RFC 6506
Supporting Authentication Trailer for OSPFv3
RFC 6506: Supporting Authentication Trailer for OSPFv3 💖
Okay bestie, this is RFC 6506 and it is a whole standards-track moment ✨. It was published in February 2012 by the Internet Engineering Task Force (IETF). The authors are M. Bhatia (Alcatel-Lucent), V. Manral (Hewlett Packard), and A. Lindem (Ericsson). It's a Standards Track document with ISSN 2070-1721. It doesn't obsolete or update any other RFCs, so it's giving independent main character energy 🦋.
Abstract 🌸
Right now, OSPF for IPv6 (OSPFv3) uses IPsec as the only way to authenticate its protocol packets 🙈. That's different from how other routing protocols do it: OSPFv2, Intermediate System to Intermediate System (IS-IS), RIP, and Routing Information Protocol Next Generation (RIPng) all have their own authentication. In some environments IPsec is really hard to configure and maintain, so it just can't be used. This document defines an alternative way to authenticate OSPFv3 packets, so OSPFv3 doesn't depend on IPsec alone for authentication 🔐.
Status of This Memo 📝
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). You can find more about Internet Standards in Section 2 of RFC 5741.
Info about the current status of this document, any errata, and how to give feedback is at http://www.rfc-editor.org/info/rfc6506.
Copyright Notice ©️
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License.
Table of Contents 📚
1. Introduction ....................................................2
1.1. Requirements ...............................................3
2. Proposed Solution ...............................................4
2.1. AT-Bit in Options Field ....................................4
2.2. Basic Operation ............................................5
2.3. IPv6 Source Address Protection .............................5
3. OSPFv3 Security Association .....................................6
4. Authentication Procedure ........................................8
4.1. Authentication Trailer .....................................8
4.1.1. Sequence Number Wrap ...............................10
4.2. OSPFv3 Header Checksum ....................................10
4.3. Cryptographic Authentication Procedure ....................10
4.4. Cross-Protocol Attack Mitigation ..........................11
4.5. Cryptographic Aspects .....................................11
4.6. Message Verification ......................................13
5. Migration and Backward Compatibility ...........................15
6. Security Considerations ........................................15
7. IANA Considerations ............................................16
8. References .....................................................17
8.1. Normative References ......................................17
8.2. Informative References ....................................17
Appendix A. Acknowledgments ......................................191. Introduction 🌷
Okay so, unlike OSPFv2 [RFC2328], OSPF for IPv6 (OSPFv3) [RFC5340] doesn't have the AuType and Authentication fields in its headers for authenticating protocol packets 🙈. Instead, OSPFv3 relies on the IPsec protocols Authentication Header (AH) [RFC4302] and Encapsulating Security Payload (ESP) [RFC4303] to provide integrity, authentication, and/or confidentiality.
[RFC4552] explains how IPv6 AH and ESP extension headers can be used to give OSPFv3 authentication and/or confidentiality 🔑.
But ngl, there are some environments, like Mobile Ad Hoc Networks (MANETs), where IPsec is difficult to configure and maintain, so this mechanism just can't be used there 💀.
[RFC4552] goes into a lot of detail about why it uses manually configured keys instead of an automated key management protocol like Internet Key Exchange version 2 (IKEv2) [RFC5996]. The main problem is that there isn't a suitable key management mechanism, because OSPFv3 adjacencies form on a one-to-many basis, and most key management mechanisms are built for one-to-one communication. So the system administrator has to set up manually configured security associations (SAs) and cryptographic keys to get the authentication and, if wanted, the confidentiality 😩.
About replay protection, [RFC4552] states that:
Since it is not possible using the current standards to provide complete replay protection while using manual keying, the proposed solution will not provide protection against replay attacks.
Since there's no replay protection, there are a bunch of vulnerabilities in OSPFv3 that were discussed in [RFC6039] 😭.
Also, there's no deterministic way to tell encrypted and unencrypted ESP packets apart just by looking at the packet. So it could be hard for some implementations to prioritize certain OSPFv3 packet types, like Hello packets, over the other types 🙃.
This document defines a new mechanism that works similarly to OSPFv2 [RFC5709] to provide authentication for OSPFv3 packets. It also tries to solve the replay protection problem and the deterministic disambiguation of different OSPFv3 packets that we just talked about 💅.
This document adds support for the Secure Hash Algorithms (SHAs) defined in the US NIST Secure Hash Standard (SHS), which is specified by NIST FIPS 180-3. [FIPS-180-3] includes SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512 🌈. The Hashed Message Authentication Code (HMAC) authentication mode defined in NIST FIPS 198-1 [FIPS-198-1] is used.
It is believed that HMAC as defined in [RFC2104] is mathematically identical to [FIPS-198-1]. It is also believed that the algorithms in [RFC6234] are mathematically identical to [FIPS-198-1] 🤓.
1.1. Requirements 📌
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
2. Proposed Solution 🦋
To do non-IPsec Cryptographic Authentication, OSPFv3 routers attach a special data block to the end of their OSPFv3 packets, which is called the Authentication Trailer. The length of the Authentication Trailer is not included in the length of the OSPFv3 packet, but it is included in the IPv6 payload length, as shown in Figure 1 👀.
+---------------------+ -- -- +----------------------+
| IPv6 Payload Length | ^ ^ | IPv6 Payload Length |
| PL = OL + LL | | | | PL = OL + LL + AL |
| | v v | |
+---------------------+ -- -- +----------------------+
| OSPFv3 Header | ^ ^ | OSPFv3 Header |
| Length = OL | | | | Length = OL |
| | | OSPFv3 | | |
|.....................| | Packet | |......................|
| | | Length | | |
| OSPFv3 Packet | | | | OSPFv3 Packet |
| | v v | |
+---------------------+ -- -- +----------------------+
| | ^ ^ | |
| Optional LLS | | LLS Data | | Optional LLS |
| LLS Block Len = LL | | Block | | LLS Block Len = LL |
| | v Length v | |
+---------------------+ -- -- +----------------------+
^ | |
AL = PL - (OL + LL) | | Authentication |
| | AL = Fixed Trailer + |
v | Digest Length |
-- +----------------------+
Figure 1: Authentication Trailer in OSPFv3The presence of the Link-Local Signaling (LLS) [RFC5613] block is decided by the L-bit setting in the OSPFv3 Options field in OSPFv3 Hello and Database Description packets. If it's present, the LLS data block gets included along with the OSPFv3 packet in the Cryptographic Authentication computation 🧩.
2.1. AT-Bit in Options Field 🎀
A new AT-bit (AT stands for Authentication Trailer) is added to the OSPFv3 Options field 💫. OSPFv3 routers MUST set the AT-bit in OSPFv3 Hello and Database Description packets to show that all the packets on this link will include an Authentication Trailer. For OSPFv3 Hello and Database Description packets, the AT-bit tells you the AT is present. For other OSPFv3 packet types, the OSPFv3 AT-bit setting from the Hello/Database Description setting is preserved in the OSPFv3 neighbor data structure. OSPFv3 packet types that don't include an OSPFv3 Options field will use the setting from the neighbor data structure to determine whether or not the AT is expected 🧠.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+--+-+--+
| | | | | | | | | | | | | |AT|L|AF|*|*|DC|R|N|MC|E|V6|
+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+--+-+--+
Figure 2: OSPFv3 Options FieldThe AT-bit, as shown in the figure above, MUST be set in all OSPFv3 Hello and Database Description packets that contain an Authentication Trailer 💅.
2.2. Basic Operation 🌸
The way the Authentication Trailer gets computed is pretty much the same as in [RFC5709] and [RFC2328]. The one difference is that the LLS data block, if there is one, gets included in the Cryptographic Authentication computation 🫶.
The way the authentication data is carried in the Authentication Trailer is very similar to how it's done in [RFC2328]. The only difference between the OSPFv2 Authentication Trailer and the OSPFv3 Authentication Trailer is that the OSPFv3 one carries extra information in addition to the message digest. That additional information is included in the message digest computation, so it's protected by OSPFv3 Cryptographic Authentication as described here ✨.
Just like OSPFv2 Cryptographic Authentication [RFC2328], both the OSPFv3 header checksum calculation and verification are omitted when the OSPFv3 authentication mechanism described in this specification is used. Periodt 💜.
2.3. IPv6 Source Address Protection 🦋
okay so OSPFv3 always uses the Router ID to identify its neighbors 🫶, but the IPv6 source address gets learned from the OSPFv3 Hello packets and copied into the neighbor data structure [RFC5340]. 😭 That means OSPFv3 is lowkey susceptible to Man-in-the-Middle attacks where the IPv6 source address gets modified 💀. To stop that, the IPv6 source address will be included in the message digest calculation and protected by OSPFv3 authentication. Check Section 4.5 for the deets 💅. This is different from the procedure in [RFC5709] but consistent with [MANUAL-KEY] ✨
3. OSPFv3 Security Association 🎀
An OSPFv3 Security Association (SA) is basically a set of parameters shared between any two legit OSPFv3 speakers 👑
Parameters associated with an OSPFv3 SA are as follows:
- Security Association Identifier (SA ID) 🍓
This is a 16-bit unsigned integer that uniquely identifies an OSPFv3 SA, and it's manually configured by the network operator.
The receiver figures out the active SA by checking the SA ID field in the incoming protocol packet 👀
The sender, based on the active configuration, selects an SA to use and puts the correct Key ID value associated with the SA in the OSPFv3 protocol packet. If multiple valid and active OSPFv3 SAs exist for a given interface, the sender may use any of those SAs to protect the packet.
Using SA IDs makes changing keys while maintaining protocol operation super convenient 🔥. Each SA ID specifies two independent parts, the authentication algorithm and the Authentication Key, as explained below.
Normally, an implementation would let the network operator configure a set of keys in a key chain, with each key in the chain having a fixed lifetime. The actual operation of these mechanisms is outside the scope of this document.
Note that each SA ID can indicate a key with a different authentication algorithm. This allows new authentication mechanisms to be introduced without disrupting existing OSPFv3 adjacencies 🦋
- Authentication Algorithm 🧚
This signifies the authentication algorithm to be used with this OSPFv3 SA. This information is never sent in clear text over the wire. Because this information is not sent on the wire, the implementer chooses an implementation-specific representation for it.
Currently, the following algorithms are supported:
HMAC-SHA-1,HMAC-SHA-256,HMAC-SHA-384, andHMAC-SHA-512.
- Authentication Key 🔑
This value denotes the Cryptographic Authentication Key associated with this OSPFv3 SA. The length of this key is variable and depends on the authentication algorithm specified by the OSPFv3 SA.
- KeyStartAccept 🌸
The time that this OSPFv3 router will accept packets that have been created with this OSPFv3 SA.
- KeyStartGenerate 🌈
The time that this OSPFv3 router will begin using this OSPFv3 SA for OSPFv3 packet generation.
- KeyStopGenerate 💜
The time that this OSPFv3 router will stop using this OSPFv3 SA for OSPFv3 packet generation.
- KeyStopAccept ⭐
The time that this OSPFv3 router will stop accepting packets generated with this OSPFv3 SA.
In order to get a smooth key transition, KeyStartAccept SHOULD be less than KeyStartGenerate, and KeyStopGenerate SHOULD be less than KeyStopAccept. If KeyStartGenerate or KeyStartAccept are left unspecified, the time defaults to 0, and the key gets used immediately. If KeyStopGenerate or KeyStopAccept are left unspecified, the time defaults to infinity, and the key's lifetime is infinite. When a new key replaces an old one, the KeyStartGenerate time for the new key MUST be less than or equal to the KeyStopGenerate time of the old key. 🔄
Key storage SHOULD persist across a system restart, warm or cold, so nothing gets weird operationally 🙈. If the last key associated with an interface expires, it is unacceptable to revert to an unauthenticated condition, and it's not advisable to disrupt routing either. So, the router SHOULD send a "last Authentication Key expiration" notification to the network operator and treat the key as having an infinite lifetime until the lifetime is extended, the key is deleted by the network operator, or a new key is configured 😭
4. Authentication Procedure 🫶
4.1. Authentication Trailer 💅
The Authentication Trailer that gets appended to the OSPFv3 protocol packet looks like this:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Type | Auth Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Security Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptographic Sequence Number (High-Order 32 Bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptographic Sequence Number (Low-Order 32 Bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authentication Data (Variable) |
~ ~
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Authentication Trailer FormatThe various fields in the Authentication Trailer are:
- Authentication Type 🎀
This is a 16-bit field identifying the type of authentication. The following values are defined in this specification:
0 - Reserved.
1 - HMAC Cryptographic Authentication as described herein.- Auth Data Len 🍓
The length in octets of the Authentication Trailer (AT), including both the 16-octet fixed header and the variable length message digest.
- Reserved 🙈
This field is reserved. It SHOULD be set to 0 when sending protocol packets and MUST be ignored when receiving protocol packets.
- Security Association Identifier (SA ID) 🧚
This 16-bit field maps to the authentication algorithm and the secret key used to create the message digest appended to the OSPFv3 protocol packet.
Though the SA ID implicitly implies the algorithm, the HMAC output size should not be used by implementers as an implicit hint, because additional algorithms may be defined in the future that have the same output size 👀
- Cryptographic Sequence Number 🔥
This is a 64-bit strictly increasing sequence number that is used to guard against replay attacks. The 64-bit sequence number MUST be incremented for every OSPFv3 packet sent by the OSPFv3 router. Upon reception, the sequence number MUST be greater than the sequence number in the last OSPFv3 packet accepted from the sending OSPFv3 neighbor. Otherwise, the OSPFv3 packet is considered a replayed packet and dropped 🚫
OSPFv3 routers implementing this specification MUST use available mechanisms to preserve the sequence number's strictly increasing property for the deployed life of the OSPFv3 router (including cold restarts). One mechanism for accomplishing this would be to use the high-order 32 bits of the sequence number as a wrap/boot count that is incremented any time the OSPFv3 router loses its sequence number state. Sequence number wrap is described in Section 4.1.1 🌈
- Authentication Data 💜
This is variable data that carries the digest for the protocol packet and the optional LLS data block.
4.1.1. Sequence Number Wrap 🌸
When incrementing the sequence number for each transmitted OSPFv3 packet, the sequence number should be treated as an unsigned 64-bit value. If the lower-order 32-bit value wraps, the higher-order 32-bit value should be incremented and saved in non-volatile storage. If by some chance the OSPFv3 router is deployed long enough that the 64-bit sequence number may wrap, all keys, independent of their key distribution mechanism, MUST be reset to avoid the possibility of replay attacks. Once the keys have been changed, the higher-order sequence number can be reset to 0 and saved to non-volatile storage ✨
4.2. OSPFv3 Header Checksum 🧚
Both OSPFv3 header checksum calculation and verification are omitted when the OSPFv3 authentication mechanism described in this specification is used. This implies:
- For OSPFv3 packets to be transmitted, the OSPFv3 header checksum computation is omitted, and the OSPFv3 header checksum SHOULD be set to 0 prior to computation of the OSPFv3 Authentication Trailer message digest.
- For received OSPFv3 packets including an OSPFv3 Authentication Trailer, OSPFv3 header checksum verification MUST be omitted. However, if the OSPFv3 packet does include a non-zero OSPFv3 header checksum, it will not be modified by the receiver and will simply be included in the OSPFv3 Authentication Trailer message digest verification 🫶
4.3. Cryptographic Authentication Procedure 🔐
As noted earlier, the SA ID maps to the authentication algorithm and the secret key used to generate and verify the message digest. This specification discusses the computation of OSPFv3 Cryptographic Authentication data when any of the NIST SHS family of algorithms is used in the Hashed Message Authentication Code (HMAC) mode 🦋
The currently valid algorithms (including mode) for OSPFv3 Cryptographic Authentication include:
HMAC-SHA-1,HMAC-SHA-256,HMAC-SHA-384, andHMAC-SHA-512.
Of the above, implementations of this specification MUST include support for at least HMAC-SHA-256, and SHOULD include support for HMAC-SHA-1, and MAY also include support for HMAC-SHA-384 and HMAC-SHA-512 👑
Implementations of this specification MUST use HMAC-SHA-256 as the default authentication algorithm 💖
4.4. Cross-Protocol Attack Mitigation 🛡️
In order to prevent cross-protocol replay attacks for protocols sharing common keys, the two-octet OSPFv3 Cryptographic Protocol ID is appended to the Authentication Key prior to use. Other protocols using Cryptographic Authentication as specified herein MUST similarly append their respective Cryptographic Protocol IDs to their keys in this step. Refer to the IANA Considerations (Section 7) 🌈
4.5. Cryptographic Aspects 🔐
okay so before we get into the algorithm, we need to agree on the nomenclature. it's consistent with [FIPS-198-1], so the names are gonna look familiar if you've seen that doc 🤓
- H is the specific hashing algorithm (e.g., SHA-256).
- K is the Authentication Key from the OSPFv3 Security Association.
- Ks is a Protocol-Specific Authentication Key obtained by appending Authentication Key (K) with the two-octet OSPFv3 Cryptographic Protocol ID.
- Ko is the cryptographic key used with the hash algorithm.
- B is the block size of H, measured in octets rather than 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 rather than bits.
- XOR is the exclusive-or operation.
- Opad is the hexadecimal value
0x5crepeated B times. - Ipad is the hexadecimal value
0x36repeated B times. - Apad is a value that is the same length as the hash output or message digest. The first 16 octets contain the IPv6 source address followed by the hexadecimal value
0x878FE1F3repeated(L-16)/4times. This implies that hash output is always a length of at least 16 octets. ✨
1. Preparation of the Key
The OSPFv3 Cryptographic Protocol ID gets appended to the Authentication Key (K), and that gives you a Protocol-Specific Authentication Key (Ks). In this application, Ko is always L octets long, and it's computed like this:
- If the Protocol-Specific Authentication Key (Ks) is L octets long, then Ko is equal to K.
- If the Protocol-Specific Authentication Key (Ks) is more than L octets long, then Ko is set to H(Ks).
- If the Protocol-Specific Authentication Key (Ks) is less than L octets long, then Ko is set to the Protocol-Specific Authentication Key (Ks) with zeros appended to the end of it, so that Ko ends up L octets long. 🧩
2. First-Hash
First up, the OSPFv3 packet's Authentication Data field in the Authentication Trailer gets filled with the value Apad. this is very similar to the appendage described in [RFC2328], Section D.4.3, Items (6)(a) and (6)(d)). 💜
Then we compute a First-Hash, which is also called the inner hash:
First-Hash = H(Ko XOR Ipad || (OSPFv3 Packet))Implementation Note: The First-Hash above includes the Authentication Trailer, as well as the OSPFv3 packet, as per [RFC2328], Section D.4.3, and, if present, the LLS data block [RFC5613].
The definition of Apad (above) makes sure it's always the same length as the hash output, which is consistent with RFC 2328. Also, the "(OSPFv3 Packet)" in the First-Hash function includes both the optional LLS data block and the OSPFv3 Authentication Trailer. 🎀
The digest length is 20 octets for SHA-1, 32 octets for SHA-256, 48 octets for SHA-384, and 64 octets for SHA-512.
3. Second-Hash
Then we compute a Second-Hash, also known as the outer hash:
Second-Hash = H(Ko XOR Opad || First-Hash)4. Result
The resulting Second-Hash becomes the authentication data that gets sent in the Authentication Trailer of the OSPFv3 packet. The length of that authentication data is always identical to the message digest size of whichever hash function H you're using. 🦋
This also means that hash functions with larger output sizes make the OSPFv3 packet bigger on the wire. chonk alert 😭
Implementation Note: [RFC2328], Appendix D specifies that the Authentication Trailer is not counted in the OSPF packet's own Length field, but it is included in the packet's IP Length field. Similarly, the Authentication Trailer is not included in the OSPFv3 header length, but it is included in the IPv6 header payload length.
4.6. Message Verification 🔍
so a router figures out that OSPFv3 is using an Authentication Trailer by checking the AT-bit in the Options field of the OSPFv3 header, for Hello and Database Description packets. The specification in the Hello and Database Description options says that other OSPFv3 packets will include the Authentication Trailer. 👀
The Authentication Trailer (AT) is found by using the OSPFv3 packet header length to get to the data after the OSPFv3 packet. If there's an LLS data block [RFC5613] present, you use the LLS data block length to get to the data after that. To know whether an LLS data block is there at all, you check the L-bit in the OSPFv3 options in Hello and Database Description packets. If the L-bit says an LLS data block is present, it gets included along with the OSPFv3 Hello or Database Description packet in the cryptographic authentication computation. 🧠
Here's the bit that matters most: because the AT sits after the LLS data block, and the LLS data block is included in the Cryptographic Authentication computation, OSPFv3 routers supporting this specification MUST minimally support examining the L-bit in the OSPFv3 options and using the length in the LLS data block to access the AT. It is RECOMMENDED that OSPFv3 routers supporting this specification fully support OSPFv3 Link-Local Signaling [RFC5613]. ✨
If usage of the Authentication Trailer (AT), as specified here, is configured for an OSPFv3 link, OSPFv3 Hello and Database Description packets with the AT-bit clear in the options will be dropped. All OSPFv3 packet types will be dropped if AT is configured for the link and the IPv6 header length is less than the amount necessary to include an Authentication Trailer. 🚫
If the cryptographic sequence number in the AT is less than or equal to the last sequence number successfully received from the neighbor, the OSPFv3 packet MUST be dropped, and an error event SHOULD be logged. replay attacks, not on my watch 🙅♀️
Authentication-algorithm-dependent processing needs to be performed, using the algorithm specified by the appropriate OSPFv3 SA for the received packet. 🔑
Before an implementation does any processing, it needs to save the values of the Authentication Data field from the Authentication Trailer appended to the OSPFv3 packet. 💾
It should then set the Authentication Data field with Apad before the authentication data is computed (as described in Section 4.5). The calculated data gets compared with the received authentication data in the Authentication Trailer. If the two do not match, the packet MUST be discarded and an error event SHOULD be logged. 💅
After the OSPFv3 packet has been successfully authenticated, implementations MUST store the 64-bit cryptographic sequence number for future replay checks. 🫶
5. Migration and Backward Compatibility 🚚
All OSPFv3 routers participating on a link SHOULD be migrated to OSPFv3 Authentication at the same time. Just like with OSPFv2 authentication, a mismatch in the SA ID, Authentication Type, or message digest will result in failure to form an adjacency. 💔
For multi-access links, communities of OSPFv3 routers could be migrated using different Interface Instance IDs. However, at least one router would need to form adjacencies between both the OSPFv3 routers including and not including the Authentication Trailer. This would result in sub-optimal routing, plus added complexity, and it is only recommended in cases where authentication is desired on the link and migrating all the routers on the link at the same time isn't feasible. 🌀
For uninterrupted deployment, an OSPFv3 router implementing this specification MAY implement a transition mode. In that mode it includes the Authentication Trailer in transmitted packets but does not verify this information in received packets. It's provided as a transition aid for networks that are in the process of migrating to the authentication mechanism described in this specification. 🌸
6. Security Considerations 🛡️
This document proposes extensions to OSPFv3 that would make it more secure than [RFC5340]. It does not provide confidentiality, because a routing protocol carries information that doesn't need to be kept secret. It does, however, provide means to authenticate the sender of the packets that are of interest. It addresses all the security issues that have been identified in [RFC6039]. 🔒
It should be noted that the authentication method described in this document is not being used to authenticate the specific originator of a packet. It's rather being used to confirm that the packet has indeed been issued by a router that has access to the Authentication Key. 🧐
Deployments SHOULD use sufficiently long and random values for the Authentication Key, so that guessing and other cryptographic attacks on the key are not feasible in their environments. Furthermore, it is RECOMMENDED that Authentication Keys incorporate at least 128 pseudo-random bits to minimize the risk of such attacks. In support of these recommendations, management systems SHOULD support hexadecimal input of Authentication Keys. 🚨
The mechanism described here is not perfect, and it does not need to be perfect. Instead, it represents a significant increase in the effort an adversary needs to successfully attack the OSPFv3 protocol, without causing undue implementation, deployment, or operational complexity. 💪
Refer to [RFC4552] for additional considerations on manual keying. 🗝️
7. IANA Considerations 📋
IANA has allocated the AT-bit (0x000400) in the "OSPFv3 Options (24 bits)" registry, as described in Section 2.1. 🦋
IANA has created the "OSPFv3 Authentication Trailer Options" registry. This new registry initially includes the "OSPFv3 Authentication Types" registry, which defines valid values for the Authentication Type field in the OSPFv3 Authentication Trailer. The registration procedure is Standards Action.
+-------------+-----------------------------------+
| Value/Range | Designation |
+-------------+-----------------------------------+
| 0 | Reserved |
| | |
| 1 | HMAC Cryptographic Authentication |
| | |
| 2-65535 | Unassigned |
+-------------+-----------------------------------+OSPFv3 Authentication Types
Finally, IANA has created the "Keying and Authentication for Routing Protocols (KARP) Parameters" category. This new category initially includes the "Authentication Cryptographic Protocol ID" registry, which provides unique protocol-specific values for cryptographic applications, such as (but not limited to) prevention of cross-protocol replay attacks. Values can be assigned for both native IPv4/IPv6 protocols and UDP/TCP protocols. The registration procedure is Standards Action. ✨
+-------------+----------------------+
| Value/Range | Designation |
+-------------+----------------------+
| 0 | Reserved |
| | |
| 1 | OSPFv3 |
| | |
| 2-65535 | Unassigned |
+-------------+----------------------+Cryptographic Protocol ID
8. References 📚
The reference list didn't come through in this part of the source, so there's nothing to list here yet. 🥺
8.1. Normative References ✨
okay bestie, the normative references are the ones you MUST have read to actually implement this thing, so pay attention 💅
[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🎀 (this is the one that defines all those capital-letter key words, so it's giving foundational)[RFC2328]Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 🦋[RFC5340]Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008. 🌈[RFC5709]Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic Authentication", RFC 5709, October 2009. 💜 (the OG that this whole spec was built on, literally iconic)
8.2. Informative References 🧚
these ones are the extra reading, not required, but lowkey super useful if you want the full story 🫶
[FIPS-180-3]US National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-3, October 2008. 🔥[FIPS-198-1]US National Institute of Standards and Technology, "The Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB 198, July 2008. 🌸[MANUAL-KEY]Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, "Security Extension for OSPFv2 when using Manual Key Management", Work in Progress, October 2011. 🙈 (still a draft, so it's a work in progress, not a finished RFC, just so you know)[RFC2104]Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. ✨[RFC4302]Kent, S., "IP Authentication Header", RFC 4302, December 2005. 🎀[RFC4303]Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. 🦋[RFC4552]Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, June 2006. 🌈[RFC5613]Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. Yeung, "OSPF Link-Local Signaling", RFC 5613, August 2009. 💜[RFC5996]Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. 🔥[RFC6039]Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues with Existing Cryptographic Protection Methods for Routing Protocols", RFC 6039, October 2010. 🌸[RFC6234]Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. ✨
Appendix A. Acknowledgments 🌷
first and foremost, huge thanks to the authors of [RFC5709], because this whole work was derived from it 💖
thanks to Sam Hartman for talking through replay mitigation and the use of a 64-bit strictly increasing sequence number 🧚 also thanks to Sam for comments during IETF last call about the OSPFv3 SA and sharing a key between protocols 🫶
thanks to Michael Barnes for tons of comments and strong input on how LLS is covered by the Authentication Trailer (AT) 💅
thanks to Rajesh Shetty for lots of comments, including the suggestion to add an Authentication Type field to the Authentication Trailer for extendibility 🦋
thanks to Uma Chunduri for suggesting we might want to protect the IPv6 source address, even though OSPFv3 uses the Router ID for neighbor identification 🌈
thanks to Srinivasan KL, Shraddha H, Alan Davey, Russ White, Stan Ratliff, and Glen Kent for their support and review comments 💜
thanks to Alia Atlas for comments made under the Routing Directorate review 🌸
thanks to Stephen Farrell for comments during the IESG review, and Stephen was also involved in the discussion of cross-protocol attacks 👑
Authors' Addresses 💌
Manav Bhatia Alcatel-Lucent Bangalore India
EMail: manav.bhatia@alcatel-lucent.com
Vishwas Manral Hewlett Packard USA
EMail: vishwas.manral@hp.com
Acee Lindem Ericsson 102 Carric Bend Court Cary, NC 27519 USA
EMail: acee.lindem@ericsson.com
and that's the whole spec, bestie!! 🎀✨🌈 we did it 😭💖
📦 where this page comes from
- ietf: rfc6506 2012-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms