RFC 4822
RIPv2 Cryptographic Authentication
RIPv2 Cryptographic Authentication 🎀
okay bestie, this is RFC 4822 and it's giving security upgrade 💖 It's a Standards Track doc from R. Atkinson (Extreme Networks) and M. Fanto (NIST), dated February 2007. It obsoletes RFC 2082 and updates RFC 2453, so it's the new and improved version of the RIPv2 authentication spec. Let's go 🦋
Status of This Memo ✨
this is an Internet standards track protocol for the Internet community, and it's basically asking for discussion and suggestions for improvements 🫶 for the official standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). distribution of this memo is unlimited, so share it with everyone 💅
Copyright Notice 🌸
Copyright (C) The IETF Trust (2007).
IESG Note 🔥
okay, real talk. the IESG approved this doc even though it doesn't meet the guidelines in BCP 107 (RFC 4107). why? because they want everyone to migrate away from Keyed-MD5 fast, since it has known weaknesses 💀 the IESG really wants automated key management used to set up session keys, and they're urging that the future key management work described in Section 5.6 of this document happen as soon as possible 🙏
Abstract 🧚
this note revises the RIPv2 Cryptographic Authentication mechanism that was originally specified in RFC 2082. this doc obsoletes RFC 2082 and updates RFC 2453. the big new thing is that it explains how the SHA family of hash algorithms can be used with RIPv2 Cryptographic Authentication, whereas the original only covered Keyed-MD5 💜 it also clarifies a potential issue with an active attack on this mechanism and adds a lot of new text to the Security Considerations section.
1. Introduction ✨
okay so the internet has grown, and now we really need better authentication for routing info 👑 RIPv2 gives you unauthenticated service (like classical RIP), or password authentication. but both are vulnerable to passive attacks that are super common on the internet right now 😭 there are well-understood security issues in routing protocols [Bell89], and cleartext passwords, which were originally specified for RIPv2, are widely known to be vulnerable to easy-to-deploy passive attacks [HA94]. not it 🙈
the original RIPv2 cryptographic authentication spec, RFC 2082 [AB97], used the Keyed-MD5 mechanism. there are no openly published attacks on it, but some reports [Dobb96a, Dobb96b] raise concerns about how strong the MD5 hash function really is 🥺 also, some end users (like several governments) need the SHA hash function family for policy reasons, and they don't want any other function. and finally, the original uses a hashing construction that's widely believed to be weaker than the HMAC construction used by the algorithms added in this revision 💅
this document obsoletes the original spec, RFC 2082 [AB97]. the difference is that it adds support for the SHA family of hash algorithms and the HMAC technique, while keeping the original Keyed-MD5 algorithm and mode 🌈 since the original RIPv2 Cryptographic Authentication mechanism was algorithm-independent, backwards compatibility is kept. that backwards compatibility requirement means no big protocol changes, so this doc only adds support for one more family of cryptographic algorithms. the original spec has been very widely implemented, is known to be widely interoperable, and is also widely deployed ✨
the authors do not believe this spec is the final answer to RIPv2 authentication, so please check out the Security Considerations section for more details 🫶
if RIPv2 authentication is disabled, then only simple misconfigurations get detected. the original RIPv2 authentication mechanism relied on reused cleartext passwords. cleartext password authentication can protect against accidental misconfigurations if that were the only concern, but it's not helpful from a security perspective 💀 by simply capturing info on the wire (which is straightforward even in a remote environment), a hostile entity can read the cleartext RIPv2 password and use it to inject false info into the routing system through RIPv2 🚨
this mechanism is meant to reduce the risk of a successful passive attack on RIPv2 deployments. that is, deploying it greatly reduces the vulnerability of the RIPv2-based routing system to passive attacks 🦋 when cryptographic authentication is enabled, we send the output of a keyed cryptographic one-way function in the authentication field of the RIPv2 packet, instead of a cleartext reusable password 🎀 the RIPv2 Authentication Key is only known to the authorized parties of the RIPv2 session, and it's never sent over the network in the clear 🔐
this way, protection is provided against forgery or message modification. it is possible to replay a message until the sequence number changes, but a sequence number can be used to reduce replay risks 🍓 the mechanism doesn't provide confidentiality, since messages stay in the clear. and since the objective of a routing protocol is to advertise the routing topology, confidentiality isn't normally required for routing protocols 🧚
other relevant reasons for this approach: MD5 and SHA-1 are both used for other purposes, so they're generally already present in IP routers, and so is some form of password management 💖
1.1. Terminology 🌸
in this document, the words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [BCP14]. they indicate requirement levels for compliant or conformant implementations, so these words are serious business 💅
2. Implementation Approach 🔥
implementing this needs a special packet format, special authentication procedures, and management controls too 🛠️ implementers, remember that the Security Considerations section is an integral part of this spec and contains important parts of it. don't skip it, bestie 😭
2.1. RIPv2 PDU Format 👑
the basic RIPv2 message format has an 8-octet header with an array of 20-octet records as its data content. when RIPv2 Cryptographic Authentication is enabled, the same header and content are used as in the original RIPv2 spec. but the 16-octet "Authentication" password field from the original spec is reused to hold a packet offset to the Authentication Data, a Key Identifier, the Authentication Data Length, and a non-decreasing sequence number ✨
AUTHENTICATION TYPE The "Authentication Type" is Cryptographic Hash Function, which is indicated by the value 3.
RIPv2 PACKET LENGTH an unsigned 16-bit offset from the start of the RIPv2 header to the end of the regular RIPv2 packet (not including the authentication trailer).
KEY IDENTIFIER an unsigned 8-bit field containing the Key Identifier, or Key-ID. combined with the network interface, this identifies the RIPv2 Security Association in use for this packet. the RIPv2 Security Association (defined in Section 2.2 below) includes the Authentication Key that was used to create the Authentication Data for this RIPv2 message, plus other parameters. in implementations that support more than one authentication algorithm, the RIPv2 Security Association also includes info about which authentication algorithm is in use for this message 🦋 a RIPv2 Security Association is always associated with an interface, not with a router. and the actual cryptographic key is part of the RIPv2 Security Association 🔑
AUTHENTICATION DATA LENGTH an unsigned 8-bit field containing the length in octets of the trailing Authentication Data field. the presence of this field helps provide cryptographic algorithm independence 💜
AUTHENTICATION DATA this field contains the cryptographic Authentication Data used to validate this packet. its length is stored in the AUTHENTICATION DATA LENGTH field above 🫶
SEQUENCE NUMBER an unsigned 32-bit sequence number. the sequence number MUST be non-decreasing for all messages sent from a given source router with a given Key ID value. yes, MUST, no cap 🔥
the authentication trailer contains the Authentication Data, which is the output of the keyed cryptographic hash function. check out the later subsections of this section for details on computing this field 🧚
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
+---------------+---------------+-------------------------------+
| Command (1) | Version (1) | Routing Domain (2) |
+---------------+---------------+-------------------------------+
| 0xFFFF | Authentication Type=0x0003 |
+---------------+---------------+---------------+---------------+
| RIPv2 Packet Length | Key ID | Auth Data Len |
+---------------+---------------+---------------+---------------+
| Sequence Number (non-decreasing) |
+---------------+---------------+---------------+---------------+
| reserved must be zero |
+---------------+---------------+---------------+---------------+
| reserved must be zero |
+---------------+---------------+---------------+---------------+
| |
~ (RIPv2 Packet Length - 24) bytes of Data ~
| |
+---------------+---------------+---------------+---------------+
| 0xFFFF | 0x0001 |
+---------------+---------------+---------------+---------------+
| Authentication Data (variable length; 20 bytes with HMAC-SHA1)|
+---------------+---------------+---------------+---------------+2.2. RIPv2 Security Association ✨
okay so this is the core concept you need to get before anything else makes sense 🧠💖 A RIPv2 Security Association is basically the bundle of shared authentication config that the legit sender and any legit receiver both need. Think of it as the shared secret-handshake card 🃏
An implementation MUST be able to support at least 2 concurrent RIPv2 Security Associations on each RIP interface. This is a functional requirement for supporting key rollover. Support for key rollover is mandatory. 🔑🔄
The sender picks which RIPv2 Security Association to use based on the outgoing router interface 💅 (the full definition is coming up below). Each one has a lifetime and other config parameters attached to it. In normal operation, a RIPv2 Security Association is never used outside its lifetime, and certain abnormal cases get discussed later in this document 👀
The minimum data items in a RIPv2 Security Association are as follows:
KEY-IDENTIFIER (KEY-ID) 🆔 The unsigned 8-bit KEY-ID value is used to identify the RIPv2 Security Association in use for this packet.
The receiver uses the combination of the interface the packet was received upon and the KEY-ID value to uniquely identify the appropriate Security Association. It's giving detective work 🕵️♀️
The sender selects which RIPv2 Security Association to use based on the outbound interface for this RIPv2 packet, and then places the correct KEY-ID value into that packet. If multiple valid and active RIPv2 Security Associations exist for a given outbound interface at the time a RIPv2 packet is sent, the sender may use any of those security associations to protect the packet. Options are giving main character energy ✨
AUTHENTICATION ALGORITHM 🧮 This specifies the cryptographic algorithm and algorithm mode used with the RIPv2 Security Association. This info is never sent in cleartext over the wire 🙈 Since it never travels on the wire, the implementer chooses an implementation specific representation for it. At present, the following values are possible: KEYED-MD5, HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512.
AUTHENTICATION KEY 🗝️ This is the value of the cryptographic authentication key used with the associated Authentication Algorithm. It MUST NOT ever be sent over the network in cleartext via any protocol. The length of this key depends on the Authentication Algorithm in use. Operators should take care to select unpredictable and strong keys, avoiding any keys known to be weak for the algorithm in use. [ESC05] has helpful info on both key generation techniques and cryptographic randomness 🧪
SEQUENCE NUMBER 🔢 This is an unsigned 32-bit number. For a given KEY-ID value and sender, this number MUST NOT decrease. In normal operation, the operator should rekey the RIPv2 session before reaching the maximum value. The initial value used in the sequence number is arbitrary. Receivers SHOULD keep track of the most recent sequence number received from a given sender 📈
START TIME ⏰ This is a local representation of the day and time that this Security Association first becomes valid.
STOP TIME 🛑 This is a local representation of the day and time that this Security Association becomes invalid (aka when it expires). It is permitted, but not recommended, for an operator to configure this to "never expire". That "never expire" value is not recommended operational practice, because it reduces security compared with periodic rekeying 😬 Normally, a RIPv2 Security Association is deleted at its STOP TIME. However, there are certain pathological cases, which are discussed in Section 5.1.
The authentication trailer consists of the Authentication Data, which is the output of the keyed cryptographic hash function. Check the later subsections of this section for the details on computing this field 🧩
2.3. Basic Authentication Processing 🔐
When the authentication type is "Cryptographic Hash Function", message processing changes in message creation and reception compared with the original RIPv2 specification in [Mal94]. 🔄
This section describes the message processing generically. Additional algorithm-dependent processing that's required is described in separate, subsequent sections of this document. As of this writing, there are 2 kinds of algorithm-dependent processing. One covers the "Keyed-MD5" algorithm. The other covers the "HMAC-SHA1" family of algorithms 🧁
2.3.1. Message Generation 📤
The RIPv2 Packet is created as usual, with these exceptions:
- The UDP checksum SHOULD be calculated, but MAY be set to zero, because any of the cryptographic authentication mechanisms in this specification will provide stronger integrity protection than the standard UDP checksum 💪
- The Authentication Type field indicates Cryptographic Authentication (3) 🏷️
- The Authentication "password" field is reused to store a packet offset to the Authentication Data, a Key Identifier, the Authentication Data Length, and a non-decreasing sequence number 🫠
See also Section 2.2 above on RIPv2 Security Association for other important background info 📚
When creating the RIPv2 Packet, the following process is followed:
- The Packet Length field of the RIPv2 header indicates the size of the main body of the RIPv2 packet 📏
- An appropriate RIPv2 Security Association is selected for use with this packet, based on the outbound interface for the packet. Any valid RIPv2 Security Association for that outbound interface may be used. The Authentication Data Offset, Key Identifier, and Authentication Data Length fields are filled in appropriately ✍️
- Algorithm-dependent processing happens now, either for the "Keyed-MD5" algorithm or for the "HMAC-SHA1" algorithm family. See the respective sub-sections (below) for the details of this processing 🧠
- The resulting Authentication Data value is written into the Authentication Data field. The trailing pad (if any) is not actually transmitted, since it's entirely predictable from the message length and Authentication Algorithm in use 🫧
2.3.2. Message Reception 📥
When the message is received, the process is reversed:
- The received Authentication Data is set aside and stored for later use 🗄️
- The appropriate RIPv2 Security Association is determined from the value of the Key Identifier field and the interface the packet was received on. If there is no valid RIPv2 Security Association for the received Key Identifier on the interface the packet was received on, then:
- (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 at least the day/time that the bad packet was received, the Source IP Address of the received RIPv2 packet, the Key-ID field value, the interface the bad packet arrived upon, and the fact that no valid RIPv2 Security Association was found for that interface and Key-ID combination. 🚨
- Algorithm-dependent processing is performed, using the algorithm specified by the appropriate RIPv2 Security Association for this packet. This results in calculation of the Authentication Data based on the information in the received RIPv2 packet and information from the appropriate RIPv2 Security Association for that packet 🧮
- The calculated Authentication Data result is compared with the received Authentication Data 🔍
- If the calculated authentication data result does not match the received Authentication Data field, then:
- (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 at least the day/time that the bad packet was received, the Source IP Address of the received RIPv2 packet, the Key-ID field value, the interface the bad packet arrived upon, and the fact that RIPv2 Authentication failed upon receipt of the packet. 🙅♀️
- If the neighbor has been heard from recently enough to have viable routes in the local routing table, and the received sequence number is less than the last sequence number received, then the message MUST be discarded unprocessed. If the received sequence number is less than the last sequence number received, that fact SHOULD be logged as a security event. This logged 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 field value, and the fact that an out-of-order RIPv2 sequence number was received 🙃
When connectivity to the neighbor has been lost, the receiver SHOULD be ready to accept either:
- a message with a sequence number of zero.
- a message with a higher sequence number than the last received sequence number.
- Acceptable messages are now truncated to the RIPv2 message itself, minus the authentication trailer, and are processed normally (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: 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 preventing 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. 💀🔒
2.4. Keyed-MD5 Algorithm-Dependent Processing 💖
okay so this section is the step-by-step for when the "Keyed-MD5" algorithm is in use 🎀. the RIPv2 Authentication Key is always 16 octets when "Keyed-MD5" is in use ✨
(1) the RIPv2 Authentication Key gets appended to the RIPv2 packet in memory 🦋
(2) the Trailing Pad for MD5 and the message length fields get added in memory too. here's how those extra bits look when they're appended in memory:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Key |
/ (16 octets long) /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero or more pad octets (as defined by RFC 1321) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64-bit message length MSW |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64-bit message length LSW |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+(3) then the Authentication Data gets calculated with the MD5 algorithm defined by RFC 1321 [Rivest92] 💅
2.5. HMAC-SHA1 Algorithm-Dependent Processing 🌈
this section covers the processing steps for HMAC Authentication 🔐. HMAC was originally documented in [KMC97], but for this spec we're using the terminology from [FIPS-198] 📚. the current spec only gives full details for HMAC Authentication using the National Institute of Standards and Technology (NIST) SHA-1 algorithm (and its direct derivatives), but this same basic process could be used with other cryptographic hash functions in the future 🔮. because the RIPv2 packet only gets hashed once, the overhead of the double hashing in this process is negligible ✨
the US NIST Secure Hash Standard (SHS), defined by [FIPS-180-2], includes specs for SHA-1, SHA-256, SHA-384, and SHA-512. this spec defines processing for each of these 🍓
the output of the cryptographic computations (e.g., HMAC-SHA1) is NOT truncated for RIPv2 Cryptographic Authentication 🙈
the Authentication Data Length is equal to the Message Digest Size for the hash algorithm in use 📏
any key value known to be weak with an algorithm defined by the NIST Secure Hash Standard MUST NOT be used with such an algorithm in an implementation of this specification. US NIST is the authoritative source for public information on weak keys for those algorithms. 🚫
in the algorithm description below, we use the following nomenclature, which is consistent with [FIPS-198] 🧚
H is the specific hashing algorithm,
for example, SHA-1 or SHA-256.
Ko is the cryptographic key used with the hash algorithm.
B is the block-size of H, measured in octets, not bits.
Note that B is the internal block size, not the hash size.
For SHA-1 and SHA-256: B == 64.
For SHA-384 and SHA-512: B == 128
L is the length of the hash, measured in octets, not bits.
For example, with SHA-1, L == 20.
XOR is the exclusive-or operation.
Opad is the hexadecimal value 0x5c repeated B times.
Ipad is the hexadecimal value 0x36 repeated B times.
Apad is the hexadecimal value 0x878FE1F3 repeated (L/4) times.(1) PREPARATION OF KEY 🗝️ in this application, Ko is always L octets long.
if the Authentication Key is L octets long, then Ko is set equal to the Authentication Key. if the Authentication Key is more 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 to the Authentication Key with zeros appended to the end of it, so that Ko ends up L octets long 🧸
(2) FIRST HASH 🌸 first, the RIPv2 packet's Authentication Data field is filled with the value Apad.
then, a first hash (also known as the inner hash) is computed like this:
First-Hash = H(Ko XOR Ipad || (RIPv2 Packet))(3) SECOND HASH 💜 then a second hash (also known as the outer hash) is computed like this:
Second-Hash = H(Ko XOR Opad || First-Hash)(4) RESULT ⭐ the result Second-Hash becomes the authentication data that gets sent in the Authentication Data field of the RIPv2 packet. the length of the Authentication Data field is always identical to the message digest size of the hash function H that's being used.
this also implies that hash functions with larger output sizes will also increase the size of the packet as it's transmitted on the wire 📦
3. Management Procedures 🗂️✨
key management is an important part of this mechanism, and proper implementation is central to providing the intended level of risk reduction 💅
3.1. Key Management Requirements 🔑
it's strongly desirable that a hypothetical security breach in one Internet protocol doesn't automatically compromise other Internet protocols 🛡️. the Authentication Key of this specification SHOULD NOT be configured or stored using protocols (e.g., RADIUS) or cryptographic algorithms that have known flaws 🙅♀️
Implementations MUST support storing more than one key at the same time, even though it's recognized that only one key will normally be active on an interface 🎀. Implementations MUST associate a specific Security Association lifetime (i.e., date/time first valid and date/time no longer valid) and a key identifier with each key 🏷️. Implementations also MUST support manual key distribution. an example of manual key distribution is the privileged user typing in the key, key lifetime, and key identifier on the router console 💻. an operator may configure the Security Association lifetime to infinite, which means the session is never rekeyed. however, it's strongly recommended that operators rekey regularly, using a moderately short Security Association lifetime (e.g., 24 hours). ⏰
this specification requires support for at least two authentication algorithms, so the implementation MUST require that the authentication algorithm be specified for each key when the other key information is entered. Manual deletion of active Security Associations MUST be supported 🗑️
it's likely that the IETF will define a standard key management protocol for use with routing protocols 🔮. it's strongly desirable to use an IETF standards-track key management protocol to distribute RIPv2 Authentication Keys among communicating RIPv2 implementations 🦋. such a protocol would provide scalability and significantly reduce the human administrative burden 🙌. the Key-ID field can be used as a hook between RIPv2 and such a future protocol 🪝
key management protocols have a long history of subtle flaws that are often discovered long after the protocol was first described in public 🙈. to avoid having to change all RIPv2 implementations should such a flaw be discovered, integrated key management protocol techniques were deliberately left out of this specification 🧠
3.2. Key Management Procedures 🔄
as with all security methods that use keys, it's necessary to change the RIPv2 Authentication Key on a regular basis 🔁. to keep routing stable during those changes, implementations MUST be able to store and use more than one RIPv2 Authentication Key on a given interface at the same time 💖
each key will have its own Key Identifier (KEY-ID), which is stored locally 🏷️. the combination of the Key Identifier and the interface associated with the message uniquely identifies the Authentication Algorithm and RIPv2 Authentication Key in use ✨
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 RIPv2 Security Associations for that interface 🎯. The receiver MUST use the Key Identifier and receiving interface to determine which RIPv2 Security Association to use for authentication of the received message 🔍. More than one RIPv2 Security Association MAY be associated with an interface at the same time 🌈. The receiver MUST NOT simply try all RIPv2 Security Associations (i.e., keys) that might be configured for RIPv2 on the receiving interface, because that creates an easily exploited denial-of-service attack on the RIP subsystem of the receiver 🚨. (At least one widely used implementation of the previous version of this specification violates these requirements as of the publication date of this document and has consequent security vulnerabilities.) 😭
so it's possible to have fairly smooth RIPv2 Security Association (i.e., key) rollovers, without losing legitimate RIPv2 messages due to an invalid shared key and without requiring people to change all the keys at once 🫶. to ensure a smooth rollover, each communicating RIPv2 system must be updated with the new RIPv2 Security Association (including the new key) several minutes before the current RIPv2 Security Association will expire and several minutes before the new RIPv2 Security Association lifetime begins. also, the new RIPv2 Security Association should have a lifetime that starts several minutes before the old RIPv2 Security Association expires 🕰️. this gives each system time to learn of the new security association before that security association will be used 📚. it also ensures that the new security association begins use and the current security association goes out of use before the current security association's lifetime expires 🦢. for the duration of the overlap in security association lifetimes, a system may receive messages corresponding to either security association and successfully authenticate the message 💫. the Key-ID in the received message is used to select the appropriate security association (i.e., key) for authentication 🔑
4. Conformance Requirements 🎀💅
for this specification, the term "conformance" has identical meaning to the phrase "full compliance" 💯
The Keyed MD5 authentication algorithm and the HMAC-SHA1 algorithm MUST be implemented by all conforming implementations 🌸. in addition, 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, and SHA-512 have been defined by the US NIST in [FIPS-180-2] 📚
a conforming implementation MAY also support additional authentication algorithms, provided those additional algorithms are publicly and openly specified 🌈
Manual key distribution as described above MUST be supported by all conforming implementations 🗝️. All implementations MUST support the smooth key rollover described under "Key Management Procedures" 🔄. this also means implementations MUST support at least 2 concurrent RIPv2 Security Associations 👑
the user documentation that comes with the implementation ought to contain clear instructions on how to configure it so that smooth key rollover happens successfully 📖
Implementations SHOULD support a standard key management protocol for secure distribution of RIPv2 Authentication Keys once such a key management protocol is standardized by the IETF 🦋
the Security Considerations section of this document is an integral part of the specification, not just a discussion of the protocol. 🧚
5. Security Considerations 🔐✨
Okay bestie, this whole memo describes and specifies an authentication mechanism for the RIPv2 routing protocol that is believed to be secure against passive attacks 🛡️. "Passive attack" is defined in RFC 1704 [HA94], and the analysis in RFC 1704 is what motivated this work. Passive attacks are clearly widespread on the Internet right now [HA94] 👀.
Protection against active attacks is incomplete in this current specification 😬. The main issue with active attacks is the need to support the case where another router has recently rebooted and that router lacks the non-volatile storage needed to remember the RIPv2 Security Association(s) and last received RIPv2 sequence number(s) across that reboot 🔄.
5.1. Known Pathological Cases
Two known pathological cases exist that MUST be handled by implementations 🚨. Both of these are failures of the network manager, and each should be exceedingly rare in normal operation 🙃.
(1) During key rollover, devices might exist that have not yet been successfully configured with the new key 🔑. Therefore, routers SHOULD implement an algorithm that detects the set of RIPv2 Security Associations being used by its neighbors, and transmit its messages using both the new and old RIPv2 Security Associations (i.e., keys) until all of the neighbors are using the new security association or the lifetime of the old security association expires 🔁. Under normal circumstances, this elevated transmission rate will exist for a single RIP update interval ⏱️.
(2) In the event that the last RIPv2 Security Association of an interface expires, it is unacceptable to revert to an unauthenticated condition, and not advisable to disrupt routing 🙅♀️. Therefore, the router MUST send a "last RIPv2 Security Association expiration" notification to the network manager (e.g., via SYSLOG, SNMP, and/or other means) 📣, and SHOULD treat that last Security Association as having an infinite lifetime until the lifetime is extended, the Security Association is deleted by network management, or a new security association is configured ♾️.
In some circumstances, the practice described in (2) can leave an opening to an active attack on the RIPv2 routing subsystem 🚩. Therefore, any actual occurrence of a RIPv2 Security Association expiration MUST cause a security event to be logged by the implementation 📝. This log item MUST include at least a note that the RIPv2 Authentication Key expired, the RIP routing protocol instance(s) affected, the routing interfaces affected, the Key-ID that is affected, and the current date/time 🕰️.
Operators are encouraged to check such logs as an operational security practice to help detect active attacks on the RIPv2 routing subsystem 👀💜. Further, implementations SHOULD provide a configuration knob ("fail secure") 🎛️ to let a network operator prefer to have the RIPv2 routing fail when the last key expires, rather than continue using RIPv2 in an insecure manner 🧱.
5.2 Network Management Considerations
Also, the use of SNMP, even SNMPv3 with cryptographic authentication and cryptographic confidentiality enabled, to modify or configure the RIPv2 Security Associations, or any component of the security association (for example, the cryptographic key), is NOT RECOMMENDED 🙅♀️. This practice would create a potential for a cascading vulnerability 🌊, whereby a compromise in the SNMP security implementation would necessarily lead to a compromise not only of the local routing table (which could be accessed via SNMP) but also of all other routers that receive RIPv2 packets (directly or indirectly) from the compromised router 💀.
Similarly, the use of protocols not designed and evaluated for use in key management (e.g., RADIUS, Diameter) to configure the security association is also NOT RECOMMENDED 🚫. Reading the Security Associations via SNMP is allowed, but the information is to be treated as security-sensitive and protected by using the priv mode 🔒.
Also, the use of SNMP to configure which form of RIPv2 authentication is in use is also NOT RECOMMENDED because of a similar cascading failure issue 🙈. Any future revision of the RIPv2 Management Information Base (MIB) [MB94] should consider making the rip2IfConfAuthType object read-only. Further, this object would need a new enum value to accommodate the RIPv2 cryptographic authentication type 🧩. In addition, the compliance statement for this MIB does not have a MIN-ACCESS for this object 🤷♀️. At a minimum, if the MIB is updated, a new compliance statement SHOULD be written for this object that allows this object to be implemented as read-only 📜. For the rip2ifConfAuthKey object, since this object always returns ''H when read, the object's MIN-ACCESS in any revised compliance statement SHOULD be not-accessible if the MIB is updated 🙌.
Further, for similar reasons, any future revisions to the RIPv2 Management Information Base (MIB) SHOULD deprecate or omit any objects that would permit the writing of any RIPv2 Security Association or RIPv2 Security Association component (e.g., the cryptographic key) 🗑️.
Also, it is RECOMMENDED that any future revisions to the RIPv2 Management Information Base (MIB) consider adding MIB objects to hold information about any RIPv2 security events that might have occurred, 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 mentioned in this document, it is also RECOMMENDED that appropriate notifications be included, with a MAX-ACCESS of Accessible-for-notify, in any future versions of the RIPv2 MIB module 🔔✨.
5.3. Key Management Considerations
For the past several years, manual configuration (e.g., via a console) has been commonly used to create and modify RIPv2 Security Associations 🖥️. There are a number of large-scale RIP deployments today that successfully use manual configuration of RIPv2 Security Associations 💪. There are also sites that use scripts (e.g., combining Tcl/Expect, PERL, and SSHv2) with a site-specific configuration database and secure console connections to dynamically manage all aspects of their router configurations, including their RIPv2 Security Associations 🤖. This last approach is similar to the current IETF approach to Network Configuration (NetConf) standards 🧑💻.
Recent IETF Multicast Security (MSEC) working group efforts into multicast key management appear promising 🌟. Several large RIPv2 deployments happen to also have deployed the Kerberos authentication system 🐕🦺. Recent IETF work into the use of Kerberos for Internet Key Negotiation (KINK) also seems relevant; one might use Kerberos to support RIPv2 key management functions for use at sites that have already deployed Kerberos 🎀. It is hoped that in the future the IETF will standardize a key management protocol suitable for managing RIPv2 Security Associations 🙏🌈.
5.4. Assurance Considerations
Users need to understand that the quality of the security provided by this mechanism depends completely on the strength of the implemented authentication algorithms, the strength of the key being used, and the correct implementation of the security mechanism in all communicating RIPv2 implementations 🧐. This mechanism also depends on the RIPv2 Authentication Key being kept confidential by all parties 🤐. If any of these are incorrect or insufficiently secure, then no real security will be provided to the users of this mechanism 💔.
Use of high-assurance development methods is RECOMMENDED for implementations of this specification 🛠️, in order to reduce the risk of subtle implementation flaws that might adversely impact the operational risk reduction that this specification seeks to provide ✅.
5.5. Confidentiality and Traffic Analysis Considerations
Confidentiality is not provided by this mechanism 🙊. It is generally considered that an IP routing protocol does not require confidentiality, as the purpose of any routing protocols is to disseminate information about the topology of the network 🗺️.
Protection against traffic analysis is also not provided 🕵️♀️. Mechanisms such as bulk link encryption SHOULD be used when protection against traffic analysis is required [CKHD89] 🔐.
5.6. Other Security Considerations
Separately, the receipt of a RIPv2 packet using cryptographic authentication but containing an invalid or unknown Key-ID value might indicate an active attack on the RIP routing subsystem and is a significant security event 🚨👀. Therefore, any actual receipt of a RIPv2 packet using cryptographic authentication and containing an unknown, expired, or otherwise invalid KEY-ID value SHOULD cause a security event to be logged by the implementation 📝. This log item SHOULD 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 interface(s) the packet was received on, the KEY-ID received, and the current date/time 🕰️.
A subtle user-interface consideration also should be noted 💅. If a user interface only permits the entry of human-readable text (e.g., a password in US-ASCII format) for use as a cryptographic key, significant numbers of bits of the cryptographic key in use become predictable, thereby reducing the strength of the key in this context 😭. For this reason, implementations of this specification SHOULD support the entry of RIPv2 cryptographic authentication keys in hexadecimal format 🔢✨.
5.7. Future Security Directions
Specification and deployment of a standards-track key management protocol that supports this RIPv2 cryptographic authentication mechanism would be a significant next step in operational risk reduction and might actually increase the ease of deployment and operation of this mechanism 🚀. Such specification is beyond the scope of this document 🙃. Recent IETF work in MSEC and KINK working groups appears promising in this regard 🌸. Recent IETF work in the NETCONF working group towards standardizing methods for secure configuration management of routers is also relevant 🧚.
Finally, we observe that this mechanism is not the final word on RIPv2 authentication 🦋. Rather, it is believed that this particular mechanism represents a significant risk reduction over previous methods (e.g., plaintext passwords), while remaining straightforward 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 much of the mechanism in this document could be reused with digital signatures 🫶.
6. Acknowledgments 🎀
Fred Baker was co-author of the earlier RIPv2 MD5 Authentication document [AB97] 👑. This document is a direct derivative of that earlier document, though it has been significantly reworked 🛠️. The current authors would like to thank Bill Burr, Tim Polk, John Kelsey, and Morris Dworkin of (US) NIST for review of versions of this document 🙏💜.
7. Normative References 📚
okay so these are the must-read receipts 💅 Every doc on this list is needed to actually implement the spec, and each one is written out below with all its details, no cap 🫶
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[Mal98] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November
1998.
[FIPS-180-2] National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-2, August 2002,
<http://csrc.nist.gov/publications/fips/fips180-2/
fips180-2.pdf>.
[FIPS-198] National Institute of Standards and Technology, "The
Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB
198, March 2002, <http://csrc.nist.gov/publications/
fips/fips198/fips-198a.pdf>.8. Informative References 🌸
these ones are the extra reading, the context and the history, so you can go deep if you're obsessed like me 🤓✨ they're not required to implement, but they're so worth a look
[AB97] Baker, F. and R. Atkinson, "RIP-2 MD5 Authentication",
RFC 2082, January 1997.
[Bell89] S. Bellovin, "Security Problems in the TCP/IP Protocol
Suite", ACM Computer Communications Review, Volume 19,
Number 2, pp. 32-48, April 1989.
[CKHD89] Cole Jr, Raymond, Donald Kallgren, Richard Hale, and
John R. Davis, "Multilevel Secure Mixed-Media
Communication Networks", Proceedings of the IEEE
Military Communications Conference (MILCOM '89), IEEE,
1989.
[Dobb96a] Dobbertin, H., "Cryptanalysis of MD5 Compress",
Technical Report, 2 May 1996. (Presented at Rump
Session of EuroCrypt 1996.)
[Dobb96b] Dobbertin, H., "The Status of MD5 After a Recent
Attack", CryptoBytes, Vol. 2, No. 2, Summer 1996.
[ESC05] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC
4086, June 2005.
[HA94] Haller, N. and R. Atkinson, "On Internet
Authentication", RFC 1704, October 1994.
[KMC97] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC 2104,
February 1997.
[Mal94] Malkin, G., "RIP Version 2 - Carrying Additional
Information", RFC 1723, November 1994.
[MB94] Malkin, G. and F. Baker, "RIP Version 2 MIB Extension",
RFC 1724, November 1994.
[MBW97] Murphy, S., Badger, M., and B. Wellington, "OSPF with
Digital Signatures", RFC 2154, June 1997.
[Rivest92] Rivest, R., "The MD5 Message-Digest Algorithm", RFC
1321, April 1992.Authors' Addresses 💌
here's where to find the authors if you ever want to slide into their inbox 👀🧚
R. Atkinson
Extreme Networks
3585 Monroe Street
Santa Clara, CA 95051
USA
Phone: +1 (408) 579-2800
EMail: rja@extremenetworks.com
M. Fanto
(US) National Institute of Standards and Technology
Gaithersburg, MD 20878
USA
Phone: +1 (301) 975-2000
EMail: mattjf@umd.edu
Web: http://csrc.nist.govFull Copyright Statement 🎀
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 legal bits, but make it cute 🫶 the IETF doesn't take a position on whether any patents or other rights cover this tech, or whether you could get a license for them. it also hasn't done any independent search to find out.
info on how rights work for RFC documents lives in BCP 78 and BCP 79. copies of IPR disclosures sent to the IETF Secretariat, plus any assurances of licenses, or the results of an attempt to get a general license for implementers or users, can be found in the IETF's online IPR repository at http://www.ietf.org/ipr.
the IETF also invites anyone to flag copyrights, patents, patent applications or other proprietary rights that might cover technology needed to implement this standard. send those to ietf-ipr@ietf.org 💅
Acknowledgement 🫶
funding for the RFC Editor function is currently provided by the Internet Society 🌈 thank you to them for keeping the lights on ✨
📦 where this page comes from
- ietf: rfc4822 2007-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms