RIP-2 MD5 Authentication
obsoleted by
- rfc-4822 — RIPv2 Cryptographic Authentication
Extracted elements (27)
Integrated key management protocol techniques were deliberately omitted from this specification. Key management protocols have a history of subtle flaws discovered long after publication; decoupling key management avoids forcing changes to all RIP-2 implementations should such a flaw be discovered. The Key-ID field serves as a hook for a future standard key management protocol.
Keyed MD5 was selected because it was already in use for OSPF cryptographic authentication and was therefore already present in routers. A similar approach had also been standardized for IP-layer authentication (IP Authentication Header, RFC 1826).
The mechanism is designed to be algorithm-independent: the Auth Data Length field permits substituting other algorithms (e.g., Keyed SHA) for Keyed MD5, and the Key-ID field identifies both the key and the algorithm in implementations supporting multiple algorithms.
The mechanism transmits the output of an authentication algorithm (Keyed MD5) rather than the secret key itself. This one-way function ensures the RIP-2 Authentication Key is never sent over the network in the clear, protecting against the passive eavesdropping attacks widespread in the Internet.
The RIP-2 header's packet length field indicates only the standard RIP-2 portion of the packet (not including the authentication trailer). The Authentication Data Offset field provides the byte offset from the RIP-2 header to the MD5 digest, enabling consistent parsing regardless of future trailer field additions.
In the event that the last key associated with an interface expires, it is unacceptable to revert to an unauthenticated condition. The router should notify the network manager and treat the key as having an infinite lifetime until a new key is configured, to avoid disrupting routing.
To maintain routing stability during key rollovers, each communicating RIP-2 system must be updated with the new key several minutes before the current key expires and before the new key lifetime begins. During the overlap period, a system may receive and authenticate messages using either key, selected by Key-ID.
A router that has forgotten its current sequence number but remembers its key and Key-ID MUST send its first packet with a sequence number of zero. This creates a small window for replay attacks, so vendors are encouraged to provide stable storage for sequence numbers.
If more than one authentication algorithm is supported, the implementation MUST require that the algorithm be specified for each key at the time the key information is entered. Expired keys MAY be deleted automatically; manual deletion of active keys SHOULD also be supported.
Implementations MUST support the storage of more than one key at the same time per interface, MUST associate a specific lifetime (date/time first valid and date/time no longer valid) and a key identifier with each key, and MUST support manual key distribution via operator console.
The 32-bit sequence number MUST be non-decreasing for all messages sent with the same Key ID. This provides protection against replay attacks; a message with a lower sequence number than the last received from a known neighbor is discarded unprocessed.
The Authentication Key SHOULD NOT be stored using protocols or algorithms that have known flaws, to prevent a security breach in one protocol from automatically compromising RIP-2 authentication.
The Keyed MD5 authentication algorithm MUST be implemented by all conforming implementations. All implementations MUST support manual key distribution and MUST support the smooth key rollover procedure.
The UDP checksum MAY be set to zero when using Keyed MD5 authentication, as the integrity protection is provided by the MD5 digest mechanism itself.
To ensure smooth key rollover, routers SHOULD implement an algorithm that detects which keys neighbors are using, and transmit messages using both the old and new keys until all neighbors have adopted the new key or the old key's lifetime expires.
User documentation provided with the implementation MUST contain clear instructions on how to ensure that smooth key rollover occurs.
When connectivity to a neighbor has been lost, the receiver SHOULD be ready to accept either a message with a sequence number of zero or a message with a higher sequence number than the last received, to handle sequence number resets after router restarts.
The Authentication Data Length is an unsigned 8-bit field specifying the length in octets of the trailing Authentication Data field. This field enables algorithm substitution (e.g., Keyed SHA instead of Keyed MD5) by signaling the digest output size.
The Authentication Type field value 3 identifies Keyed Message Digest authentication, distinguishing it from value 1 (IP Route) and value 2 (Password). This type triggers the changed PDU format and processing described in this specification.
The Key Identifier (Key-ID) is an unsigned 8-bit field that identifies the key used to create the Authentication Data. In implementations supporting multiple authentication algorithms, the Key-ID also implicitly identifies the algorithm in use. A key is associated with a specific interface.
Compromise of SNMP security has the necessary result that RIP-2 configuration parameters manageable via SNMP — including the routing table and Authentication Key — may be compromised. Changing Authentication Keys using non-encrypted SNMP is no more secure than sending passwords in the clear.
Replay attacks are possible until the sequence number changes. A forgotten sequence number forces reset to zero, creating a small replay window. Vendors are encouraged to provide stable storage for keys, key lifetimes, Key-IDs, and sequence numbers to minimize this exposure.
The quality of security depends entirely on the strength of the authentication algorithm, the strength of the key, correct implementation in all communicating RIP-2 systems, and keeping the Authentication Key confidential. Compromise of any of these factors eliminates the security guarantee.
This mechanism does not provide confidentiality (messages remain in the clear) and does not protect against traffic analysis. IP-layer encryption (RFC 1827) or bulk link encryption may be used to address these gaps if needed.
Message reception processing: (1) set aside the received digest; (2) determine algorithm and key from Key-ID; (3) write the authentication key into the packet at the indicated offset; (4) add padding; (5) compute new digest. If computed digest does not match or sequence number is non-advancing for a known neighbor, discard the message unprocessed.
The Authentication Data trailer is appended after the RIP-2 data, preceded by a 0xFFFF marker and 0x01 type byte. When Keyed MD5 is used, the Authentication Data is 16 bytes. The MD5 computation appends 16 bytes of secret key, RFC 1321 padding, and a 64-bit message length field in memory but does not transmit the pad.
The RIP-2 authentication header when using Keyed Message Digest (type 3) reuses the 16-byte authentication password field to encode: a 16-bit packet offset to the digest, an 8-bit Key ID, an 8-bit Authentication Data Length, and a 32-bit non-decreasing sequence number, followed by two reserved zero 32-bit words.