rfc4822.original   rfc4822.txt 
Network Working Group R. Atkinson, Extreme Networks Network Working Group R. Atkinson
INTERNET-DRAFT M. Fanto, NIST Request for Comments: 4822 Extreme Networks
Obsoletes: RFC-2082 (once approved) 7 October 2006 Obsoletes: 2082 M. Fanto
Updates: RFC-2453 (once approved) draft-rja-ripv2-auth-06.txt Updates: 2453 NIST
RIPv2 Cryptographic Authentication Category: Standards Track February 2007
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any RIPv2 Cryptographic Authentication
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Internet-Drafts are working documents of the Internet Engineering Status of This Memo
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This document specifies an Internet standards track protocol for the
and may be updated, replaced, or obsoleted by other documents at any Internet community, and requests discussion and suggestions for
time. It is inappropriate to use Internet-Drafts as reference improvements. Please refer to the current edition of the "Internet
material or to cite them other than as "work in progress." Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
The list of current Internet-Drafts can be accessed at: Copyright Notice
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at: Copyright (C) The IETF Trust (2007).
http://www.ietf.org/shadow.html
This memo is a contribution to the IETF and is intended for future IESG Note
standards-track publication to update RFC-2082 and RFC-2453. This
memo is not the product of any IETF working group.
Distribution of this memo is unlimited. In the interests of encouraging rapid migration away from Keyed-MD5
and its known weakness, the IESG has approved this document even
though it does not meet the guidelines in BCP 107 (RFC 4107).
However, the IESG stresses that automated key management should be
used to establish session keys and urges that the future work on key
management described in Section 5.6 of this document should be
performed as soon as possible.
ABSTRACT Abstract
This note describes a revision to the RIPv2 Cryptographic This note describes a revision to the RIPv2 Cryptographic
Authentication mechanism originally specified in RFC-2082. This Authentication mechanism originally specified in RFC 2082. This
document obsoletes RFC-2082. This document updates RFC-2453. This document obsoletes RFC 2082 and updates RFC 2453. This document adds
document adds details of how the SHA family of hash algorithms can be details of how the SHA family of hash algorithms can be used with
used with RIPv2 Cryptographic Authentication, whereas the original RIPv2 Cryptographic Authentication, whereas the original document
document only specified the use of Keyed-MD5. Also, this document only specified the use of Keyed-MD5. Also, this document clarifies a
clarifies a potential issue with an active attack on this mechanism potential issue with an active attack on this mechanism and adds
and adds significant text to the Security Considerations section. significant text to the Security Considerations section.
1. INTRODUCTION 1. Introduction
Growth in the Internet has made us aware of the need for improved Growth in the Internet has made us aware of the need for improved
authentication of routing information. RIPv2 provides for authentication of routing information. RIPv2 provides for
unauthenticated service (as in classical RIP), or password unauthenticated service (as in classical RIP), or password
authentication. Both are vulnerable to passive attacks currently authentication. Both are vulnerable to passive attacks currently
widespread in the Internet. Well-understood security issues exist in widespread in the Internet. Well-understood security issues exist in
routing protocols [Bell89]. Clear text passwords, originally routing protocols [Bell89]. Clear text passwords, originally
specified for use with RIPv2, are widely understood to be vulnerable specified for use with RIPv2, are widely understood to be vulnerable
to easily deployed passive attacks [HA94]. to easily deployed passive attacks [HA94].
The original RIPv2 cryptographic authentication specification [AB97] The original RIPv2 cryptographic authentication specification, RFC
used the Keyed-MD5 cryptographic mechanism. While there are no openly 2082 [AB97], used the Keyed-MD5 cryptographic mechanism. While there
published attacks on that mechanism, some reports [Dobb96a, Dobb96b] are no openly published attacks on that mechanism, some reports
create concern about the ultimate strength of the MD5 cryptographic [Dobb96a, Dobb96b] create concern about the ultimate strength of the
hash function. Further, some end users, particularly several MD5 cryptographic hash function. Further, some end users,
different governments, require the use of the SHA hash function family particularly several different governments, require the use of the
rather than any other such function for policy reasons. Finally, the SHA hash function family rather than any other such function for
original specification uses a hashing construction widely believed to policy reasons. Finally, the original specification uses a hashing
be weaker than the HMAC construction used with the algorithms added in construction widely believed to be weaker than the HMAC construction
this revision of the specification. used with the algorithms added in this revision of the specification.
This document obsoletes the original specification, RFC-2082 [AB97]. This document obsoletes the original specification, RFC 2082 [AB97].
This specification differs from RFC-2082 by adding support for the SHA This specification differs from RFC 2082 by adding support for the
family of hash algorithms and the HMAC technique, while retaining the SHA family of hash algorithms and the HMAC technique, while retaining
original Keyed-MD5 algorithm and mode. As the original RIPv2 the original Keyed-MD5 algorithm and mode. As the original RIPv2
Cryptographic Authentication mechanism was algorithm-independent, Cryptographic Authentication mechanism was algorithm-independent,
backwards compatibility is retained. This requirement for backwards backwards compatibility is retained. This requirement for backwards
compatibility precludes making significant protocol changes. So this compatibility precludes making significant protocol changes. So,
document limits changes to the addition of support for an additional this document limits changes to the addition of support for an
family of cryptographic algorithms. The original specification has additional family of cryptographic algorithms. The original
been very widely implemented, is known to be widely interoperable, specification has been very widely implemented, is known to be widely
and is also widely deployed. interoperable, and is also widely deployed.
The authors do NOT believe that this specification is the final The authors do NOT believe that this specification is the final
answer to RIPv2 authentication and encourage the reader to consult answer to RIPv2 authentication and encourage the reader to consult
the SECURITY CONSIDERATIONS section of this document for more the Security Considerations section of this document for more
details. details.
If RIPv2 authentication is disabled, then only simple If RIPv2 authentication is disabled, then only simple
misconfigurations are detected. The original RIPv2 authentication misconfigurations are detected. The original RIPv2 authentication
mechanism relied upon reused cleartext passwords. Use of cleartext mechanism relied upon reused cleartext passwords. Use of cleartext
password authentication can protect against accidential password authentication can protect against accidental
misconfigurations if that were the only concern, but is not helpful misconfigurations if that were the only concern, but is not helpful
from a security perspective. By simply capturing information on the from a security perspective. By simply capturing information on the
wire - straightforward even in a remote environment - a hostile wire -- straightforward even in a remote environment -- a hostile
entity can read the cleartext RIPv2 password and use that knowledge entity can read the cleartext RIPv2 password and use that knowledge
to inject false information into the routing system via the RIPv2 to inject false information into the routing system via the RIPv2
routing protocol. routing protocol.
This mechanism is intended to reduce the risk of a successful passive This mechanism is intended to reduce the risk of a successful passive
attack upon RIPv2 deployments. That is, deployment of this mechanism attack upon RIPv2 deployments. That is, deployment of this mechanism
greatly reduces the vulnerability of the RIPv2-based routing system greatly reduces the vulnerability of the RIPv2-based routing system
from a passive attack. When cryptographic authentication is enabled, from a passive attack. When cryptographic authentication is enabled,
we transmit the output of a keyed cryptographic one-way function in we transmit the output of a keyed cryptographic one-way function in
the authentication field of the RIPv2 packet, instead of sending a the authentication field of the RIPv2 packet, instead of sending a
cleartext reusable password in the RIPv2 packet. The RIPv2 cleartext reusable password in the RIPv2 packet. The RIPv2
Authentication Key is known only to the authorised parties of the Authentication Key is known only to the authorized parties of the
RIPv2 session. The RIPv2 Authentication Key is never sent over the RIPv2 session. The RIPv2 Authentication Key is never sent over the
network in the clear. network in the clear.
In this way, protection is afforded against forgery or message In this way, protection is afforded against forgery or message
modification. While it is possible to replay a message until the modification. While it is possible to replay a message until the
sequence number changes, a sequence number can be used to reduce sequence number changes, a sequence number can be used to reduce
replay risks. The mechanism does not provide confidentiality, replay risks. The mechanism does not provide confidentiality, since
since messages stay in the clear. Since the objective of a messages stay in the clear. Since the objective of a routing
routing protocol is to advertise the routing topology, protocol is to advertise the routing topology, confidentiality is not
confidentiality is not normally required for routing protocols. normally required for routing protocols.
Other relevant rationales for the approach are that MD5 and SHA-1 Other relevant rationales for the approach are that MD5 and SHA-1 are
are both being used for other purposes and are therefore generally both being used for other purposes and are therefore generally
already present in IP routers, as is some form of password already present in IP routers, as is some form of password
management. management.
1.1 Terminology 1.1. Terminology
In this document, the words "MUST", "MUST NOT", "REQUIRED", "SHALL", In this document, the words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
in [BCP14] [RFC-2119] and indicate requirement levels for compliant described in [BCP14] and indicate requirement levels for compliant or
or conformant implementations. conformant implementations.
2. Implementation Approach 2. Implementation Approach
Implementation requires use of a special packet format, special Implementation requires use of a special packet format, special
authentication procedures, and also management controls. Implementers authentication procedures, and also management controls.
need to remember that the SECURITY CONSIDERATIONS section is an Implementers need to remember that the Security Considerations
integral part of this specification and contains important parts of section is an integral part of this specification and contains
this specification. important parts of this specification.
2.1. RIPv2 PDU Format 2.1. RIPv2 PDU Format
The basic RIPv2 message format provides for an 8 octet header with an The basic RIPv2 message format provides for an 8-octet header with an
array of 20 octet records as its data content. When RIPv2 array of 20-octet records as its data content. When RIPv2
Cryptographic Authentication is enabled, the same header and content Cryptographic Authentication is enabled, the same header and content
are used as with the original RIPv2 specification, but the 16 octet are used as with the original RIPv2 specification, but the 16-octet
"Authentication" password field of the original RIPv2 specification "Authentication" password field of the original RIPv2 specification
is reused to contain a packet offset to the Authentication Data, a is reused to contain a packet offset to the Authentication Data, a
Key Identifier, the Authentication Data Length, and a non-decreasing Key Identifier, the Authentication Data Length, and a non-decreasing
Sequence Number. sequence number.
AUTHENTICATION TYPE AUTHENTICATION TYPE
The "Authentication Type" is Cryptographic Hash Function, The "Authentication Type" is Cryptographic Hash Function, which
which is indicated by the value 3. is indicated by the value 3.
RIPv2 PACKET LENGTH RIPv2 PACKET LENGTH
An unsigned 16 bit offset from the start of the RIPv2 header An unsigned 16-bit offset from the start of the RIPv2 header to
to the end of the regular RIPv2 packet (not including the authentication the end of the regular RIPv2 packet (not including the
trailer). authentication trailer).
KEY IDENTIFIER KEY IDENTIFIER
An unsigned 8-bit field that contains the Key Identifier or An unsigned 8-bit field that contains the Key Identifier or
Key-ID. This, in combination with the network interface, identifies Key-ID. This, in combination with the network interface,
the RIPv2 Security Association in use for this packet. The RIPv2 identifies the RIPv2 Security Association in use for this
Security association, which is defined in Section 2.2 below, includes packet. The RIPv2 Security Association, which is defined in
the Authentication Key that was used to create the Authentication Data Section 2.2 below, includes the Authentication Key that was
for this RIPv2 message and other parameters. In implementations used to create the Authentication Data for this RIPv2 message
supporting more than one authentication algorithm, the RIPv2 Security and other parameters. In implementations supporting more than
Association also includes information about which authentication one authentication algorithm, the RIPv2 Security Association
algorithm in use for this message. A RIPv2 Security Association is also includes information about which authentication algorithm
always associated with an interface, rather than with a router. The is in use for this message. A RIPv2 Security Association is
actual cryptographic key is part of a RIPv2 Security Association. always associated with an interface, rather than with a router.
The actual cryptographic key is part of the RIPv2 Security
Association.
AUTHENTICATION DATA LENGTH AUTHENTICATION DATA LENGTH
An unsigned 8-bit field that contains the length in octets of An unsigned 8-bit field that contains the length in octets of
the trailing Authentication Data field. The presence of this field the trailing Authentication Data field. The presence of this
helps provide cryptographic algorithm independence. field helps provide cryptographic algorithm independence.
AUTHENTICATION DATA AUTHENTICATION DATA
This field contains the cryptographic Authentication Data This field contains the cryptographic Authentication Data used
used to validate this packet. The length of this field is stored to validate this packet. The length of this field is stored in
in the AUTHENTICATION DATA LENGTH field above. the AUTHENTICATION DATA LENGTH field above.
SEQUENCE NUMBER SEQUENCE NUMBER
An unsigned 32 bit sequence number. The sequence number MUST An unsigned 32-bit sequence number. The sequence number MUST
be non-decreasing for all messages sent from a given source router be non-decreasing for all messages sent from a given source
with a given Key ID value. router with a given Key ID value.
The authentication trailer contains the Authentication Data, which The authentication trailer contains the Authentication Data, which is
is the output of the keyed cryptographic hash function. See later the output of the keyed cryptographic hash function. See later
subsections of this section for details on computing this field. subsections of this section for details on computing this field.
0 1 2 3 3 0 1 2 3
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 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
+---------------+---------------+-------------------------------+ +---------------+---------------+-------------------------------+
| Command (1) | Version (1) | Routing Domain (2) | | Command (1) | Version (1) | Routing Domain (2) |
+---------------+---------------+-------------------------------+ +---------------+---------------+-------------------------------+
| 0xFFFF | Authentication Type==0x0003 | | 0xFFFF | Authentication Type=0x0003 |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| RIPv2 Packet Length | Key ID | Auth Data Len | | RIPv2 Packet Length | Key ID | Auth Data Len |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Sequence Number (non-decreasing) | | Sequence Number (non-decreasing) |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| reserved must be zero | | reserved must be zero |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| reserved must be zero | | reserved must be zero |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| (RIPv2 Packet Length - 24) bytes of Data | | |
~ (RIPv2 Packet Length - 24) bytes of Data ~
| |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| 0xFFFF | 0x0001 | | 0xFFFF | 0x0001 |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Authentication Data (variable length; 20 bytes with HMAC-SHA1)| | Authentication Data (variable length; 20 bytes with HMAC-SHA1)|
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
2.2 RIPv2 Security Association 2.2. RIPv2 Security Association
Understanding the RIPv2 Security Association concept is central to Understanding the RIPv2 Security Association concept is central to
understanding this specification. A RIPv2 Security Association understanding this specification. A RIPv2 Security Association
contains the set of shared authentication configuration parameters contains the set of shared authentication configuration parameters
needed by the legitimate sender or any legitimate receiver. needed by the legitimate sender or any legitimate receiver.
An implementation MUST be able to support at least 2 concurrent RIPv2 An implementation MUST be able to support at least 2 concurrent RIPv2
Security Associations on each RIP interface. This is a functional Security Associations on each RIP interface. This is a functional
requirement for supporting key rollover. Support for key rollover is requirement for supporting key rollover. Support for key rollover is
mandatory. mandatory.
The RIPv2 Security Association, defined below, is selected by the The RIPv2 Security Association, defined below, is selected by the
sender based on the outgoing router interface. Each RIPv2 Security sender based on the outgoing router interface. Each RIPv2 Security
Association has a lifetime and other configuration parameters Association has a lifetime and other configuration parameters
associated with it. In normal operation, a RIPv2 Security Association associated with it. In normal operation, a RIPv2 Security
is never used outside its lifetime. Certain abnormal cases are Association is never used outside its lifetime. Certain abnormal
discussed later in this document. cases are discussed later in this document.
The minimum data items in a RIPv2 Security Association are as follows: The minimum data items in a RIPv2 Security Association are as
follows:
KEY-IDENTIFIER (KEY-ID) KEY-IDENTIFIER (KEY-ID)
The unsigned 8-bit KEY-ID value is used to identify the RIPv2 The unsigned 8-bit KEY-ID value is used to identify the RIPv2
Security Association in use for this packet. Security Association in use for this packet.
The receiver uses the combination of the interface the packet The receiver uses the combination of the interface the packet
was received upon and the KEY-ID value to uniquely identify the was received upon and the KEY-ID value to uniquely identify the
appropriate Security Association. appropriate Security Association.
The sender selects which RIPv2 Security Association to use based
on the outbound interface for this RIPv2 packet and then places the The sender selects which RIPv2 Security Association to use
correct KEY-ID value into that packet. If multiple valid and active based on the outbound interface for this RIPv2 packet and then
RIPv2 Security Associations exist for a given outbound interface at places the correct KEY-ID value into that packet. If multiple
the time a RIPv2 packet is sent, the sender may use any of those valid and active RIPv2 Security Associations exist for a given
security associations to protect the packet. outbound interface at the time a RIPv2 packet is sent, the
sender may use any of those security associations to protect
the packet.
AUTHENTICATION ALGORITHM AUTHENTICATION ALGORITHM
This specifies the cryptographic algorithm and algorithm This specifies the cryptographic algorithm and algorithm mode
mode used with the RIPv2 Security Association. This information used with the RIPv2 Security Association. This information is
is never sent in clear-text over the wire. Because this information never sent in cleartext over the wire. Because this
is not sent on the wire, the implementer chooses an implementation information is not sent on the wire, the implementer chooses an
specific representation for this information. At present, the implementation specific representation for this information.
following values are possible: At present, the following values are possible: KEYED-MD5,
KEYED-MD5, HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512.
and HMAC-SHA-512.
AUTHENTICATION KEY AUTHENTICATION KEY
This is the value of the cryptographic authentication key This is the value of the cryptographic authentication key used
used with the associated Authentication Algorithm. It MUST NOT with the associated Authentication Algorithm. It MUST NOT ever
ever be sent over the network in clear-text via any protocol. be sent over the network in cleartext via any protocol. The
The length of this key will depend on the Authentication Algorithm length of this key will depend on the Authentication Algorithm
in use. Operators should take care to select unpredictable and in use. Operators should take care to select unpredictable and
strong keys, avoiding any keys known to be weak for the algorithm strong keys, avoiding any keys known to be weak for the
in use. [ECS94] contains helpful information both on key algorithm in use. [ESC05] contains helpful information on both
generation techniques and on cryptographic randomness. key generation techniques and cryptographic randomness.
SEQUENCE NUMBER SEQUENCE NUMBER
This is an unsigned 32-bit number. For a given KEY-ID value and This is an unsigned 32-bit number. For a given KEY-ID value
sender, this number MUST NOT decrease. In normal operation, the and sender, this number MUST NOT decrease. In normal
operator should rekey the RIPv2 session prior to reaching the maximum operation, the operator should rekey the RIPv2 session prior to
value. The initial value used in the sequence number is arbitrary. reaching the maximum value. The initial value used in the
Receivers SHOULD keep track of the most recent sequence number sequence number is arbitrary. Receivers SHOULD keep track of
received from a given sender. the most recent sequence number received from a given sender.
START TIME START TIME
This is a local representation of the day and time that This is a local representation of the day and time that this
this Security Association first becomes valid. Security Association first becomes valid.
STOP TIME STOP TIME
This is a local representation of the day and time that this This is a local representation of the day and time that this
Security Association becomes invalid (i.e. when it expires). It is Security Association becomes invalid (i.e., when it expires).
permitted, but not recommended, for an operator to configure this to It is permitted, but not recommended, for an operator to
be "never expire". The "never expire" value is not recommended configure this to "never expire". The "never expire" value is
operational practice because it reduces security as compared with not recommended operational practice because it reduces
periodic rekeying. Normally, a RIPv2 Security Association is deleted security as compared with periodic rekeying. Normally, a RIPv2
at its STOP TIME. However, there are certain pathological cases, Security Association is deleted at its STOP TIME. However,
which are discussed in Section 5.1. there are certain pathological cases, which are discussed in
Section 5.1.
The authentication trailer consists of the Authentication Data, which The authentication trailer consists of the Authentication Data, which
is the output of the keyed cryptographic hash function. See later is the output of the keyed cryptographic hash function. See later
subsections of this section for details on computing this field. subsections of this section for details on computing this field.
2.3 Basic Authentication Processing 2.3. Basic Authentication Processing
When the authentication type is "Cryptographic Hash Function", message When the authentication type is "Cryptographic Hash Function",
processing is changed in message creation and reception as compared message processing is changed in message creation and reception as
with the original RIPv2 specification in [Mal94]. compared with the original RIPv2 specification in [Mal94].
This section describes the message processing generically. Additional This section describes the message processing generically.
algorithm-dependent processing that is required is described in Additional algorithm-dependent processing that is required is
separate, subsequent sections of this document. As of this writing, described in separate, subsequent sections of this document. As of
there are 2 kinds of algorithm-dependent processing. One covers the this writing, there are 2 kinds of algorithm-dependent processing.
"Keyed-MD5" algorithm. The other covers the "HMAC-SHA1" family of One covers the "Keyed-MD5" algorithm. The other covers the
algorithms. "HMAC-SHA1" family of algorithms.
2.3.1. Message Generation 2.3.1. Message Generation
The RIPv2 Packet is created as usual, with these exceptions: The RIPv2 Packet is created as usual, with these exceptions:
(1) The UDP checksum SHOULD be calculated, but MAY be set (1) The UDP checksum SHOULD be calculated, but MAY be set to zero
to zero because any of the cryptographic authentication because any of the cryptographic authentication mechanisms in
mechanisms in this specification will provider stronger this specification will provide stronger integrity protection
integrity protection than the standard UDP checksum. than the standard UDP checksum.
(2) The authentication type field indicates Cryptographic (2) The Authentication Type field indicates Cryptographic
Authentication (3). Authentication (3).
(3) The authentication "password" field is reused to store a (3) The Authentication "password" field is reused to store a packet
packet offset to the Authentication Data, a Key Identifier, offset to the Authentication Data, a Key Identifier, the
the Authentication Data Length, and a non-decreasing Authentication Data Length, and a non-decreasing sequence number.
sequence number.
See also Section 2.2 above on RIPv2 Security Association for See also Section 2.2 above on RIPv2 Security Association for other
other important background information. important background information.
When creating the RIPv2 Packet, the follow process is followed: When creating the RIPv2 Packet, the following process is followed:
(1) The packet length field of the RIPv2 header indicates the (1) The Packet Length field of the RIPv2 header indicates the size of
size of the main body of the RIPv2 packet. the main body of the RIPv2 packet.
(2) An appropriate RIPv2 Security Association is selected for (2) An appropriate RIPv2 Security Association is selected for use
use with this packet, based on the outbound interface for with this packet, based on the outbound interface for the packet.
the packet. Any valid RIPv2 Security Association for that Any valid RIPv2 Security Association for that outbound interface
outbound interface may be used. The Authentication Data Offset, may be used. The Authentication Data Offset, Key Identifier, and
Key Identifier, and Authentication Data size fields are Authentication Data Length fields are filled in appropriately.
filled in appropriately.
(3) Algorithm-dependent processing occurs now, either for the (3) Algorithm-dependent processing occurs now, either for the
"Keyed-MD5" algorithm or for the "HMAC-SHA1" algorithm family. "Keyed-MD5" algorithm or for the "HMAC-SHA1" algorithm family.
See the respective sub-sections (below) for details of this See the respective sub-sections (below) for details of this
algorithm-dependent processing. algorithm-dependent processing.
(4) The resulting Authentication Data value is written into the (4) The resulting Authentication Data value is written into the
Authentication Data field. The trailing pad (if any) is not Authentication Data field. The trailing pad (if any) is not
actually transmitted, as it is entirely predictable from the actually transmitted, as it is entirely predictable from the
message length and Authentication Algorithm in use. message length and Authentication Algorithm in use.
2.3.2. Message Reception 2.3.2. Message Reception
When the message is received, the process is reversed: When the message is received, the process is reversed:
(1) The received Authentication Data is set aside and stored (1) The received Authentication Data is set aside and stored for
for later use, later use,
(2) The appropriate RIPv2 Security Association is determined (2) The appropriate RIPv2 Security Association is determined from the
from the value of the Key Identifier field and the interface value of the Key Identifier field and the interface the packet
the packet was received on. If there is no valid RIPv2 was received on. If there is no valid RIPv2 Security Association
Security Association for the received Key Identifier on for the received Key Identifier on the interface that the packet
the interface that the packet was received on, then was received on, then:
(a) all processing of the incoming packet ceases,
and (a) all processing of the incoming packet ceases, and
(b) a security event SHOULD be logged by the RIPv2 subsystem
of the receiving system. That security event should indicate (b) a security event SHOULD be logged by the RIPv2 subsystem of
at least the day/time that the bad packet was received, the the receiving system. That security event should indicate at
least the day/time that the bad packet was received, the
Source IP Address of the received RIPv2 packet, the Key-ID Source IP Address of the received RIPv2 packet, the Key-ID
field value, the interface the bad packet arrived upon, and field value, the interface the bad packet arrived upon, and
the fact that no valid RIPv2 Security Association was found the fact that no valid RIPv2 Security Association was found
for that interface and Key-ID combination. for that interface and Key-ID combination.
(3) Algorithm-dependent processing is performed, using the (3) Algorithm-dependent processing is performed, using the algorithm
algorithm specified by the appropriate RIPv2 Security specified by the appropriate RIPv2 Security Association for this
Association for this packet. This results in calculation packet. This results in calculation of the Authentication Data
of the Authentication Data based on the information in the based on the information in the received RIPv2 packet and
received RIPv2 packet and information from the appropriate information from the appropriate RIPv2 Security Association for
RIPv2 Security Association for that packet. that packet.
(4) The calculated Authentication Data result is compared with (4) The calculated Authentication Data result is compared with the
the received Authentication Data. received Authentication Data.
(5) If the calculated authentication data result does not match the (5) If the calculated authentication data result does not match the
received Authentication Data field, then: received Authentication Data field, then:
(a) the message MUST be discarded without being processed,
and (a) the message MUST be discarded without being processed, and
(b) a security event SHOULD be logged by the RIPv2 subsystem
of the receiving system. That security event SHOULD indicate (b) a security event SHOULD be logged by the RIPv2 subsystem of
at least the day/time that the bad packet was received, the the receiving system. That security event SHOULD indicate at
least the day/time that the bad packet was received, the
Source IP Address of the received RIPv2 packet, the Key-ID Source IP Address of the received RIPv2 packet, the Key-ID
field value, the interface the bad packet arrived upon, and field value, the interface the bad packet arrived upon, and
the fact that RIPv2 Authentication failed upon receipt of the the fact that RIPv2 Authentication failed upon receipt of the
packet. packet.
(6) If the neighbor has been heard from recently enough to have viable (6) If the neighbor has been heard from recently enough to have
routes in the local routing table, and the received sequence number viable routes in the local routing table, and the received
is less than the last sequence number received, then the message sequence number is less than the last sequence number received,
MUST be discarded unprocessed. If the received sequence number then the message MUST be discarded unprocessed. If the received
is less than the last sequence number received, that fact SHOULD sequence number is less than the last sequence number received,
be logged as a security event. This logged security event SHOULD that fact SHOULD be logged as a security event. This logged
indicate at least the day/time that the bad packet was received, security event SHOULD indicate at least the day/time that the bad
the Source IP Address of the received RIPv2 packet, the Key-ID packet was received, the Source IP Address of the received RIPv2
field value, and the fact that an out of order RIPv2 Sequence packet, the Key-ID field value, and the fact that an out-of-order
Number was received. RIPv2 sequence number was received.
When connectivity to the neighbor has been lost, the receiver When connectivity to the neighbor has been lost, the receiver
SHOULD be ready to accept either: SHOULD be ready to accept either:
- a message with a sequence number of zero. - a message with a sequence number of zero.
- a message with a higher sequence number than
the last received sequence number.
(7) Acceptable messages are now truncated to the RIPv2 message itself, - a message with a higher sequence number than the last
minus the authentication trailer, and are processed normally received sequence number.
(i.e. in accordance with the RIPv2 base specification in RFC-2453
[Mal98]). The last received Sequence Number for this RIPv2
Security Association and sender is also updated.
NOTA BENE: (7) Acceptable messages are now truncated to the RIPv2 message
A router that has forgotten its current sequence number but itself, minus the authentication trailer, and are processed
remembers its Security Association MUST send its first packet with a normally (i.e., in accordance with the RIPv2 base specification
sequence number of zero. This leaves a small opening for a replay in RFC 2453 [Mal98]). The last received sequence number for this
attack. To reduce the risk of such attacks by precluding the situation RIPv2 Security Association and sender is also updated.
where a router has forgotten its current sequence number, implementers
SHOULD provide non-volatile storage for all components of a RIPv2
Security Association and receiving systems SHOULD provide non-volatile
storage for the last received Sequence Number from each sender.
See also the SECURITY CONSIDERATIONS section of this document.
2.4 Keyed-MD5 Algorithm-dependent Processing NOTA BENE: A router that has forgotten its current sequence number
but remembers its Security Association MUST send its first packet
with a sequence number of zero. This leaves a small opening for a
replay attack. To reduce the risk of such attacks by precluding the
situation where a router has forgotten its current sequence number,
implementers SHOULD provide non-volatile storage for all components
of a RIPv2 Security Association, and receiving systems SHOULD provide
non-volatile storage for the last received sequence number from each
sender. See also the Security Considerations section of this
document.
This section describes the algorithm-dependent processing 2.4. Keyed-MD5 Algorithm-Dependent Processing
steps applicable when the "Keyed-MD5" authentication algorithm is
in use. The RIPv2 Authentication Key is always 16 octets when
"Keyed-MD5" is in use.
(1) The RIPv2 Authentication Key is appended to the RIPv2 packet This section describes the algorithm-dependent processing steps
in memory. applicable when the "Keyed-MD5" authentication algorithm is in use.
(2) The Trailing Pad for MD5 and message length fields are added The RIPv2 Authentication Key is always 16 octets when "Keyed-MD5" is
in memory. The diagram below shows how these additions appear in use.
when appended in memory:
(1) The RIPv2 Authentication Key is appended to the RIPv2 packet in
memory.
(2) The Trailing Pad for MD5 and message length fields are added in
memory. The diagram below shows how these additions appear when
appended in memory:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Key | | Authentication Key |
/ (16 octets long) / / (16 octets long) /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero or more pad octets (as defined by RFC-1321) | | zero or more pad octets (as defined by RFC 1321) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64 bit message length MSW | | 64-bit message length MSW |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64 bit message length LSW | | 64-bit message length LSW |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(3) The Authentication Data is then calculated according to the (3) The Authentication Data is then calculated according to the MD5
MD5 algorithm defined by RFC-1321 [Rivest92]. algorithm defined by RFC 1321 [Rivest92].
2.5 HMAC-SHA1 Algorithm-dependent Processing 2.5. HMAC-SHA1 Algorithm-Dependent Processing
This section describes the processing steps for HMAC This section describes the processing steps for HMAC Authentication.
Authentication. While HMAC was originally documented in [KMC97], While HMAC was originally documented in [KMC97], for this
for this specification the terminology used in [FIPS-198] is used. specification, the terminology used in [FIPS-198] is used. While the
While the current specification only provides full details for HMAC current specification only provides full details for HMAC
Authentication using the NIST SHA-1 algorithm (and its direct Authentication using the National Institute of Standards and
derivatives), this same basic process could be used with other Technology (NIST) SHA-1 algorithm (and its direct derivatives), this
cryptographic hash functions in future. Because the RIPv2 packet same basic process could be used with other cryptographic hash
is only hashed once, the overhead of the double hashing in this functions in the future. Because the RIPv2 packet is only hashed
process is negligible. once, the overhead of the double hashing in this process is
negligible.
The US NIST Secure Hash Standard (SHA-1), defined by The US NIST Secure Hash Standard (SHS), defined by [FIPS-180-2],
[FIPS-180-2], includes specifications for SHA-1, SHA-256, SHA-384, includes specifications for SHA-1, SHA-256, SHA-384, and SHA-512.
and SHA-512. This specification defines processing for each of these. This specification defines processing for each of these.
The output of the cryptographic computations (e.g. HMAC-SHA1) The output of the cryptographic computations (e.g., HMAC-SHA1) is NOT
is NOT truncated for RIPv2 Cryptographic Authentication. truncated for RIPv2 Cryptographic Authentication.
The Authentication Data length is equal to the Message Digest The Authentication Data Length is equal to the Message Digest Size
Size for the hash algorithm in use. for the hash algorithm in use.
Any key value known to be weak with SHA-1 MUST NOT be used with Any key value known to be weak with an algorithm defined by the NIST
this specification. US NIST is the authoritative source for public Secure Hash Standard MUST NOT be used with such an algorithm in an
information on weak keys for SHA-1. implementation of this specificaton. US NIST is the authoritative
source for public information on weak keys for those algorithms.
In the algorithm description below, the following nomenclature, which
is consistent with [FIPS-198], is used:
In the algorithm description below, the following nomenclature,
which is consistent with [FIPS-198] is used:
H is the specific hashing algorithm, H is the specific hashing algorithm,
for example SHA-1 or SHA-256. for example, SHA-1 or SHA-256.
Ko is the cryptographic key used with the hash algorithm. Ko is the cryptographic key used with the hash algorithm.
B is the block-size of H, measured in octets not bits. B is the block-size of H, measured in octets, not bits.
Note that B is the internal block size, Note that B is the internal block size, not the hash size.
not the hash size.
For SHA-1 and SHA-256: B == 64. For SHA-1 and SHA-256: B == 64.
For SHA-384 and SHA-512: B == 128 For SHA-384 and SHA-512: B == 128
L is the length of the hash, measured in octets, L is the length of the hash, measured in octets, not bits.
not bits. For example, with SHA-1, L == 20. For example, with SHA-1, L == 20.
XOR is the exclusive-or operation. XOR is the exclusive-or operation.
Opad is the hexadecimal value 0x5c repeated B times. Opad is the hexadecimal value 0x5c repeated B times.
Ipad is the hexadecimal value 0x36 repeated B times. Ipad is the hexadecimal value 0x36 repeated B times.
Apad is the hexadecimal value 0x878FE1F3 repeated (L/4) times. Apad is the hexadecimal value 0x878FE1F3 repeated (L/4) times.
(1) PREPARATION OF KEY (1) PREPARATION OF KEY
In this application, Ko is always L octets long. In this application, Ko is always L octets long.
If the Authentication Key is L octets long, then Ko is set equal If the Authentication Key is L octets long, then Ko is set equal
to the Authentication Key. If the Authentication Key is more to the Authentication Key. If the Authentication Key is more
than L octets long, then Ko is set to H(Authentication Key). If than L octets long, then Ko is set to H(Authentication Key). If
the Authentication Key is less than L octets long, then Ko is set the Authentication Key is less than L octets long, then Ko is set
to the Authentication Key with zeros appended to the end of the to the Authentication Key with zeros appended to the end of the
Authentication Key such that Ko is L octets long. Authentication Key such that Ko is L octets long.
(2) FIRST HASH (2) FIRST HASH
First, the RIPv2 packet's Authentication Data field is filled First, the RIPv2 packet's Authentication Data field is filled
with the value Apad. with the value Apad.
Then, a first hash, also known as the inner hash, is computed Then, a first hash, also known as the inner hash, is computed as
as follows: follows:
First-Hash = H(Ko XOR Ipad, (RIPv2 Packet)) First-Hash = H(Ko XOR Ipad || (RIPv2 Packet))
(3) SECOND HASH (3) SECOND HASH
Then a second hash, also known as the outer hash, is computed Then a second hash, also known as the outer hash, is computed as
as follows: follows:
Second-Hash = H(Ko XOR Opad, First-Hash) Second-Hash = H(Ko XOR Opad || First-Hash)
(4) RESULT (4) RESULT
The result Second-Hash becomes the Authentication Data that is The result Second-Hash becomes the authentication data that is
sent in the Authentication Data field of the RIPv2 packet. The sent in the Authentication Data field of the RIPv2 packet. The
length of the Authentication Data field is always identical to length of the Authentication Data field is always identical to
the message digest size of the hash function H that is being used. the message digest size of the hash function H that is being
used.
This also implies that use of hash functions with larger output This also implies that use of hash functions with larger output
sizes will also increase the size of the packet as transmitted on sizes will also increase the size of the packet as transmitted on
the wire. the wire.
3. Management Procedures 3. Management Procedures
Key management is an important component of this mechanism and Key management is an important component of this mechanism and proper
proper implementation is central to providing the intended level implementation is central to providing the intended level of risk
of risk reduction. reduction.
3.1. Key Management Requirements 3.1. Key Management Requirements
It is strongly desirable that a hypothetical security breach in It is strongly desirable that a hypothetical security breach in one
one Internet protocol not automatically compromise other Internet Internet protocol not automatically compromise other Internet
protocols. The Authentication Key of this specification SHOULD NOT protocols. The Authentication Key of this specification SHOULD NOT
be configured or stored using protocols (e.g. RADIUS) or cryptographic be configured or stored using protocols (e.g., RADIUS) or
algorithms that have known flaws. cryptographic algorithms that have known flaws.
Implementations MUST support the storage of more than one key at the Implementations MUST support the storage of more than one key at the
same time, although it is recognized that only one key will normally same time, although it is recognized that only one key will normally
be active on an interface. Implementations MUST associate a specific be active on an interface. Implementations MUST associate a specific
Security Association lifetime (i.e., date/time first valid and Security Association lifetime (i.e., date/time first valid and
date/time no longer valid) and a key identifier with each key. date/time no longer valid) and a key identifier with each key.
Implementations also MUST support manual key distribution. An Implementations also MUST support manual key distribution. An
example of manual key distribution is having the privileged user example of manual key distribution is having the privileged user
typing in the key, key lifetime, and key identifier on the router typing in the key, key lifetime, and key identifier on the router
console. An operator may configure the Security Association lifetime console. An operator may configure the Security Association lifetime
to infinite, which means that the session is never rekeyed. However, to infinite, which means that the session is never rekeyed. However,
instead, it is strongly recommended that operators rekey regularly, instead, it is strongly recommended that operators rekey regularly,
using a moderately short Security Association lifetime (e.g. 24 hours). using a moderately short Security Association lifetime (e.g., 24
hours).
This specification requires support for at least two authentication This specification requires support for at least two authentication
algorithms, so the implementation MUST require that the authentication algorithms, so the implementation MUST require that the
algorithm be specified for each key when the other key information authentication algorithm be specified for each key when the other key
is entered. Manual deletion of active Security Associations MUST information is entered. Manual deletion of active Security
be supported. Associations MUST be supported.
It is likely that the IETF will define a standard key management It is likely that the IETF will define a standard key management
protocol for use with routing protocols. It is strongly desirable to protocol for use with routing protocols. It is strongly desirable to
use an IETF standards-track key management protocol to distribute use an IETF standards-track key management protocol to distribute
RIPv2 Authentication Keys among communicating RIPv2 implementations. RIPv2 Authentication Keys among communicating RIPv2 implementations.
Such a protocol would provide scalability and significantly reduce the Such a protocol would provide scalability and significantly reduce
human administrative burden. The Key-ID field can be used as a hook the human administrative burden. The Key-ID field can be used as a
between RIPv2 and such a future protocol. hook between RIPv2 and such a future protocol.
Key management protocols have a long history of subtle flaws that are Key management protocols have a long history of subtle flaws that are
often discovered long after the protocol was first described in often discovered long after the protocol was first described in
public. To avoid having to change all RIPv2 implementations should public. To avoid having to change all RIPv2 implementations should
such a flaw be discovered, integrated key management protocol such a flaw be discovered, integrated key management protocol
techniques were deliberately omitted from this specification. techniques were deliberately omitted from this specification.
3.2. Key Management Procedures 3.2. Key Management Procedures
As with all security methods using keys, it is necessary to change As with all security methods using keys, it is necessary to change
the RIPv2 Authentication Key on a regular basis. To maintain the RIPv2 Authentication Key on a regular basis. To maintain routing
routing stability during such changes, implementations MUST be able stability during such changes, implementations MUST be able to store
to store and use more than one RIPv2 Authentication Key on a and use more than one RIPv2 Authentication Key on a given interface
given interface at the same time. at the same time.
Each key will have its own Key Identifier (KEY-ID), which is stored Each key will have its own Key Identifier (KEY-ID), which is stored
locally. The combination of the Key Identifier and the interface locally. The combination of the Key Identifier and the interface
associated with the message uniquely identifies the Authentication associated with the message uniquely identifies the Authentication
Algorithm and RIPv2 Authentication Key in use. Algorithm and RIPv2 Authentication Key in use.
As noted above in Section 2.3.1, the party creating the RIPv2 message As noted above in Section 2.3.1, the party creating the RIPv2 message
will select a valid RIPv2 Security Association from the set of valid will select a valid RIPv2 Security Association from the set of valid
RIPv2 Security Associations for that interface. The receiver MUST use RIPv2 Security Associations for that interface. The receiver MUST
the Key Identifier and receiving interface to determine which RIPv2 use the Key Identifier and receiving interface to determine which
Security Association to use for authentication of the received RIPv2 Security Association to use for authentication of the received
message. More than one RIPv2 Security Association MAY be associated message. More than one RIPv2 Security Association MAY be associated
with an interface at the same time. The receiver MUST NOT simply try with an interface at the same time. The receiver MUST NOT simply try
all RIPv2 Security Associations (i.e. keys) that might be configured all RIPv2 Security Associations (i.e., keys) that might be configured
for RIPv2 on the receiving interface, as that creates an easily for RIPv2 on the receiving interface, as that creates an easily
exploited denial-of-service attack on the RIP subsystem of the exploited denial-of-service attack on the RIP subsystem of the
receiver. (At least one widely used implementation of the previous receiver. (At least one widely used implementation of the previous
version of this specification violates these requirements as of the version of this specification violates these requirements as of the
publication date of this document and has consequent security publication date of this document and has consequent security
vulnerabilities.) vulnerabilities.)
Hence it is possible to have fairly smooth RIPv2 Security Association Hence, it is possible to have fairly smooth RIPv2 Security
(i.e. key) rollovers, without losing legitimate RIPv2 messages due to Association (i.e., key) rollovers, without losing legitimate RIPv2
an invalid shared key and without requiring people to change all the messages due to an invalid shared key and without requiring people to
keys at once. To ensure a smooth rollover, each communicating RIPv2 change all the keys at once. To ensure a smooth rollover, each
system must be updated with the new RIPv2 Security Association communicating RIPv2 system must be updated with the new RIPv2
(including the new key) several minutes before the current RIPv2 Security Association (including the new key) several minutes before
Security Association will expire and several minutes before the new the current RIPv2 Security Association will expire and several
RIPv2 Security Association lifetime begins. Also, the new RIPv2 minutes before the new RIPv2 Security Association lifetime begins.
Security Association should have a lifetime that starts several Also, the new RIPv2 Security Association should have a lifetime that
minutes before the old RIPv2 Security Association expires. This gives starts several minutes before the old RIPv2 Security Association
time for each system to learn of the new security association before expires. This gives time for each system to learn of the new
that security association will be used. It also ensures that the new security association before that security association will be used.
security association will begin use and the current security It also ensures that the new security association will begin use and
association will go out of use before the current security the current security association will go out of use before the
association's lifetime expires. For the duration of the overlap in current security association's lifetime expires. For the duration of
security association lifetimes, a system may receive messages the overlap in security association lifetimes, a system may receive
corresponding to either security association and successfully messages corresponding to either security association and
authenticate the message. The Key-ID in the received message is used successfully authenticate the message. The Key-ID in the received
to select the appropriate security association (i.e. key) to be used message is used to select the appropriate security association (i.e.,
for authentication. key) to be used for authentication.
4. Conformance Requirements 4. Conformance Requirements
For this specification, the term "conformance" has identical meaning For this specification, the term "conformance" has identical meaning
to the phrase "full compliance". to the phrase "full compliance".
The Keyed MD5 authentication algorithm and the HMAC-SHA1 algorithm The Keyed MD5 authentication algorithm and the HMAC-SHA1 algorithm
MUST be implemented by all conforming implementations. In addition, MUST be implemented by all conforming implementations. In addition,
the HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 algorithms SHOULD be the HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 algorithms SHOULD be
implemented. MD5 is defined in [Rivest92]. SHA-1, SHA-256, SHA-384, implemented. MD5 is defined in [Rivest92]. SHA-1, SHA-256, SHA-384,
and SHA-512 have been defined by the (US) National Institute of and SHA-512 have been defined by the US NIST in [FIPS-180-2].
Standards & Technology (NIST) in [FIPS-180-2].
A conforming implementation MAY also support additional authentication A conforming implementation MAY also support additional
algorithms, provided those additional algorithms are publicly and authentication algorithms, provided those additional algorithms are
openly specified. publicly and openly specified.
Manual key distribution as described above MUST be supported by all Manual key distribution as described above MUST be supported by all
conforming implementations. All implementations MUST support the conforming implementations. All implementations MUST support the
smooth key rollover described under "Key Management Procedures". This smooth key rollover described under "Key Management Procedures".
also means that implementations MUST support at least 2 concurrent This also means that implementations MUST support at least 2
RIPv2 Security Associations. concurrent RIPv2 Security Associations.
The user documentation provided with the implementation ought to The user documentation provided with the implementation ought to
contain clear instructions on how to configure the implementation such contain clear instructions on how to configure the implementation
that smooth key rollover occurs successfully. such that smooth key rollover occurs successfully.
Implementations SHOULD support a standard key management protocol Implementations SHOULD support a standard key management protocol for
for secure distribution of RIPv2 Authentication Keys once such a secure distribution of RIPv2 Authentication Keys once such a key
key management protocol is standardized by the IETF. management protocol is standardized by the IETF.
The Security Considerations section of this document is an integral The Security Considerations section of this document is an integral
part of the specification, not just a discussion of the protocol. part of the specification, not just a discussion of the protocol.
5. Security Considerations 5. Security Considerations
This entire memo describes and specifies an authentication mechanism This entire memo describes and specifies an authentication mechanism
for the RIPv2 routing protocol that is believed to be secure against for the RIPv2 routing protocol that is believed to be secure against
passive attacks. The term "passive attack" is defined in passive attacks. The term "passive attack" is defined in RFC 1704
RFC-1704. [HA94] The analysis contained in RFC-1704 motivated this [HA94]. The analysis contained in RFC 1704 motivated this work.
work. Passive attacks are clearly widespread in the Internet at Passive attacks are clearly widespread in the Internet at present
present.[HA94] [HA94].
Protection against active attacks is incomplete in this current Protection against active attacks is incomplete in this current
specification. The main issue relative to active attacks lies in the specification. The main issue relative to active attacks lies in the
need to support the case where another router has recently rebooted need to support the case where another router has recently rebooted
and that router lacks the non-volatile storage needed to remember the and that router lacks the non-volatile storage needed to remember the
RIPv2 Security Association(s) and last received RIPv2 sequence RIPv2 Security Association(s) and last received RIPv2 sequence
number(s) across that reboot. number(s) across that reboot.
5.1 Known Pathological Cases 5.1. Known Pathological Cases
Two known pathological cases exist which MUST be handled by Two known pathological cases exist that MUST be handled by
implementations. Both of these are failures of the network manager. implementations. Both of these are failures of the network manager.
Each of these should be exceedingly rare in normal operation. Each of these should be exceedingly rare in normal operation.
(1) During key rollover, devices might exist which have not yet been (1) During key rollover, devices might exist that have not yet been
successfully configured with the new key. Therefore, routers SHOULD successfully configured with the new key. Therefore, routers
implement an algorithm that detects the set of RIPv2 Security SHOULD implement an algorithm that detects the set of RIPv2
Associations being used by its neighbors, and transmits its messages Security Associations being used by its neighbors, and transmit
using both the new and old RIPv2 Security Associations (i.e. keys) its messages using both the new and old RIPv2 Security
until all of the neighbors are using the new security association or Associations (i.e., keys) until all of the neighbors are using
the lifetime of the old security association expires. Under normal the new security association or the lifetime of the old security
circumstances, this elevated transmission rate will exist for a association expires. Under normal circumstances, this elevated
single RIP update interval. transmission rate will exist for a single RIP update interval.
(2) In the event that the last RIPv2 Security Association of an (2) In the event that the last RIPv2 Security Association of an
interface expires, it is unacceptable to revert to an interface expires, it is unacceptable to revert to an
unauthenticated condition, and not advisable to disrupt routing. unauthenticated condition, and not advisable to disrupt routing.
Therefore, the router MUST send a "last RIPv2 Security Association Therefore, the router MUST send a "last RIPv2 Security
expiration" notification to the network manager (e.g. via SYSLOG, Association expiration" notification to the network manager
SNMP, and/or other means) and SHOULD treat that last Security (e.g., via SYSLOG, SNMP, and/or other means) and SHOULD treat
Association as having an infinite lifetime until the lifetime that last Security Association as having an infinite lifetime
is extended, the Security Association is deleted by network until the lifetime is extended, the Security Association is
management, or a new security association is configured. deleted by network management, or a new security association is
configured.
In some circumstances, the practice described in (2) can leave an In some circumstances, the practice described in (2) can leave an
opening to an active attack on the RIPv2 routing subsystem. opening to an active attack on the RIPv2 routing subsystem.
Therefore, any actual occurance of a RIPv2 Security Association Therefore, any actual occurrence of a RIPv2 Security Association
expiration MUST cause a security event to be logged by the expiration MUST cause a security event to be logged by the
implementation. This log item MUST include at least note that the implementation. This log item MUST include at least a note that the
RIPv2 Authentication Key expired, the RIP routing protocol instance(s) RIPv2 Authentication Key expired, the RIP routing protocol
affected, the routing interfaces affected, the Key-ID that is instance(s) affected, the routing interfaces affected, the Key-ID
affected, and the current date/time. Operators are encouraged to that is affected, and the current date/time. Operators are
check such logs as an operational security practice to help detect encouraged to check such logs as an operational security practice to
help detect active attacks on the RIPv2 routing subsystem. Further,
active attacks on the RIPv2 routing subsystem. Further, implementations SHOULD provide a configuration knob ("fail secure")
implementations SHOULD provide a configuration knob ("fail secure") to to let a network operator prefer to have the RIPv2 routing fail when
let a network operator prefer to have the RIPv2 routing fail when the the last key expires, rather than continue using RIPv2 in an insecure
last key expires, rather than continue using RIPv2 in an insecure
manner. manner.
5.2 Network Management Considerations 5.2 Network Management Considerations
Also, the use of SNMP, even SNMPv3 with cryptographic Also, the use of SNMP, even SNMPv3 with cryptographic authentication
authentication and cryptographic confidentiality enabled, to modify or and cryptographic confidentiality enabled, to modify or configure the
configure the RIPv2 Security Associations, or any component of the RIPv2 Security Associations, or any component of the security
security association (for example the cryptographic key), is NOT association (for example, the cryptographic key), is NOT RECOMMENDED.
RECOMMENDED. This practice would create a potential for a cascading This practice would create a potential for a cascading vulnerability,
vulnerability, whereby a compromise in the SNMP security whereby a compromise in the SNMP security implementation would
implementation would necessarily lead to a compromise not only of the necessarily lead to a compromise not only of the local routing table
local routing table (which could be accessed via SNMP) but also of all (which could be accessed via SNMP) but also of all other routers that
other routers that receive RIPv2 packets (directly or indirectly) from receive RIPv2 packets (directly or indirectly) from the compromised
the compromised router. router.
Similarly, the use of protocols not designed and evaluated for Similarly, the use of protocols not designed and evaluated for use in
use in key management (e.g. RADIUS, Diameter) to configure the key management (e.g., RADIUS, Diameter) to configure the security
security association is also NOT RECOMMENDED. Reading the Security association is also NOT RECOMMENDED. Reading the Security
Associations via SNMP is allowed, but the information is to be treated Associations via SNMP is allowed, but the information is to be
as security-sensitive and protected by using the priv mode. treated as security-sensitive and protected by using the priv mode.
Also, the use of SNMP to configure which form of RIPv2 Also, the use of SNMP to configure which form of RIPv2 authentication
authentication is in use is also NOT RECOMMENDED because of a similar is in use is also NOT RECOMMENDED because of a similar cascading
cascading failure issue. Any future revision of the RIPv2 Management failure issue. Any future revision of the RIPv2 Management
Information Base (MIB) [MB94] should consider making the Information Base (MIB) [MB94] should consider making the
rip2IfConfAuthType object read-only. Further, this object would need a rip2IfConfAuthType object read-only. Further, this object would need
new enum value to accomodate the RIPv2 cryptographic authentication a new enum value to accommodate the RIPv2 cryptographic
type. In addition, the compliance statement for this MIB does not authentication type. In addition, the compliance statement for this
have a MIN-ACCESS for this object. At a minimum, if the MIB is MIB does not have a MIN-ACCESS for this object. At a minimum, if the
updated, a new compliance statement SHOULD be written for this object MIB is updated, a new compliance statement SHOULD be written for this
that allows this object to be implemented as read-only. For the object that allows this object to be implemented as read-only. For
rip2ifConfAuthKey object, since this object always returns ''H when the rip2ifConfAuthKey object, since this object always returns ''H
read, the object's MIN-ACCESS in any revised compliance statement when read, the object's MIN-ACCESS in any revised compliance
SHOULD be not-accessible if the MIB is updated. statement SHOULD be not-accessible if the MIB is updated.
Further, for similar reasons, any future revisions to the Further, for similar reasons, any future revisions to the RIPv2
RIPv2 Management Information Base (MIB) SHOULD deprecate or omit Management Information Base (MIB) SHOULD deprecate or omit any
any objects that would permit the writing of any RIPv2 Security objects that would permit the writing of any RIPv2 Security
Association or of any RIPv2 Security Association component Association or RIPv2 Security Association component (e.g., the
(e.g. the cryptographic key). cryptographic key).
Also, it is RECOMMENDED that any future revisions to the RIPv2 Also, it is RECOMMENDED that any future revisions to the RIPv2
Management Information Base (MIB) consider adding MIB objects to hold Management Information Base (MIB) consider adding MIB objects to hold
information about any RIPv2 security events that might have occurred information about any RIPv2 security events that might have occurred,
and MIB objects that could be used to read the set of security events and MIB objects that could be used to read the set of security events
that have been logged by the RIPv2 subsystem. For each security event that have been logged by the RIPv2 subsystem. For each security
mentioned in this document, it is also RECOMMENDED that appropriate event mentioned in this document, it is also RECOMMENDED that
notifications be included, with a MAX-ACCESS of Accessible-for-notify, appropriate notifications be included, with a MAX-ACCESS of
in any future versions of the RIPv2 MIB module. Accessible-for-notify, in any future versions of the RIPv2 MIB
module.
5.3 Key Management Considerations 5.3. Key Management Considerations
For the past several years, manual configuration (e.g. via a For the past several years, manual configuration (e.g., via a
console) has been commonly used to create and modify RIPv2 Security console) has been commonly used to create and modify RIPv2 Security
Associations. There are a number of large-scale RIP deployments today Associations. There are a number of large-scale RIP deployments
that successfully use manual configuration of RIPv2 Security today that successfully use manual configuration of RIPv2 Security
Associations. There are also sites that use scripts (e.g. combining Associations. There are also sites that use scripts (e.g., combining
Tcl/Expect, PERL, and SSHv2) with a site-specific configuration Tcl/Expect, PERL, and SSHv2) with a site-specific configuration
database and secure console connections to dynamically manage all database and secure console connections to dynamically manage all
aspects of their router configurations, including their RIPv2 Security aspects of their router configurations, including their RIPv2
Associations. This last approach is similar to the current IETF Security Associations. This last approach is similar to the current
approach to Network Configuration (NetConf) standards. IETF approach to Network Configuration (NetConf) standards.
Recent IETF Multicast Security Working Group (MSec) efforts Recent IETF Multicast Security (MSEC) working group efforts into
into multicast key manaagement appear promising. Several large RIPv2 multicast key management appear promising. Several large RIPv2
deployments happen to also have deployed the Kerberos authentication deployments happen to also have deployed the Kerberos authentication
system. Recent IETF work into the use of Kerberos for Internet Key system. Recent IETF work into the use of Kerberos for Internet Key
Negotiation (KINK) also seems relevant; one might use Kerberos to Negotiation (KINK) also seems relevant; one might use Kerberos to
support RIPv2 key management functions for use at sites that have support RIPv2 key management functions for use at sites that have
already deployed Kerberos. It is hoped that in future the IETF will already deployed Kerberos. It is hoped that in the future the IETF
standardise a key management protocol suitable for managing RIPv2 will standardize a key management protocol suitable for managing
Security Associations. RIPv2 Security Associations.
5.4 Assurance Considerations 5.4. Assurance Considerations
Users need to understand that the quality of the security Users need to understand that the quality of the security provided by
provided by this mechanism depends completely on the strength of the this mechanism depends completely on the strength of the implemented
implemented authentication algorithms, the strength of the key being authentication algorithms, the strength of the key being used, and
used, and the correct implementation of the security mechanism in all the correct implementation of the security mechanism in all
communicating RIPv2 implementations. This mechanism also depends on communicating RIPv2 implementations. This mechanism also depends on
the RIPv2 Authentication Key being kept confidential by all parties. the RIPv2 Authentication Key being kept confidential by all parties.
If any of these incorrect or insufficiently secure, then no real If any of these are incorrect or insufficiently secure, then no real
security will be provided to the users of this mechanism. security will be provided to the users of this mechanism.
Use of high assurance development methods is RECOMMENDED for Use of high-assurance development methods is RECOMMENDED for
implementations of this specification, in order to reduce the risk of implementations of this specification, in order to reduce the risk of
subtle implementation flaws that might adversely impact the subtle implementation flaws that might adversely impact the
operational risk reduction that this specification seeks to provide. operational risk reduction that this specification seeks to provide.
5.5 Confidentiality & Traffic Analysis Considerations 5.5. Confidentiality and Traffic Analysis Considerations
Confidentiality is not provided by this mechanism. It is Confidentiality is not provided by this mechanism. It is generally
generally considered that an IP routing protocol does not require considered that an IP routing protocol does not require
confidentiality, as the purpose of any routing protocols is to confidentiality, as the purpose of any routing protocols is to
disseminate information about the topology of the network. disseminate information about the topology of the network.
Protection against traffic analysis is also not provided. Protection against traffic analysis is also not provided. Mechanisms
Mechanisms such as bulk link encryption SHOULD be used when protection such as bulk link encryption SHOULD be used when protection against
against traffic analysis is required. [CKHD89] traffic analysis is required [CKHD89].
5.6 Other Security Considerations 5.6. Other Security Considerations
Separately, the receipt of a RIPv2 packet using cryptographic Separately, the receipt of a RIPv2 packet using cryptographic
authentication but containing an invalid or unknown Key-ID value might authentication but containing an invalid or unknown Key-ID value
indicate an active attack on the RIP routing subsystem and is a might indicate an active attack on the RIP routing subsystem and is a
significant security event. Therefore, any actual receipt of a RIPv2 significant security event. Therefore, any actual receipt of a RIPv2
packet using cryptographic authentication and containing an unknown, packet using cryptographic authentication and containing an unknown,
expired, or otherwise invalid KEY-ID value SHOULD cause a security expired, or otherwise invalid KEY-ID value SHOULD cause a security
event to be logged by the implementation. This log item SHOULD event to be logged by the implementation. This log item SHOULD
include at least the fact that the invalid KEY-ID was received, the include at least the fact that the invalid KEY-ID was received, the
source IP address of the packet containing the invalid KEY-ID, the source IP address of the packet containing the invalid KEY-ID, the
interface(s) the packet was received on, the KEY-ID received, and the interface(s) the packet was received on, the KEY-ID received, and the
current date/time. current date/time.
A subtle user-interface consideration also should be noted. A subtle user-interface consideration also should be noted. If a
If a user-interface only permits the entry of human-readable text user interface only permits the entry of human-readable text (e.g., a
(e.g. a password in US-ASCII format) for use as a cryptographic key, password in US-ASCII format) for use as a cryptographic key,
significant numbers of bits of the cryptographic key in use become significant numbers of bits of the cryptographic key in use become
predictable, thereby reducing the strength of the key in this context. predictable, thereby reducing the strength of the key in this
For this reason, implementations of this specification SHOULD support context. For this reason, implementations of this specification
the entry of RIPv2 cryptographic authentication keys in hexadecimal SHOULD support the entry of RIPv2 cryptographic authentication keys
format. in hexadecimal format.
5.7 Future Security Directions 5.7. Future Security Directions
Specification and deployment of a standards-track key Specification and deployment of a standards-track key management
management protocol that supporting this RIPv2 cryptographic protocol that supports this RIPv2 cryptographic authentication
authentication mechanism would be a significant next step in mechanism would be a significant next step in operational risk
operational risk reduction and might actually increase the ease of reduction and might actually increase the ease of deployment and
deployment and operation of this mechanism. Such specification is operation of this mechanism. Such specification is beyond the scope
beyond the scope of this document. Recent IETF work in MSEC and KINK of this document. Recent IETF work in MSEC and KINK working groups
appears promising in this regard. Recent IETF work in NetConf towards appears promising in this regard. Recent IETF work in the NETCONF
standardising methods for secure configuration management of routers working group towards standardizing methods for secure configuration
is also relevant. management of routers is also relevant.
Finally, we observe that this mechanism is not the final word Finally, we observe that this mechanism is not the final word on
on RIPv2 authentication. Rather, it is believed that this particular RIPv2 authentication. Rather, it is believed that this particular
mechanism represents a significant risk reduction over previous mechanism represents a significant risk reduction over previous
methods (e.g. plain-text passwords), while remaining straight-forward methods (e.g., plaintext passwords), while remaining straightforward
to implement correctly and also straight-forward to deploy. to implement correctly and also straightforward to deploy.
User communities that believe this mechanism is not adequate
to their needs are encouraged to consider using digital signatures
with RIPv2. [MBW97] specifies the use of OSPF with Digital
Signatures; that document might be a starting point for creating such
a specification for the RIPv2 protocol. Digital signatures are
significantly more expensive computationally and are also
significantly more difficult to deploy operationally, as compared with
the mechanism specified here. However, it appears likely that the
much of the mechanism in this document could be reused with digital
signatures.
6. IANA Considerations
No IANA protocol parameter registries are created or modified User communities that believe this mechanism is not adequate to their
by this specification. needs are encouraged to consider using digital signatures with RIPv2.
[MBW97] specifies the use of OSPF with Digital signatures; that
document might be a starting point for creating such a specification
for the RIPv2 protocol. Digital signatures are significantly more
expensive computationally and are also significantly more difficult
to deploy operationally, as compared with the mechanism specified
here. However, it appears likely that much of the mechanism in this
document could be reused with digital signatures.
Acknowledgments 6. Acknowledgments
Fred Baker was co-author of the earlier RIPv2 MD5 Authentication Fred Baker was co-author of the earlier RIPv2 MD5 Authentication
document. [AB97] This document is a direct derivative of that earlier document [AB97]. This document is a direct derivative of that
document, though it has been significantly reworked. The current earlier document, though it has been significantly reworked. The
authors would like to thank Bill Burr, Tim Polk, John Kelsey, and current authors would like to thank Bill Burr, Tim Polk, John Kelsey,
Morris Dworkin of (US) NIST for review of drafts of this document. and Morris Dworkin of (US) NIST for review of versions of this
document.
Informative References
[AB97] Atkinson, R. & F. Baker, "RIPv2 MD5 Authentication",
RFC-2082, January 1997.
[Bell89] S. Bellovin, "Security Problems in the TCP/IP Protocol 7. Normative References
Suite", ACM Computer Communications Review, Volume 19,
Number 2, pp. 32-48, April 1989.
[CKHD89] Cole Jr, Raymond, Donald Kallgren, Richard Hale, & [BCP14] Bradner, S., "Key words for use in RFCs to Indicate
John R. Davis, "Multilevel Secure Mixed-Media Requirement Levels", BCP 14, RFC 2119, March 1997.
Communication Networks", Proceedings of the IEEE Military
Communications Conference (MILCOM '89), IEEE, 1989.
[Dobb96a] Dobbertin, H., "Cryptanalysis of MD5 Compress", Technical [Mal98] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November
Report, 2 May 1996. (Presented at Rump Session of 1998.
EuroCrypt 1996.)
[Dobb96b] Dobbertin, H., "The Status of MD5 After a Recent Attack", [FIPS-180-2] National Institute of Standards and Technology, "Secure
CryptoBytes, Vol. 2, No. 2, Summer 1996. Hash Standard", FIPS PUB 180-2, August 2002,
<http://csrc.nist.gov/publications/fips/fips180-2/
fips180-2.pdf>.
[ECS94] Eastlake 3rd, D, S. Crocker, & J. Schiller, "Randomness [FIPS-198] National Institute of Standards and Technology, "The
Recommendations for Security", RFC-1750, December 1994. Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB
198, March 2002, <http://csrc.nist.gov/publications/
fips/fips198/fips-198a.pdf>.
[HA94] N. Haller & R. Atkinson, "On Internet Authentication", 8. Informative References
RFC-1704, October 1994.
[KMC97] H. Krawczyk, M. Bellare, & R. Canetti, "Keyed-Hashing for [AB97] Baker, F. and R. Atkinson, "RIP-2 MD5 Authentication",
Message Authentication", RFC-2104, February 1997. RFC 2082, January 1997.
[Mal94] Malkin, G, "RIP version 2 - Carrying Additional [Bell89] S. Bellovin, "Security Problems in the TCP/IP Protocol
Information", RFC-1723, November 1994. Suite", ACM Computer Communications Review, Volume 19,
Number 2, pp. 32-48, April 1989.
[MB94] Malkin, G., and F. Baker, "RIP Version 2 MIB Extension", [CKHD89] Cole Jr, Raymond, Donald Kallgren, Richard Hale, and
RFC-1724, November 1994. John R. Davis, "Multilevel Secure Mixed-Media
Communication Networks", Proceedings of the IEEE
Military Communications Conference (MILCOM '89), IEEE,
1989.
[MBW97] Murphy, S., M. Badger, and B. Wellington, "OSPF with [Dobb96a] Dobbertin, H., "Cryptanalysis of MD5 Compress",
Digital Signatures", RFC-2154, June 1997. Technical Report, 2 May 1996. (Presented at Rump
Session of EuroCrypt 1996.)
[Rivest92] Rivest, R., "The MD5 Message-Digest Algorithm", [Dobb96b] Dobbertin, H., "The Status of MD5 After a Recent
RFC-1321, April 1992. Attack", CryptoBytes, Vol. 2, No. 2, Summer 1996.
Normative References [ESC05] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC
4086, June 2005.
[Mal98] Malkin, G., "RIP Version 2", RFC-2453, November 1998. [HA94] Haller, N. and R. Atkinson, "On Internet
Authentication", RFC 1704, October 1994.
[FIPS-180-2] US National Institute of Standards & Technology (NIST), [KMC97] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
"Secure Hash Specification", US Federal Information Processing Keyed-Hashing for Message Authentication", RFC 2104,
Standard 180-2, NIST, Gaithersburg, MD, USA, 1 August 2002. February 1997.
http://csrc.nist.gov/cryptval
[FIPS-198] US National Institute of Standards & Technology (NIST), [Mal94] Malkin, G., "RIP Version 2 - Carrying Additional
"The Keyed-Hash Message Authentication Code (HMAC)", Information", RFC 1723, November 1994.
US Federal Information Processing Standard 198, NIST,
Gaithersburg, MD, USA, 6 March 2002.
http://csrc.nist.gov/cryptval
COPYRIGHT NOTICE [MB94] Malkin, G. and F. Baker, "RIP Version 2 MIB Extension",
RFC 1724, November 1994.
Copyright (C) The Internet Society 2006. This document is subject to [MBW97] Murphy, S., Badger, M., and B. Wellington, "OSPF with
the rights, licenses and restrictions contained in BCP 78, and except Digital Signatures", RFC 2154, June 1997.
as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an [Rivest92] Rivest, R., "The MD5 Message-Digest Algorithm", RFC
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1321, April 1992.
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Authors' Addresses Authors' Addresses
R. Atkinson R. Atkinson
Extreme Networks Extreme Networks
3585 Monroe Street 3585 Monroe Street
Santa Clara, CA Santa Clara, CA 95051
USA 95051 USA
Phone: +1 (408) 579-2800 Phone: +1 (408) 579-2800
EMail: rja@extremenetworks.com EMail: rja@extremenetworks.com
M. Fanto M. Fanto
(US) National Institute of Standards and Technology (US) National Institute of Standards and Technology
Gaithersburg, MD Gaithersburg, MD 20878
USA 20878 USA
Phone: +1 (301) 975-2000 Phone: +1 (301) 975-2000
EMail: matthew.fanto@nist.gov EMail: mattjf@umd.edu
Web: http://csrc.nist.gov Web: http://csrc.nist.gov
Filename: draft-rja-ripv2-auth-06.txt Full Copyright Statement
Expires: 7 APR 2007
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 165 change blocks. 
555 lines changed or deleted 529 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/