RFC 7166
Supporting Authentication Trailer for OSPFv3
RFC 7166: Supporting Authentication Trailer for OSPFv3 💖
Okay so, this one is from the IETF (Internet Engineering Task Force), dated March 2014. It's a Standards Track document with ISSN 2070-1721. The authors are M. Bhatia (Alcatel-Lucent), V. Manral (Ionos Corp.), and A. Lindem (Ericsson). It obsoletes RFC 6506, and the header doesn't list any RFC it updates. Bestie, this is giving main character energy 🎀
Abstract ✨
Right now, OSPF for IPv6 (OSPFv3) uses IPsec as its only way to authenticate protocol packets 🙈 That's different from what the other routing protocols do (OSPFv2, Intermediate System to Intermediate System (IS-IS), RIP, and Routing Information Protocol Next Generation (RIPng)). In some environments, IPsec has turned out to be a pain to configure and maintain, so it just can't be used there 💀 This document defines an alternative way to authenticate OSPFv3 packets, so OSPFv3 doesn't depend only on IPsec for authentication 🔥
The OSPFv3 Authentication Trailer was first defined in RFC 6506. This document obsoletes RFC 6506 with a revised definition that adds clarifications and refinements to the procedures 🦋
Status of This Memo 📜
This is an Internet Standards Track document ✨
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check out Section 2 of RFC 5741 🌸
Info about the current status of this document, any errata, and how to send feedback is at http://www.rfc-editor.org/info/rfc7166 🧚
Copyright Notice 💅
Copyright (c) 2014 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 they're in effect on the date this document was published. Please review those documents carefully, because they describe your rights and restrictions with respect to 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're provided without warranty as described in the Simplified BSD License 🫶
Table of Contents 🗂️
1. Introduction ....................................................3
1.1. Requirements ...............................................4
1.2. Summary of Changes from RFC 6506 ...........................4
2. Proposed Solution ...............................................5
2.1. AT-Bit in Options Field ....................................5
2.2. Basic Operation ............................................6
2.3. IPv6 Source Address Protection .............................6
3. OSPFv3 Security Association .....................................7
4. Authentication Procedure ........................................9
4.1. Authentication Trailer .....................................9
4.1.1. Sequence Number Wrap ...............................11
4.2. OSPFv3 Header Checksum and LLS Data Block Checksum ........11
4.3. Cryptographic Authentication Procedure ....................12
4.4. Cross-Protocol Attack Mitigation ..........................12
4.5. Cryptographic Aspects .....................................12
4.6. Message Verification ......................................15
5. Migration and Backward Compatibility ...........................16
6. Security Considerations ........................................17
7. IANA Considerations ............................................18
8. References .....................................................19
8.1. Normative References ......................................19
8.2. Informative References ....................................19
Appendix A. Acknowledgments .......................................221. Introduction ✨
Okay so, unlike Open Shortest Path First version 2 (OSPFv2) [RFC2328], OSPF for IPv6 (OSPFv3) [RFC5340] doesn't have the AuType and Authentication fields in its headers for authenticating protocol packets 😭 Instead, OSPFv3 leans 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 honestly, some environments, like Mobile Ad Hoc Networks (MANETs), find IPsec hard to configure and maintain, so this mechanism just can't be used there 🙈
[RFC4552] goes deep on 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 are formed on a one-to-many basis and most key management mechanisms are built for a one-to-one communication model. That forces the system administrator to use manually configured Security Associations (SAs) and cryptographic keys to provide the authentication and, if wanted, confidentiality services 💅
About replay protection, [RFC4552] says:
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] 💀
Techniques to identify ESP-NULL packets do exist [RFC5879], but they're generally not implemented in the data planes of OSPFv3 routers. That makes it really hard for implementations to examine OSPFv3 packets and prioritize certain types, like Hello packets, over the others 😤
This document defines a mechanism that works similarly to OSPFv2 [RFC5709] to authenticate OSPFv3 packets, and it solves the replay protection problems and the deterministic disambiguation of different OSPFv3 packets described above 👑
This document also adds support for the Secure Hash Algorithms (SHAs) defined in the US NIST Secure Hash Standard (SHS), which is specified by NIST FIPS 180-4 [FIPS-180-4]. [FIPS-180-4] 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 too ✨
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] 🫶
1.2. Summary of Changes from RFC 6506 🔄
Here's what's new compared to RFC 6506 [RFC6506] 👀
- Sections 2.2 and 4.2 now explicitly say that the Link-Local Signaling (LLS) block checksum calculation gets skipped when an OSPFv3 Authentication Trailer is used for OSPFv3 authentication. The LLS data block is included in the authentication digest calculation, so computing a checksum is unnecessary. This was cleared up in an erratum 🧚
- Section 3 used to recommend using an expired key for transmitted OSPFv3 packets when no valid keys existed. That statement has been removed 🗑️
- Section 4.5 has a correction to the key preparation: it uses the Protocol-Specific Authentication Key (Ks) rather than the Authentication Key (K) as the initial key (Ko). This problem was also documented in an erratum 🩹
- Section 4.5 also discusses choosing the key length to be the hash length (L) rather than the block size (B). That discussion was added to clear up an issue raised in a rejected erratum 🤓
- Sections 4.1 and 4.6 say that sequence number checking depends on the OSPFv3 packet type, so packet prioritization as specified in [RFC4222] gets accounted for. This was an omission from RFC 6506 [RFC6506] 😅
- Section 4.6 now explicitly states that OSPFv3 packets with a nonexistent or expired Security Association (SA) will be dropped 🚫
- Section 5 includes guidance on the precise actions required for an OSPFv3 router providing a backward-compatible transition mode 🌸
2. Proposed Solution 🎀
So to do non-IPsec Cryptographic Authentication, OSPFv3 routers tack a special data block, called the Authentication Trailer from here on, onto the end of the OSPFv3 packets 💖 The length of the Authentication Trailer isn't included in the length of the OSPFv3 packet, but it is included in the IPv6 payload length, as you can see 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 |
| LL = LLS Data | | Block | | LL = LLS Data |
| Block Length | v Length v | Block Length |
+---------------------+ -- -- +----------------------+
^ | |
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 the LLS data block is there, it gets included along with the OSPFv3 packet in the Cryptographic Authentication computation 🦋
2.1. AT-Bit in Options Field ✨
okay so RFC 6506 introduced the AT-bit ("AT" stands for "Authentication Trailer") into the OSPFv3 Options field 🫶. OSPFv3 routers MUST set the AT-bit in OSPFv3 Hello and Database Description packets to say 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 AT-bit setting from the Hello/Database Description setting gets saved in the OSPFv3 neighbor data structure. OSPFv3 packet types that don't include an OSPFv3 Options field use the setting from the neighbor data structure to figure out 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 Field
The 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 we compute the Authentication Trailer is pretty much the same as in [RFC5709] and [RFC2328] 🦋. one difference: the LLS data block, if there is one, gets included in the Cryptographic Authentication computation.
the way the authentication data gets carried in the Authentication Trailer is super similar to [RFC2328]. the only real difference between the OSPFv2 Authentication Trailer and the OSPFv3 Authentication Trailer is that the OSPFv3 one has extra info on top of the message digest. that extra info gets included in the message digest computation, so it's protected by OSPFv3 Cryptographic Authentication too, as described here 🔥.
consistent with OSPFv2 Cryptographic Authentication [RFC2328] and Link-Local Signaling Cryptographic Authentication [RFC5613], checksum calculation and verification are skipped for both the OSPFv3 header checksum and the LLS data block when the OSPFv3 authentication mechanism in this specification is used 🌸.
2.3. IPv6 Source Address Protection 🛡️
okay this part is lowkey important 😭. OSPFv3 always uses the Router ID to identify OSPFv3 neighbors, but the IPv6 source address is learned from OSPFv3 Hello packets and copied into the neighbor data structure [RFC5340]. so OSPFv3 is 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. see Section 4.5 for the details ✨. this is different from the procedure in [RFC5709], but it's consistent with [MANUAL-KEY] 💜.
3. OSPFv3 Security Association 🧚
an OSPFv3 Security Association (SA) is a set of parameters shared between any two legitimate OSPFv3 speakers 🎀.
these are the parameters associated with an OSPFv3 SA:
- Security Association Identifier (SA ID) 🆔
- This is a 16-bit unsigned integer used to uniquely identify an OSPFv3 SA, as manually configured by the network operator.
- The receiver figures out the active SA by looking at the SA ID field in the incoming protocol packet.
- The sender, based on the active configuration, picks an SA to use and puts the correct Key ID value associated with that 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 keeping protocol operation running really 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.
- heads up: each SA ID can point to a key with a different authentication algorithm. this means new authentication mechanisms can get introduced without disrupting existing OSPFv3 adjacencies 🌈.
- Authentication Algorithm 🧮
- this signifies the authentication algorithm to be used with this OSPFv3 SA. this info is never sent in clear text over the wire. because it isn't sent on the wire, the implementer chooses an implementation-specific representation for it.
- currently, these algorithms are supported:
- HMAC-SHA-1,
- HMAC-SHA-256,
- HMAC-SHA-384, and
- HMAC-SHA-512.
- Authentication Key 🗝️
- this value is the Cryptographic Authentication Key associated with this OSPFv3 SA. its length is variable and depends on the authentication algorithm specified by the OSPFv3 SA.
- KeyStartAccept ⏰
- this value is the time that this OSPFv3 router will accept packets that have been created with this OSPFv3 SA.
- KeyStartGenerate 🚀
- this value is the time that this OSPFv3 router will begin using this OSPFv3 SA for OSPFv3 packet generation.
- KeyStopGenerate 🛑
- this value is the time that this OSPFv3 router will stop using this OSPFv3 SA for OSPFv3 packet generation.
- KeyStopAccept 🚪
- this value is the time that this OSPFv3 router will stop accepting packets generated with this OSPFv3 SA.
- for a smooth key transition, KeyStartAccept SHOULD be less than KeyStartGenerate, and KeyStopGenerate SHOULD be less than KeyStopAccept. if KeyStartGenerate or KeyStartAccept is left unspecified, the time defaults to 0, and the key gets used immediately. if KeyStopGenerate or KeyStopAccept is left unspecified, the time defaults to infinity, and the key's lifetime is infinite ♾️.
- when a new key replaces an old key, 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, to avoid operational issues. if the last key associated with an interface expires, the network operator SHOULD be notified, and the OSPFv3 packet MUST NOT be transmitted unauthenticated 😱.
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 Format
here are the fields in the Authentication Trailer, bestie 📝:
- Authentication Type 🏷️
- this 16-bit field identifies the type of authentication. these values are defined in this specification:
0 - Reserved.
1 - HMAC Cryptographic Authentication as described herein.- Auth Data Len 📏
- this is 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.
- even though the SA ID 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 used to guard against replay attacks. the 64-bit sequence number MUST be incremented for every OSPFv3 packet sent by the OSPFv3 router. on reception, the sequence number MUST be greater than the sequence number in the last accepted OSPFv3 packet of the same OSPFv3 packet type from the sending OSPFv3 neighbor. otherwise, the OSPFv3 packet is considered a replayed packet and dropped 🚫.
- OSPFv3 packets of different types may arrive out of order if they are prioritized as recommended in [RFC4222].
- 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 this would be to use the high-order 32 bits of the sequence number as a wrap/boot count that gets incremented any time the OSPFv3 router loses its sequence number state. sequence number wrap is described in Section 4.1.1 🔄.
- Authentication Data 📦
- this field contains variable data that carries the digest for the protocol packet and 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 could 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 and LLS Data Block Checksum 🎀
okay so bestie, when the OSPFv3 authentication mechanism from this spec is in use, the checksum math gets skipped for BOTH the OSPFv3 header checksum and the LLS data block checksum [RFC5613]. no cap, here's what that looks like:
- For OSPFv3 packets being sent, the header checksum computation gets skipped, and the header checksum SHOULD be set to 0 before the Authentication Trailer message digest is computed. 💅
- For OSPFv3 packets with an LLS data block being sent, the LLS data block checksum computation gets skipped, and that checksum SHOULD be set to 0 before the message digest is computed. ✨
- For received OSPFv3 packets with an Authentication Trailer, header checksum verification MUST be omitted. 🧚 but if the packet does have a non-zero header checksum, the receiver won't touch it. it just gets included in the message digest verification.
- For received OSPFv3 packets with both an LLS data block and an Authentication Trailer, LLS data block checksum verification MUST be omitted. 🫶 same deal: a non-zero checksum stays exactly as it is and just gets baked into the digest check.
4.3. Cryptographic Authentication Procedure 🔐
remember how the SA ID tells you which algorithm and secret key to use for making and checking the message digest? yep, this is that part. this spec covers the OSPFv3 Cryptographic Authentication computation when any algorithm from the NIST SHS family is used in HMAC mode. 🦋
the currently valid algorithms (including mode) for OSPFv3 Cryptographic Authentication are:
- HMAC-SHA-1,
- HMAC-SHA-256,
- HMAC-SHA-384, and
- HMAC-SHA-512.
okay so out of those, implementations of this specification MUST include support for at least HMAC-SHA-256, SHOULD include support for HMAC-SHA-1, and MAY also include support for HMAC-SHA-384 and HMAC-SHA-512. 📊
and implementations of this specification MUST use HMAC-SHA-256 as the default authentication algorithm. 👑
4.4. Cross-Protocol Attack Mitigation 🛡️
so nobody can pull off a cross-protocol replay attack when protocols share the same keys, the two-octet OSPFv3 Cryptographic Protocol ID gets appended to the Authentication Key before it's used. 🔑 and any other protocol using Cryptographic Authentication as specified here MUST do the same thing with its own Cryptographic Protocol ID. see the IANA Considerations (Section 7) for more. 💜
4.5. Cryptographic Aspects 🧮
before we get into the algorithm, here's the nomenclature. it's consistent with [FIPS-198-1], so it's giving official vibes:
His the specific hashing algorithm (e.g., SHA-256).Kis the Authentication Key from the OSPFv3 Security Association.Ksis a Protocol-Specific Authentication Key, made by appending the Authentication Key (K) with the two-octet OSPFv3 Cryptographic Protocol ID.Kois the cryptographic key used with the hash algorithm.Bis the block size ofH, measured in octets rather than bits. note thatBis the internal block size, not the hash size.
For SHA-1 and SHA-256: B == 64
For SHA-384 and SHA-512: B == 128Lis the length of the hash, measured in octets rather than bits.- XOR is the exclusive-or operation.
Opadis the hexadecimal value0x5crepeatedBtimes.Ipadis the hexadecimal value0x36repeatedBtimes.Apadis a value that's the same length as the hash output or message digest. the first 16 octets contain the IPv6 source address, followed by the hexadecimal value0x878FE1F3repeated (L-16)/4 times. this means the hash output is always at least 16 octets long. 🌸
1. Preparation of the Key 🗝️
the OSPFv3 Cryptographic Protocol ID gets appended to the Authentication Key (K), giving you a Protocol-Specific Authentication Key (Ks). in this application, Ko is always L octets long. [RFC2104] supports a key up to B octets long, but this application uses L as the Ks length, consistent with [RFC4822], [RFC5310], and [RFC5709]. according to [FIPS-198-1], Section 3, keys longer than L octets don't significantly increase the function strength. so Ks gets computed like this:
If Ks is L octets long, then Ko is equal to Ks. If Ks is more
than L octets long, then Ko is set to H(Ks). If Ks is less
than L octets long, then Ko is set to the value of Ks, with
zeros appended to the end of Ks such that Ko is L octets long.2. First-Hash 🔁
first, the Authentication Data field in the OSPFv3 packet's Authentication Trailer gets filled with the value Apad. this is very similar to the appendage described in [RFC2328], Appendix D.4.3, Items (6)(a) and (6)(d)).
then the First-Hash (aka the inner hash) is computed:
First-Hash = H(Ko XOR Ipad || (OSPFv3 Packet))when XORing Ko and Ipad, Ko gets padded with zeros to the length of Ipad.
Implementation Note: the First-Hash above includes the Authentication Trailer as well as the OSPFv3 packet, as per [RFC2328], Appendix D.4.3, and the LLS data block, if present [RFC5613]. ✨
the definition of Apad (above) makes sure it's always the same length as the hash output. this 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 the Second-Hash (aka the outer hash) is computed:
Second-Hash = H(Ko XOR Opad || First-Hash)when XORing Ko and Opad, Ko gets padded with zeros to the length of Opad.
4. Result 🎉
the resulting Second-Hash becomes the authentication data that's sent in the Authentication Trailer of the OSPFv3 packet. the length of the authentication data is always identical to the message digest size of whichever hash function H is being used.
this also means that hash functions with bigger output sizes make the OSPFv3 packet bigger on the wire. 📦
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 🔍
a router figures out that OSPFv3 is using an Authentication Trailer (AT) by checking the AT-bit in the Options field of the OSPFv3 header for Hello and Database Description packets. the options in those Hello and Database Description packets say that the other OSPFv3 packet types will include the Authentication Trailer. 👀
the AT is accessed by using the OSPFv3 packet header length to reach the data after the OSPFv3 packet. if an LLS data block [RFC5613] is present, the LLS data block length gets used to reach the data after the LLS data block. the L-bit in the OSPFv3 options in Hello and Database Description packets is checked to see if an LLS data block is present. if one is present (as the L-bit says), it's included along with the OSPFv3 Hello or Database Description packet in the Cryptographic Authentication computation. 🧩
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 AT 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 the AT is configured for the link and the IPv6 header length is less than the amount needed to include an Authentication Trailer. 💀
the receiving interface's OSPFv3 SA is located using the SA ID in the received AT. if the SA is not found, or if the SA isn't valid for reception (i.e., current time < KeyStartAccept or current time >= KeyStopAccept), the OSPFv3 packet gets dropped. 🙅♀️
if the cryptographic sequence number in the AT is less than or equal to the last sequence number in the last OSPFv3 packet of the same OSPFv3 type successfully received from the neighbor, the OSPFv3 packet MUST be dropped, and an error event SHOULD be logged. OSPFv3 packets of different types may arrive out of order if they are prioritized as recommended in [RFC4222]. 🔢
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 is 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 each OSPFv3 packet type received from the neighbor. the saved cryptographic sequence numbers will be used for replay checking for subsequent packets received from the neighbor. 🔒
5. Migration and Backward Compatibility 🦋
okay so the big rule here is that all the OSPFv3 routers on a link SHOULD get migrated to OSPFv3 authentication at the same time 🫶. Just like with OSPFv2 authentication, if the SA ID, Authentication Type, or message digest doesn't match, the adjacency literally won't form 💀. For multi-access links, you could migrate different groups of routers using different Interface Instance IDs, but then at least one router would have to form adjacencies with both the routers that have the Authentication Trailer and the ones that don't. That gives you sub-optimal routing AND extra complexity, so it's only recommended if you really want authentication on the link and migrating everyone at once just isn't doable 🙈.
To keep the rollout smooth, an OSPFv3 router implementing this specification MAY implement a transition mode 🌸. In transition mode, it includes the Authentication Trailer in the packets it sends, but it doesn't verify that info in the packets it receives. It's a transition aid for networks that are in the middle of moving over to the authentication mechanism in this spec. Here's how it works:
- OSPFv3 routers in transition mode will include the OSPFv3 Authentication Trailer in transmitted packets and set the AT-bit in the Options field of transmitted Hello and Database Description packets. OSPFv3 routers receiving these packets and not having authentication configured will ignore the Authentication Trailer and AT-bit.
- OSPFv3 routers in transition mode will also calculate and set the OSPFv3 header checksum and the LLS data block checksum in transmitted packets so that they will not be dropped by OSPFv3 routers without authentication configured.
- OSPFv3 routers in transition mode will authenticate received packets that either have the AT-bit set in the Options field for Hello or Database Description packets or are from a neighbor that previously set the AT-bit in the Options field of successfully authenticated Hello and Database Description packets.
- OSPFv3 routers in transition mode will also accept packets without the Options field AT-bit set in Hello and Database Description packets. These packets will be assumed to be from OSPFv3 routers without authentication configured, and they will not be authenticated. Additionally, the OSPFv3 header checksum and LLS data block checksum will be validated.
6. Security Considerations 🔐
okay the security part is SO important bestie 😭. This document adds extensions to OSPFv3 that make it way more secure than the plain OSPFv3 from [RFC5340]. It does NOT give confidentiality, because a routing protocol carries info that doesn't need to be secret. What it does do is give you a way to authenticate the sender of the packets that actually matter 🧚. It also deals with all the security issues flagged in [RFC6039] and [RFC6506] ✨.
Also, be careful here: the authentication method in this doc isn't really proving which specific router sent a packet. It's confirming the packet came from a router that has access to the Authentication Key 🔑.
Deployments SHOULD use Authentication Keys that are sufficiently long and random, so that guessing and other cryptographic attacks on the key aren't feasible in their environment 💅. On top of that, it is RECOMMENDED that Authentication Keys include at least 128 pseudorandom bits to lower the risk of those attacks 🫣. To back this up, management systems SHOULD support hexadecimal input of Authentication Keys.
Deployments that support a transitionary state but interoperate with routers that do not support this authentication method may be exposed to unauthenticated data during the transition period. This is a real risk, so plan your rollout with it in mind 🚨.
The mechanism described here isn't perfect, and it doesn't need to be perfect 🌈. What it does do is massively raise the effort an attacker needs to successfully go after OSPFv3, all without piling on undue implementation, deployment, or operational complexity 👑. For more on manual keying, check [RFC4552] 🎀.
7. IANA Considerations 📋
This document obsoletes RFC 6506, so IANA updated the references in existing registries that pointed to RFC 6506 so they now point to this document ✨. That's the only IANA action this document asks for.
IANA already allocated the AT-bit (0x000400) in the "OSPFv3 Options (24 bits)" registry, as described in Section 2.1 💜.
IANA also previously created the "Open Shortest Path First v3 (OSPFv3) Authentication Trailer Options" registry 🍓. That registry includes the "OSPFv3 Authentication Types" registry, which defines the valid values for the Authentication Type field in the OSPFv3 Authentication Trailer. The registration procedure is Standards Action [RFC5226].
+-------------+-----------------------------------+
|Value | Designation |
+-------------+-----------------------------------+
| 0 | Reserved |
| | |
| 1 | HMAC Cryptographic Authentication |
| | |
| 2-65535 | Unassigned |
+-------------+-----------------------------------+
OSPFv3 Authentication TypesFinally, IANA previously created the "Keying and Authentication for Routing Protocols (KARP) Parameters" registry 🌸. This registry includes the "Cryptographic Protocol ID" registry, which gives unique protocol-specific values for cryptographic applications, including (but not limited to) preventing 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 ID8. References 📚
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.8.2. Informative References
[FIPS-180-4]
US National Institute of Standards and Technology, "Secure
Hash Standard (SHS)", FIPS PUB 180-4, March 2012.
[FIPS-198-1]
US National Institute of Standards and Technology, "The
Keyed-Hash Message Authentication Code (HMAC)", FIPS
PUB 198-1, July 2008.
[MANUAL-KEY]
Bhatia, M., Hartman, S., and D. Zhang, "Security Extension
for OSPFv2 when using Manual Key Management", Work in
Progress, February 2011.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC4222] Choudhury, G., Ed., "Prioritized Treatment of Specific
OSPF Version 2 Packets and Congestion Avoidance", BCP 112,
RFC 4222, October 2005.
[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.
[RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic
Authentication", RFC 4822, February 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic
Authentication", RFC 5310, February 2009.
[RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D.
Yeung, "OSPF Link-Local Signaling", RFC 5613, August 2009.
[RFC5879] Kivinen, T. and D. McDonald, "Heuristics for Detecting
ESP-NULL Packets", RFC 5879, May 2010.
[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.
[RFC6506] Bhatia, M., Manral, V., and A. Lindem, "Supporting
Authentication Trailer for OSPFv3", RFC 6506,
February 2012.Appendix A. Acknowledgments 🧡
First and foremost, big thanks to the US National Institute of Standards and Technology for their work on the SHA [FIPS-180-4] and HMAC [FIPS-198-1] 🙌.
Thanks also to the authors of the HMAC-SHA authentication RFCs, including [RFC4822], [RFC5310], and [RFC5709] 💖. The basic HMAC-SHA procedures were originally described by Ran Atkinson in [RFC4822].
Also, thanks to Ran Atkinson for helping analyse the RFC 6506 errata 🔍.
Thanks to Srinivasan K L and Marek Karasek for identifying and submitting the RFC 6506 errata 🫶.
Thanks to Sam Hartman for discussions on 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 the sharing of keys between protocols 🔑.
Thanks to Michael Barnes for lots of comments and strong input on how LLS is covered by the Authentication Trailer (AT) 🌟.
Thanks to Marek Karasek for providing the specifics on backward-compatible transition mode 🦋.
Thanks to Michael Dubrovskiy and Anton Smirnov for comments on document revisions 🌷.
Thanks to Rajesh Shetty for numerous comments, including the suggestion to add an Authentication Type field to the Authentication Trailer for extendibility 🎀.
Thanks to Uma Chunduri for suggesting that we might want to protect the IPv6 source address, even though OSPFv3 uses the Router ID for neighbor identification 💅.
Thanks to Srinivasan K L, 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 👑. Stephen was also involved in the discussion of cross-protocol attacks ⚡.
Thanks to Brian Carpenter for comments made during the Gen-ART review 🍓.
Thanks to Victor Kuarsingh for the OPS-DIR review 💜.
Thanks to Brian Weis for the SEC-DIR review 🫶.
Authors' Addresses ✨
okay bestie, this is where the three authors leave their contact info so you can slide into their DMs about the spec 💌 no cap, these are the people who wrote it 👑
Manav Bhatia 🦋
Manav Bhatia
Alcatel-Lucent
Bangalore
IndiaEMail: manav.bhatia@alcatel-lucent.com 💖
Vishwas Manral 🌸
Vishwas Manral
Ionos Corp.
4100 Moorpark Ave.
San Jose, CA 95117
USAEMail: vishwas@ionosnetworks.com 🫶
Acee Lindem 🧚
Acee Lindem
Ericsson
301 Midenhall Way
Cary, NC 27513
USAEMail: acee.lindem@ericsson.com 💅
📦 where this page comes from
- ietf: rfc7166 2014-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms