home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc2082 < prev    next >
Text File  |  1997-01-09  |  25KB  |  676 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          F. Baker
  8. Request for Comments: 2082                                  R. Atkinson
  9. Category: Standards Track                                 Cisco Systems
  10.                                                            January 1997
  11.  
  12.  
  13.                         RIP-2 MD5 Authentication
  14.  
  15. Status of this Memo
  16.  
  17.    This document specifies an Internet standards track protocol for the
  18.    Internet community, and requests discussion and suggestions for
  19.    improvements.  Please refer to the current edition of the "Internet
  20.    Official Protocol Standards" (STD 1) for the standardization state
  21.    and status of this protocol.  Distribution of this memo is unlimited.
  22.  
  23. Table of Contents
  24.  
  25.    1 Use of Imperatives ...........................................    1
  26.    2 Introduction .................................................    2
  27.    3 Implementation Approach ......................................    3
  28.    3.1 RIP-2 PDU Format ...........................................    3
  29.    3.2 Processing Algorithm .......................................    5
  30.    3.2.1 Message Generation .......................................    6
  31.    3.2.2 Message Reception ........................................    7
  32.    4 Management Procedures ........................................    7
  33.    4.1 Key Management Requirements ................................    7
  34.    4.2 Key Management Procedures ..................................    8
  35.    4.3 Pathological Cases .........................................    9
  36.    5 Conformance Requirements .....................................    9
  37.    6 Acknowledgments ..............................................   10
  38.    7 References ...................................................   10
  39.    8 Security Considerations ......................................   11
  40.    9 Chairman's Address ...........................................   11
  41.    10 Authors' Addresses ..........................................   12
  42.  
  43. 1.  Use of Imperatives
  44.  
  45.    Throughout this document, the words that are used to define the
  46.    significance of particular requirements are capitalized.  These words
  47.    are:
  48.  
  49.    MUST
  50.  
  51.       This word or the adjective "REQUIRED" means that the item is an
  52.       absolute requirement of this specification.
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Baker & Atkinson            Standards Track                     [Page 1]
  59.  
  60. RFC 2082                RIP-2 MD5 Authentication            January 1997
  61.  
  62.  
  63.    MUST NOT
  64.  
  65.       This phrase means that the item is an absolute prohibition of this
  66.       specification.
  67.  
  68.    SHOULD
  69.  
  70.       This word or the adjective "RECOMMENDED" means that there may
  71.       exist valid reasons in particular circumstances to ignore this
  72.       item, but the full implications should be understood and the case
  73.       carefully weighed before choosing a different course.
  74.  
  75.    SHOULD NOT
  76.  
  77.       This phrase means that there may exist valid reasons in particular
  78.       circumstances when the listed behavior is acceptable or even
  79.       useful, but the full implications should be understood and the
  80.       case carefully weighed before implementing any behavior described
  81.       with this label.
  82.  
  83.    MAY
  84.       This word or the adjective "OPTIONAL" means that this item is
  85.       truly optional.  One vendor may choose to include the item because
  86.       a particular marketplace requires it or because it enhances the
  87.       product, for example; another vendor may omit the same item.
  88.  
  89. 2.  Introduction
  90.  
  91.    Growth in the Internet has made us aware of the need for improved
  92.    authentication of routing information.  RIP-2 provides for
  93.    unauthenticated service (as in classical RIP), or password
  94.    authentication.  Both are vulnerable to passive attacks currently
  95.    widespread in the Internet.  Well-understood security issues exist in
  96.    routing protocols [4].  Clear text passwords, currently specified for
  97.    use with RIP-2, are no longer considered sufficient [5].
  98.  
  99.    If authentication is disabled, then only simple misconfigurations are
  100.    detected.  Simple passwords transmitted in the clear will further
  101.    protect against the honest neighbor, but are useless in the general
  102.    case.  By simply capturing information on the wire - straightforward
  103.    even in a remote environment - a hostile process can learn the
  104.    password and overcome the network.
  105.  
  106.    We propose that RIP-2 use an authentication algorithm, as was
  107.    originally proposed for SNMP Version 2, augmented by a sequence
  108.    number.  Keyed MD5 is proposed as the standard authentication
  109.    algorithm for RIP-2, but the mechanism is intended to be algorithm-
  110.    independent.  While this mechanism is not unbreakable (no known
  111.  
  112.  
  113.  
  114. Baker & Atkinson            Standards Track                     [Page 2]
  115.  
  116. RFC 2082                RIP-2 MD5 Authentication            January 1997
  117.  
  118.  
  119.    mechanism is), it provides a greatly enhanced probability that a
  120.    system being attacked will detect and ignore hostile messages.  This
  121.    is because we transmit the output of an authentication algorithm
  122.    (e.g., Keyed MD5) rather than the secret RIP-2 Authentication Key.
  123.    This output is a one-way function of a message and a secret RIP-2
  124.    Authentication Key.  This RIP-2 Authentication Key is never sent over
  125.    the network in the clear, thus providing protection against the
  126.    passive attacks now commonplace in the Internet.
  127.  
  128.    In this way, protection is afforded against forgery or message
  129.    modification.  It is possible to replay a message until the sequence
  130.    number changes, but the sequence number makes replay in the long term
  131.    less of an issue.  The mechanism does not afford confidentiality,
  132.    since messages stay in the clear; however, the mechanism is also
  133.    exportable from most countries, which test a privacy algorithm would
  134.    fail.
  135.  
  136.    Other relevant rationales for the approach are that Keyed MD5 is
  137.    being used for OSPF cryptographic authentication, and is therefore
  138.    present in routers already, as is some form of password management.
  139.    A similar approach has been standardized for use in IP-layer
  140.    authentication. [7]
  141.  
  142. 3.  Implementation Approach
  143.  
  144.    Implementation requires three issues to be addressed:
  145.  
  146.    (1)  A changed packet format,
  147.  
  148.    (2)  Authentication procedures, and
  149.  
  150.    (3)  Management controls.
  151.  
  152. 3.1.  RIP-2 PDU Format
  153.  
  154.    The basic RIP-2 message format provides for an 8 byte header with an
  155.    array of 20 byte records as its data content.  When Keyed MD5 is
  156.    used, the same header and content are used, except that the 16 byte
  157.    "authentication key" field is reused to describe a "Keyed Message
  158.    Digest" trailer.  This consists in five fields:
  159.  
  160.    (1)  The "Authentication Type" is Keyed Message Digest Algorithm,
  161.         indicated by the value 3 (1 and 2 indicate "IP Route" and
  162.         "Password", respectively).
  163.  
  164.    (2)  A 16 bit offset from the RIP-2 header to the MD5 digest (if no
  165.         other trailer fields are ever defined, this value equals the
  166.         RIP-2 Data Length).
  167.  
  168.  
  169.  
  170. Baker & Atkinson            Standards Track                     [Page 3]
  171.  
  172. RFC 2082                RIP-2 MD5 Authentication            January 1997
  173.  
  174.  
  175.    (3)  An unsigned 8-bit field that contains the Key Identifier
  176.         or Key-ID. This identifies the key used to create the
  177.         Authentication Data for this RIP-2 message.  In
  178.         implementations supporting more than one authentication
  179.         algorithm, the Key-ID also indicates the authentication
  180.         algorithm in use for this message. A key is associated with
  181.         an interface.
  182.  
  183.    (4)  An unsigned 8-bit field that contains the length in octets of the
  184.         trailing Authentication Data field.  The presence of this field
  185.         permits other algorithms (e.g., Keyed SHA) to be substituted for
  186.         Keyed MD5 if desired.
  187.  
  188.    (5)  An unsigned 32 bit sequence number.  The sequence number MUST be
  189.         non-decreasing for all messages sent with the same Key ID.
  190.  
  191.    The trailer consists of the Authentication Data, which is the output
  192.    of the Keyed Message Digest Algorithm.  When the Authentication
  193.    Algorithm is Keyed MD5, the output data is 16 bytes; during digest
  194.    calculation, this is effectively followed by a pad field and a length
  195.    field as defined by RFC 1321.
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Baker & Atkinson            Standards Track                     [Page 4]
  227.  
  228. RFC 2082                RIP-2 MD5 Authentication            January 1997
  229.  
  230.  
  231. 3.2.  Processing Algorithm
  232.  
  233.    When the authentication type is "Keyed Message Digest", message
  234.    processing is changed in message creation and reception.
  235.  
  236.        0                   1                   2                   3 3
  237.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  238.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  239.    | Command (1)   | Version (1)   |       Routing Domain (2)      |
  240.    +---------------+---------------+-------------------------------+
  241.    |             0xFFFF            | AuType=Keyed Message Digest   |
  242.    +-------------------------------+-------------------------------+
  243.    |    RIP-2 Packet Length        |    Key ID    | Auth Data Len  |
  244.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  245.    |               Sequence Number (non-decreasing)                |
  246.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  247.    |               reserved must be zero                           |
  248.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  249.    |               reserved must be zero                           |
  250.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  251.    |                                                               |
  252.    /    (RIP-2 Packet Length - 24) bytes of Data                   /
  253.    |                                                               |
  254.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  255.    |             0xFFFF            |       0x01                    |
  256.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  257.    /  Authentication Data (var. length; 16 bytes with Keyed MD5)   /
  258.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  259.  
  260.    In memory, the following trailer is appended by the MD5 algorithm and
  261.    treated as though it were part of the message.
  262.  
  263.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  264.    |              sixteen octets of MD5 "secret"                   |
  265.    /                                                               /
  266.    |                                                               |
  267.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  268.    | zero or more pad bytes (defined by RFC 1321 when MD5 is used) |
  269.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  270.    |                        64 bit message length MSW              |
  271.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  272.    |                        64 bit message length LSW              |
  273.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Baker & Atkinson            Standards Track                     [Page 5]
  283.  
  284. RFC 2082                RIP-2 MD5 Authentication            January 1997
  285.  
  286.  
  287. 3.2.1.  Message Generation
  288.  
  289.    The RIP-2 Packet is created as usual, with these exceptions:
  290.  
  291.    (1) The UDP checksum need not be calculated, but MAY be set to
  292.        zero.
  293.  
  294.    (2) The authentication type field indicates the Keyed Message Digest
  295.        Algorithm (3).
  296.  
  297.    (3) The authentication "password" field is reused to store a packet
  298.        offset to the Authentication Data, a Key Identifier, the
  299.        Authentication Data Length, and a non-decreasing sequence number.
  300.  
  301.    The value used in the sequence number is arbitrary, but two
  302.    suggestions are the time of the message's creation or a simple
  303.    message counter.
  304.  
  305.    The RIP-2 Authentication Key is selected by the sender based on the
  306.    outgoing interface. Each key has a lifetime associated with it.  No
  307.    key is ever used outside its lifetime.  Since the key's algorithm is
  308.    related to the key itself, stored in the sender and receiver along
  309.    with it, the Key ID effectively indicates which authentication
  310.    algorithm is in use if the implementation supports more than one
  311.    authentication algorithm.
  312.  
  313.    (1)  The RIP-2 header's packet length field indicates the standard
  314.         RIP-2 portion of the packet.
  315.  
  316.    (2)  The Authentication Data Offset, Key Identifier, and
  317.         Authentication Data size fields are filled in appropriately.
  318.  
  319.    (3)  The RIP-2 Authentication Key, which is 16 bytes long when the
  320.         Keyed MD5 algorithm is used, is now appended to the data.  For
  321.         all algorithms, the RIP-2 Authentication Key is never longer than
  322.         the output of the algorithm in use.
  323.  
  324.    (4)  Trailing pad and length fields are added and the digest
  325.         calculated using the indicated algorithm. When Keyed MD5 is the
  326.         algorithm in use, these are calculated per RFC 1321.
  327.  
  328.    (5)  The digest is written over the RIP-2 Authentication Key.  When
  329.         MD5 is used, this digest will be 16 bytes long.
  330.  
  331.    The trailing pad is not actually transmitted, as it is entirely
  332.    predictable from the message length and algorithm in use.
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Baker & Atkinson            Standards Track                     [Page 6]
  339.  
  340. RFC 2082                RIP-2 MD5 Authentication            January 1997
  341.  
  342.  
  343. 3.2.2.  Message Reception
  344.  
  345.    When the message is received, the process is reversed:
  346.  
  347.    (1)  The digest is set aside,
  348.  
  349.    (2)  The appropriate algorithm and key are determined from the value
  350.         of the Key Identifier field,
  351.  
  352.    (3)  The RIP-2 Authentication Key is written into the appropriate
  353.         number (16 when Keyed MD5 is used) of bytes starting at the
  354.         offset indicated,
  355.  
  356.    (4)  Appropriate padding is added as needed, and
  357.  
  358.    (5)  A new digest calculated using the indicated algorithm.
  359.  
  360.    If the calculated digest does not match the received digest, the
  361.    message is discarded unprocessed.  If the neighbor has been heard
  362.    from recently enough to have viable routes in the route table and the
  363.    received sequence number is less than the last one received, the
  364.    message likewise is discarded unprocessed.  When connectivity to the
  365.    neighbor has been lost, the receiver SHOULD be ready to accept
  366.    either:
  367.    - a message with a sequence number of zero
  368.    - a message with a higher sequence number than the last received
  369.      sequence number.
  370.  
  371.    A router that has forgotten its current sequence number but remembers
  372.    its key and Key-ID MUST send its first packet with a sequence number
  373.    of zero.  This leaves a small opening for a replay attack.  Router
  374.    vendors are encouraged to provide stable storage for keys, key
  375.    lifetimes, Key-IDs, and the related sequence numbers.
  376.  
  377.    Acceptable messages are now truncated to RIP-2 message itself and
  378.    treated normally.
  379.  
  380. 4.  Management Procedures
  381.  
  382. 4.1.  Key Management Requirements
  383.  
  384.    It is strongly desirable that a hypothetical security breach in one
  385.    Internet protocol not automatically compromise other Internet
  386.    protocols.  The Authentication Key of this specification SHOULD NOT
  387.    be stored using protocols or algorithms that have known flaws.
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Baker & Atkinson            Standards Track                     [Page 7]
  395.  
  396. RFC 2082                RIP-2 MD5 Authentication            January 1997
  397.  
  398.  
  399.    Implementations MUST support the storage of more than one key at the
  400.    same time, although it is recognized that only one key will normally
  401.    be active on an interface. They MUST associate a specific lifetime
  402.    (i.e., date/time first valid and date/time no longer valid) and a key
  403.    identifier with each key, and MUST support manual key distribution
  404.    (e.g., the privileged user manually typing in the key, key lifetime,
  405.    and key identifier on the router console).  The lifetime may be
  406.    infinite.  If more than one algorithm is supported, then the
  407.    implementation MUST require that the algorithm be specified for each
  408.    key at the time the other key information is entered. Keys that are
  409.    out of date MAY be deleted at will by the implementation without
  410.    requiring human intervention.  Manual deletion of active keys SHOULD
  411.    also be supported.
  412.  
  413.    It is likely that the IETF will define a standard key management
  414.    protocol.  It is strongly desirable to use that key management
  415.    protocol to distribute RIP-2 Authentication Keys among communicating
  416.    RIP-2 implementations.  Such a protocol would provide scalability and
  417.    significantly reduce the human administrative burden. The Key ID can
  418.    be used as a hook between RIP-2 and such a future protocol.  Key
  419.    management protocols have a long history of subtle flaws that are
  420.    often discovered long after the protocol was first described in
  421.    public.  To avoid having to change all RIP-2 implementations should
  422.    such a flaw be discovered, integrated key management protocol
  423.    techniques were deliberately omitted from this specification.
  424.  
  425. 4.2.  Key Management Procedures
  426.  
  427.    As with all security methods using keys, it is necessary to change
  428.    the RIP-2 Authentication Key on a regular basis.  To maintain routing
  429.    stability during such changes, implementations MUST be able to store
  430.    and use more than one RIP-2 Authentication Key on a given interface
  431.    at the same time.
  432.  
  433.    Each key will have its own Key Identifier, which is stored locally.
  434.    The combination of the Key Identifier and the interface associated
  435.    with the message uniquely identifies the Authentication Algorithm and
  436.    RIP-2 Authentication Key in use.
  437.  
  438.    As noted above in Section 2.2.1, the party creating the RIP-2 message
  439.    will select a valid key from the set of valid keys for that
  440.    interface.  The receiver will use the Key Identifier and interface to
  441.    determine which key to use for authentication of the received
  442.    message.  More than one key may be associated with an interface at
  443.    the same time.
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Baker & Atkinson            Standards Track                     [Page 8]
  451.  
  452. RFC 2082                RIP-2 MD5 Authentication            January 1997
  453.  
  454.  
  455.    Hence it is possible to have fairly smooth RIP-2 Authentication Key
  456.    rollovers without losing legitimate RIP-2 messages because the stored
  457.    key is incorrect and without requiring people to change all the keys
  458.    at once.  To ensure a smooth rollover, each communicating RIP-2
  459.    system must be updated with the new key several minutes before the
  460.    current key will expire and several minutes before the new key
  461.    lifetime begins. The new key should have a lifetime that starts
  462.    several minutes before the old key expires. This gives time for each
  463.    system to learn of the new RIP-2 Authentication Key before that key
  464.    will be used.  It also ensures that the new key will begin being used
  465.    and the current key will go out of use before the current key's
  466.    lifetime expires.  For the duration of the overlap in key lifetimes,
  467.    a system may receive messages using either key and authenticate the
  468.    message. The Key-ID in the received message is used to select the
  469.    appropriate key for authentication.
  470.  
  471. 4.3.  Pathological Cases
  472.  
  473.    Two pathological cases exist which must be handled, which are
  474.    failures of the network manager.  Both of these should be exceedingly
  475.    rare.
  476.  
  477.    During key switchover, devices may exist which have not yet been
  478.    successfully configured with the new key. Therefore, routers SHOULD
  479.    implement (and would be well advised to implement) an algorithm that
  480.    detects the set of keys being used by its neighbors, and transmits
  481.    its messages using both the new and old keys until all of the
  482.    neighbors are using the new key or the lifetime of the old key
  483.    expires.  Under normal circumstances, this elevated transmission rate
  484.    will exist for a single update interval.
  485.  
  486.    In the event that the last key associated with an interface expires,
  487.    it is unacceptable to revert to an unauthenticated condition, and not
  488.    advisable to disrupt routing.  Therefore, the router should send a
  489.    "last authentication key expiration" notification to the network
  490.    manager and treat the key as having an infinite lifetime until the
  491.    lifetime is extended, the key is deleted by network management, or a
  492.    new key is configured.
  493.  
  494. 5.  Conformance Requirements
  495.  
  496.    To conform to this specification, an implementation MUST support all
  497.    of its aspects.  The Keyed MD5 authentication algorithm MUST be
  498.    implemented by all conforming implementations. MD5 is defined in
  499.    RFC-1321.  A conforming implementation MAY also support other
  500.    authentication algorithms such as Keyed Secure Hash Algorithm (SHA).
  501.    Manual key distribution as described above MUST be supported by all
  502.    conforming implementations. All implementations MUST support the
  503.  
  504.  
  505.  
  506. Baker & Atkinson            Standards Track                     [Page 9]
  507.  
  508. RFC 2082                RIP-2 MD5 Authentication            January 1997
  509.  
  510.  
  511.    smooth key rollover described under "Key Change Procedures."
  512.  
  513.    The user documentation provided with the implementation MUST contain
  514.    clear instructions on how to ensure that smooth key rollover occurs.
  515.  
  516.    Implementations SHOULD support a standard key management protocol for
  517.    secure distribution of RIP-2 Authentication Keys once such a key
  518.    management protocol is standardized by the IETF.
  519.  
  520. 6.  Acknowledgments
  521.  
  522.    This work was done by the RIP-2 Working Group, of which Gary Malkin
  523.    is the Chair.  This suggestion was originally made by Christian
  524.    Huitema on behalf of the IAB.  Jeff Honig (Cornell) and Dennis
  525.    Ferguson (ANS) built the first operational prototype, proving out the
  526.    algorithms.  The authors gladly acknowledge significant inputs from
  527.    each of these sources.
  528.  
  529. 7.  References
  530.  
  531.    [1]  Malkin, G., "RIP Version 2 Carrying Additional Information",
  532.         RFC 1388, January 1993.
  533.  
  534.    [2]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
  535.         1992.
  536.  
  537.    [3]  Malkin, G., and F. Baker, "RIP Version 2 MIB Extension",
  538.         RFC 1389, Xylogics, Inc., Advanced Computer Communications,
  539.         January 1993.
  540.  
  541.    [4]  S. Bellovin, "Security Problems in the TCP/IP Protocol Suite",
  542.         ACM Computer Communications Review, Volume 19, Number 2,
  543.         pp.32-48, April 1989.
  544.  
  545.    [5]  Haller, N., and R. Atkinson, "Internet Authentication
  546.         Guidelines", RFC 1704, October 1994.
  547.  
  548.    [6]  Braden, R., Clark, D., Crocker, S., and C. Huitema, "Report
  549.         of IAB Workshop on Security in the Internet Architecture",
  550.         RFC 1636, June 1994.
  551.  
  552.    [7]  Atkinson, R., "IP Authentication Header", RFC 1826, August 1995.
  553.  
  554.    [8]  Atkinson, R., "IP Encapsulating Security Payload", RFC 1827,
  555.         August 1995.
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Baker & Atkinson            Standards Track                    [Page 10]
  563.  
  564. RFC 2082                RIP-2 MD5 Authentication            January 1997
  565.  
  566.  
  567. 8.  Security Considerations
  568.  
  569.    This entire memo describes and specifies an authentication mechanism
  570.    for the RIP-2 routing protocol that is believed to be secure against
  571.    active and passive attacks. Passive attacks are clearly widespread in
  572.    the Internet at present.  Protection against active attacks is also
  573.    needed because active attacks are becoming more common.
  574.  
  575.    Users need to understand that the quality of the security provided by
  576.    this mechanism depends completely on the strength of the implemented
  577.    authentication algorithms, the strength of the key being used, and
  578.    the correct implementation of the security mechanism in all
  579.    communicating RIP-2 implementations. This mechanism also depends on
  580.    the RIP-2 Authentication Key being kept confidential by all parties.
  581.    If any of these incorrect or insufficiently secure, then no real
  582.    security will be provided to the users of this mechanism.
  583.  
  584.    Specifically with respect to the use of SNMP, compromise of SNMP
  585.    security has the necessary result that the various RIP-2
  586.    configuration parameters (e.g. routing table, RIP-2 Authentication
  587.    Key) manageable via SNMP could be compromised as well.  Changing
  588.    Authentication Keys using non-encrypted SNMP is no more secure than
  589.    sending passwords in the clear.
  590.  
  591.    Confidentiality is not provided by this mechanism.  Recent work in
  592.    the IETF provides a standard mechanism for IP-layer encryption. [8]
  593.    That mechanism might be used to provide confidentiality for RIP-2 in
  594.    the future.  Protection against traffic analysis is also not
  595.    provided.  Mechanisms such as bulk link encryption might be used when
  596.    protection against traffic analysis is required.
  597.  
  598.    The memo is written to address a security consideration in RIP
  599.    Version 2 that was raised during the IAB's recent security review
  600.    [6].
  601.  
  602. 9.  Chairman's Address
  603.  
  604.    Gary Scott Malkin
  605.    Xylogics, Inc.
  606.    53 Third Avenue
  607.    Burlington, MA 01803
  608.  
  609.    Phone:  (617) 272-8140
  610.    EMail:  gmalkin@Xylogics.COM
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Baker & Atkinson            Standards Track                    [Page 11]
  619.  
  620. RFC 2082                RIP-2 MD5 Authentication            January 1997
  621.  
  622.  
  623. 10.  Authors' Addresses
  624.  
  625.    Fred Baker
  626.    cisco Systems
  627.    519 Lado Drive
  628.    Santa Barbara, California 93111
  629.  
  630.    Phone: (805) 681 0115
  631.    Email: fred@cisco.com
  632.  
  633.  
  634.    Randall Atkinson
  635.    cisco Systems
  636.    170 West Tasman Drive
  637.    San Jose, CA 95134-1706
  638.  
  639.    Phone: (408) 526-6566
  640.    EMail: rja@cisco.com
  641.  
  642.  
  643.  
  644.  
  645.  
  646.  
  647.  
  648.  
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659.  
  660.  
  661.  
  662.  
  663.  
  664.  
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Baker & Atkinson            Standards Track                    [Page 12]
  675.  
  676.