RFC 7474
Security Extension for OSPFv2 When Using Manual Key Management
RFC 7474: Security Extension for OSPFv2 When Using Manual Key Management 🦋
Okay bestie, this one is a Standards Track doc from the IETF, published April 2015 📅. It's giving "we fixed OSPFv2 crypto auth when you're using manual keys" 🔐. The ISSN is 2070-1721. It updates RFC 2328 and RFC 5709 🎀 and doesn't list anything it obsoletes.
The authors are M. Bhatia from Ionos Networks, S. Hartman from Painless Security, D. Zhang from Huawei Technologies Co., Ltd., and A. Lindem, Ed. from Cisco. "Ed." just means editor 💅
Abstract 🎀
Here's the tea ☕. The OSPFv2 crypto authentication from RFC 2328 and RFC 5709 is vulnerable to both inter-session and intra-session replay attacks when you're using manual keying 😭. On top of that, the existing mechanism doesn't cover the IP header, and attackers can totally exploit that to run all kinds of attacks 💀.
This doc changes the authentication sequence number mechanism so OSPFv2 is protected from both inter-session and intra-session replays when manual keys are securing the protocol packets 🔒. It also changes the cryptographic hash computation to kill the attacks that happen because OSPFv2 wasn't protecting the IP header 🔥.
Status of This Memo 📝
This is an Internet Standards Track document, bestie 🌈
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) ✨. For more on Internet Standards, check out Section 2 of RFC 5741 📚.
If you want the current status, any errata, or a way to give feedback, head to http://www.rfc-editor.org/info/rfc7474 💌
Copyright Notice ©️
The IETF Trust and the people listed as document authors own the copyright for 2015, and all rights are reserved 💖
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at http://trustee.ietf.org/license-info as they were in effect when this doc was published. Please actually read those, because they spell out your rights and restrictions for this document 🧐
One important bit: any Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions. They come with no warranty, as the Simplified BSD License describes 🫶
Table of Contents 🧚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Replay Protection Using Extended Sequence Numbers . . . . . . 4
3. OSPF Packet Extensions . . . . . . . . . . . . . . . . . . . 5
4. OSPF Packet Key Selection . . . . . . . . . . . . . . . . . . 6
4.1. Key Selection for Unicast OSPF Packet Transmission . . . 7
4.2. Key Selection for Multicast OSPF Packet Transmission . . 8
4.3. Key Selection for OSPF Packet Reception . . . . . . . . . 8
5. Securing the IP Header . . . . . . . . . . . . . . . . . . . 9
6. Mitigating Cross-Protocol Attacks . . . . . . . . . . . . . . 10
7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 12
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 141. Introduction 🌸
Okay so the OSPFv2 crypto auth in [RFC2328] uses per-packet sequence numbers to block replay attacks 🛡️. These numbers go up monotonically, so sneaky stale packets get thwarted ✨. The sequence number values live as part of neighbor adjacency state. That means if an adjacency goes down, the sequence numbers get reinitialized and neighbor adjacency formation starts all over again 😤.
And here's the kicker 💀: the crypto auth mechanism doesn't say how to handle a sequence number rolling over when it wraps. Attackers can use these gaps to pull off various replay attacks ([RFC6039]) 🙈. So this doc defines extensions to the authentication sequence number mechanism to fix all of that 💅.
Next, the crypto auth in [RFC2328], later updated in [RFC5709], doesn't include the IP header 😭. That means the source address in the IP header isn't protected, which opens the door to several attacks. For broadcast and NBMA (Non-Broadcast Multi-Access) networks, the OSPF spec requires implementations to use the IP header's source address to figure out which neighbor sent a packet. So if someone changes a packet's IP source address to a conflicting one, they can run a bunch of denial-of-service attacks ([RFC6039]) 🔥.
It gets worse 🫠. If a packet gets interpreted as coming from a different neighbor, that neighbor's received sequence number state might get updated incorrectly, which can wreck communication with a legit neighbor. Hello packets can get reflected so a neighbor looks like it only has one-way communication. And Database Description packets can get reflected too when the per-packet sequence numbers are far enough apart to disrupt an adjacency ([RFC6863]). This is the IP-layer issue from point 18 in Section 4 of [RFC6862] 🧩.
Now, [RFC2328] says implementations MUST offer keyed MD5 authentication. This will probably get deprecated in favor of the stronger algorithms described in [RFC5709] and required in [RFC6094] 👑.
So this doc makes a few simple changes to the crypto auth mechanism, as currently described in [RFC5709], to stop these IP-layer attacks 🦋✨.
1.1. Requirements Language 💜
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] 📖.
When they're used in lowercase, these words just mean their normal everyday thing, and they are not to be interpreted as described in RFC 2119 [RFC2119] 🙃.
2. Replay Protection Using Extended Sequence Numbers 🍓
Okay, bestie, the goal here is replay protection against both inter-session and intra-session replays 🔐. So the OSPFv2 sequence number gets expanded to 64 bits. The least significant 32-bit value holds a strictly increasing sequence number, and the most significant 32-bit value holds the boot count 🌈.
OSPFv2 implementations are required to keep the boot count in non-volatile storage for the deployment life of the OSPF router 💾. SNMP agents get the same requirement from the SNMPv3 security architecture, so check out snmpEngineBoots in Section 2.2 of [RFC3414] if you want the details 🧚.
Here's a fun problem 🙈. There's no room in the OSPFv2 packet for a 64-bit sequence number, so it gets stuffed into the 8 octets following the OSPFv2 packet. It MUST be included when calculating the OSPFv2 packet digest 🔥. Those extra 8 octets aren't counted in the OSPFv2 packet header length, but they are counted in the OSPFv2 header Authentication Data length and the IPv4 packet header length 💅.
The lower-order 32-bit sequence number MUST be incremented for every OSPF packet the OSPF router sends ✨. When a packet comes in, its sequence number MUST be greater than the sequence number in the last OSPF packet of that type accepted from the sending OSPF neighbor. If it isn't, the packet counts as a replay and gets dropped 🚫. OSPF packets of different types can arrive out of order if they get prioritized as recommended in [RFC4222] 🫶.
OSPF routers implementing this spec MUST use available mechanisms to keep the sequence number's strictly increasing property for the deployed life of the OSPFv2 router, including cold restarts 🧊. They do this by keeping a boot count in non-volatile storage and bumping it every time the OSPF router loses its prior sequence number state 📈. The SNMPv3 snmpEngineBoots variable [RFC3414] MAY be used for this purpose 🌸.
That said, keeping a separate boot count just for OSPF sequence numbers has a perk 💖: it decouples SNMP reinitialization from OSPF reinitialization. Also, in the rare event that the lower-order 32-bit sequence number wraps, the boot count can be incremented to keep the aggregate sequence number strictly increasing 🎀. So a separate OSPF boot count is RECOMMENDED 👑.
3. OSPF Packet Extensions ✨
okay so the OSPF packet header has an authentication type field plus 64 bits of data for whatever auth scheme that type field picks 🔐. Types 0, 1, and 2 are already defined in [RFC2328]. This section is where we define Authentication type 3, and it's giving main character energy 💅
When you use this scheme, the 64-bit Authentication field from Appendix D.3 of [RFC2328] (sitting in the OSPF packet header from Appendix A.3.1 of [RFC2328] and [RFC6549]) gets a glow-up 🦋 The sequence number is removed, the Key ID gets extended to 32 bits, and it moves into the old sequence number spot. Iconic restructuring, no notes 🫶
The 64-bit sequence number doesn't disappear though. It moves to the first 64 bits right after the OSPFv2 packet and gets protected by the authentication digest 🔒 Those extra 8 octets are counted in the IP header length but NOT in the OSPF header packet length. Lowkey tricky, so keep that in mind 🙈
Last change: the 0 field at the start of the OSPFv2 header authentication grows from 16 bits to 24 bits 🌸
Here's the layout (Figure 1, obviously the star of the show ✨):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | Type | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Auth Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| OSPF Protocol Packet |
~ ~
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (Boot Count) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (Strictly Increasing Packet Counter) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Authentication Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 1: Extended Sequence Number Packet Extensions 💜
4. OSPF Packet Key Selection 🗝️
this section is all about how the security solution picks long-lived keys out of key tables 🔑 See [RFC7210]. Here we're choosing the key plus its matching Security Association (SA), the one defined in Section 3.2 of [RFC5709]. Generally, a key used for OSPFv2 packet authentication should satisfy these requirements:
- For packet transmission, the key validity interval (SendLifetimeStart and SendLifetimeEnd) must include the current time ⏰
- For packet reception, the key validity interval (AcceptLifetimeStart and AcceptLifetimeEnd) must include the current time ⏰
- The key must be valid for the desired security algorithm 💅
The rest of this section lists extra key requirements for each different scenario, so stay tuned 🧚
4.1. Key Selection for Unicast OSPF Packet Transmission 📬
picture this: router R1 wants to send a unicast OSPF packet from its interface I1 to interface I2 on a faraway router R2, using security protocol P through interface I at time T 🌸 Start with the case where R1 and R2 are NOT connected by a virtual link. R1 then has to pick a long-lived symmetric key from its key table. The key has to be shared by R1 and R2 to protect the I1-to-I2 conversation, so it should meet these:
- The Peers field contains the area ID or, if there's no key with the area ID, the string "all" 🫧
- The Direction field is either "out" or "both" ➡️
- The Interfaces field matches I1 or "all" 🔌
- If several keys match the Interface field, keys that explicitly match I1 should be preferred over keys matching "all". If there are STILL several matches, the key with the most recent SendLifetimeStart gets picked. This helps make graceful key rollover happen 🔄
- The Key ID field in the OSPFv2 header (see Figure 1) gets set to the selected key's LocalKeyName 🏷️
Now, when R1 and R2 are connected to a virtual link, the Peers field has to identify the virtual endpoint instead of the virtual link itself 🎀 There could be multiple virtual links to the same router, so the transit area ID has to be part of the identifier. So the key should satisfy these:
- The Peers field includes both the virtual endpoint's OSPF router ID and the transit area ID for the virtual link, written as the transit area ID, then a colon, then the router ID. If no such key exists, a key with the Peers field set to the transit area ID gets used, followed by a key with the Peers field set to "all" 🧩
- The Interfaces field is not used for key selection on virtual links 🙅♀️
- The Direction field is either "out" or "both" ➡️
- If several keys match the Peers field, keys that explicitly match the router ID should be preferred, then keys with a transit area specified, then keys with the Peers field set to "all". If there are STILL several matches, the key with the most recent SendLifetimeStart gets selected 🔄
- The Key ID field in the OSPFv2 header (see Figure 1) gets set to the selected key's LocalKeyName 🏷️
4.2. Key Selection for Multicast OSPF Packet Transmission 📣
If router R1 sends an OSPF packet from its interface I1 to a multicast address (AllSPFRouters or AllDRouters), it has to select a key using these requirements:
- First, try a key with the Peers field containing the area ID the interface belongs to. If no key exists, try a key with the Peers field "all" 🌈
- The Interfaces field matches the interface the packet goes out on, or "all" 🔌
- The Direction field is either "out" or "both" ➡️
- If several keys match the Interface field, keys that explicitly match I1 should be preferred over keys matching "all". If there are STILL several matches, the key with the most resent SendLifetimeStart gets selected. This helps make graceful key rollover happen 🔄
- The Key ID field in the OSPFv2 header (see Figure 1) gets set to the selected key's LocalKeyName 🏷️
4.3. Key Selection for OSPF Packet Reception 📥
When cryptographic authentication is in use, the ID of the authentication key is included in the authentication field of the OSPF packet header 🪪 With that Key ID, a receiver can easily find the matching key. The simple requirements are:
- The interface the key was received on is associated with the key's interface 🔌
- The Key ID obtained from the OSPFv2 packet header corresponds to the neighbor's PeerKeyName. Since OSPFv2 keys are symmetric, the LocalKeyName and PeerKeyName for OSPFv2 keys will be identical. So the Key ID is used to select the correct local key 🔑
- The Direction field is either "in" or "both" ⬅️
- The Peers field matches as described in Sections Section 4.1 and Section 4.2 🧠
5. Securing the IP Header 🛡️
this document updates the definition of the Apad constant (from [RFC5709]) so it also includes the IP source address from the IP header of the OSPFv2 protocol packet 💖 The overall cryptographic authentication process from [RFC5709] stays the same. To keep things from getting confusing, this section doesn't repeat much of RFC 5709 [RFC5709]. The changes are:
RFC 5709, Section 3.3 explains how the cryptographic authentication must be computed. In RFC 5709, the First-Hash covers the OSPF packet and Authentication Trailer. With this spec, the 64-bit sequence number gets included in the First-Hash too, along with the Authentication Trailer and OSPF packet 🧁
RFC 5709, Section 3.3 also requires the OSPFv2 packet's Authentication Trailer (the appendage described in RFC 2328, Appendix D.4.3, page 233, items (6)(a) and (6)(d)) to be filled with the value Apad. Apad is a hexadecimal constant with the value 0x878FE1F3 repeated (L/4) times, where L is the length of the hash being used, measured in octets rather than bits 🔢
OSPF routers sending OSPF packets must initialize the first 4 octets of Apad to the value of the IP source address that would be used when sending the OSPFv2 packet. The rest of Apad contains the value 0x878FE1F3 repeated (L - 4)/4 times, where L is the length of the hash, measured in octets. The basic idea is to bake the IP source address from the IP header into the cryptographic authentication computation, so any change of IP source address in a replayed packet can be detected 🕵️♀️✨
When an OSPF packet is received, implementations MUST initialize the first 4 octets of Apad to the IP source address from the IP header of the incoming OSPFv2 packet. The rest of Apad contains the value 0x878FE1F3 repeated (L - 4)/4 times, where L is the length of the hash, measured in octets. Besides changing the value of Apad, this document doesn't make any other changes to the authentication mechanism described in [RFC5709]. This blocks all attacks where a rogue OSPF router changes the IP source address of an OSPFv2 packet and replays it on the same multi-access interface or on another interface. Since the IP source address is now part of the cryptographic hash computation, any modification causes the OSPFv2 packet to be dropped due to an authentication failure 🚫🔐 absolutely iconic, bestie 🌈
6. Mitigating Cross-Protocol Attacks ✨
okay so bestie, to stop cross-protocol replay attacks between protocols that share the same keys, the two-octet OSPFv2 Cryptographic Protocol ID gets tacked onto the authentication key before it's used 🔐💖 the ID value is in the IANA Considerations (Section 9), so go peek there 👀
[RFC5709], Section 3.3 explains how to prep the key that goes into the hash computation. This document updates the "(1) PREPARATION OF KEY" text there, and the new version reads like this 🎀
The OSPFv2 Cryptographic Protocol ID is appended to the
Authentication Key (K) yielding a Protocol-Specific Authentication
Key (Ks). In this application, Ko is always L octets long. While
[RFC2104] supports a key that is up to B octets long, this
application uses L as the Ks length consistent with [RFC4822],
[RFC5310], and [RFC5709]. According to [FIPS-198], Section 3,
keys greater than L octets do not significantly increase the
function strength. Ks is computed as follows:
If the Protocol-Specific Authentication Key (Ks) is L octets long,
then Ko is equal to Ks. 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 the
Protocol-Specific Authentication Key (Ks) such that Ko is L octets
long.Once Ko (the key the hash algorithm uses) is derived, the rest of the [RFC5709] authentication mechanism stays the same, with one tiny detail that was never spelled out before 🌸 When you XOR Ko with Ipad or Opad, Ko MUST be padded with zeros to the length of Ipad or Opad. implementations of [RFC5709] are expected to do this padding implicitly 🫶
7. Backward Compatibility 🦋
this security extension uses a brand-new authentication type, the AuType field in the OSPFv2 header (see Figure 1) ✨ if an OSPFv2 packet comes in and its AuType doesn't match the authentication type configured on the interface, the packet gets dropped, just like RFC 2328 [RFC2328] says 🙅♀️ this keeps things backward compatible, behaving the same way as any other authentication type mismatch 💅
8. Security Considerations 💀
okay this section is serious, so buckle up 🙈
This document fixes the manual key management procedure that already exists in OSPFv2, as part of Phase 1 of the KARP Working Group. So only the OSPFv2 manual key management mechanism is covered here. Any solution that uses the automatic key management mechanism is out of scope for this document 🔑
The sequence number extension we described gets you most of the perks of fancier mechanisms without their headaches 😤 There are, however, a couple of drawbacks. First, the implementation has to be able to save its boot count in non-volatile storage. If that storage ever gets repaired or upgraded in a way that loses its contents, or the OSPFv2 router gets replaced, the authentication keys MUST be changed to prevent replay attacks 🚨
Second, if a router is taken out of service completely (on purpose or because of a persistent failure), someone could potentially re-establish an OSPFv2 adjacency by replaying the entire OSPFv2 session establishment 😱 This is extremely unlikely, though, since it would require an identical OSPFv2 adjacency formation packet exchange. Without adjacency formation, replaying the OSPFv2 hello packets alone for a router that's been taken out of service should not result in any serious attack, because the only consequence is superfluous processing 🙄 Of course, changing the relevant manual keys would also stop this attack 🔐
This document also offers a fix for certain denial-of-service attacks that can be launched by changing the source address in the IP header of an OSPFv2 protocol packet 🛡️
Using a single crypto sequence number can leave a router open to a replay attack where it uses the same source IP address on two different point-to-point unnumbered links. In environments where an attacker can actively tap the point-to-point links, it's recommended that the user employ different keys on each of those unnumbered IP interfaces. ⚠️
Bestie, the point-to-point unnumbered link thing is the big one here. Using different keys on each unnumbered IP interface is how you stop this replay trick cold 🧊
9. IANA Considerations 📋
This document registers a new code point from the "OSPF Shortest Path First (OSPF) Authentication Codes" registry:
- 3 - Cryptographic Authentication with Extended Sequence Numbers.
This document also registers a new code point from the "Authentication Cryptographic Protocol ID" registry defined under "Keying and Authentication for Routing Protocols (KARP) Parameters":
- 3 - OSPFv2.
10. References 📚
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998,
<http://www.rfc-editor.org/info/rfc2328>.
[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,
<http://www.rfc-editor.org/info/rfc5709>.10.2. Informative References
[FIPS-198]
US National Institute of Standards and Technology, "The
Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB
198-1, July 2008.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997, <http://www.rfc-editor.org/info/rfc2104>.
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", STD 62, RFC 3414, December 2002,
<http://www.rfc-editor.org/info/rfc3414>.
[RFC4222] Choudhury, G., Ed., "Prioritized Treatment of Specific
OSPF Version 2 Packets and Congestion Avoidance", BCP 112,
RFC 4222, October 2005,
<http://www.rfc-editor.org/info/rfc4222>.
[RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic
Authentication", RFC 4822, February 2007,
<http://www.rfc-editor.org/info/rfc4822>.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic
Authentication", RFC 5310, February 2009,
<http://www.rfc-editor.org/info/rfc5310>.
[RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues
with Existing Cryptographic Protection Methods for Routing
Protocols", RFC 6039, October 2010,
<http://www.rfc-editor.org/info/rfc6039>.
[RFC6094] Bhatia, M. and V. Manral, "Summary of Cryptographic
Authentication Algorithm Implementation Requirements for
Routing Protocols", RFC 6094, February 2011,
<http://www.rfc-editor.org/info/rfc6094>.
[RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi-
Instance Extensions", RFC 6549, March 2012,
<http://www.rfc-editor.org/info/rfc6549>.
[RFC6862] Lebovitz, G., Bhatia, M., and B. Weis, "Keying and
Authentication for Routing Protocols (KARP) Overview,
Threats, and Requirements", RFC 6862, March 2013,
<http://www.rfc-editor.org/info/rfc6862>.
[RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security
According to the Keying and Authentication for Routing
Protocols (KARP) Design Guide", RFC 6863, March 2013,
<http://www.rfc-editor.org/info/rfc6863>.
[RFC7210] Housley, R., Polk, T., Hartman, S., and D. Zhang,
"Database of Long-Lived Symmetric Cryptographic Keys", RFC
7210, April 2014,
<http://www.rfc-editor.org/info/rfc7210>.Acknowledgments 💜
Thanks to Ran Atkinson for help in the analysis of errata for RFC 6506, which led to clarifications in this document. 🙌
Thanks to Gabi Nakibly for pointing out a possible attack on P2P links. 🫶
Thanks to Suresh Krishnan for comments made during the Gen-Art review. In particular, thanks for pointing out an ambiguity in the initialization of Apad. 🧠
Thanks to Shaun Cooley for the security directorate review. 🌟
Thanks to Adrian Farrel for comments during the IESG last call. 🎀
Authors' Addresses 🦋
Manav Bhatia
Ionos Networks
Bangalore
India
EMail: manav@ionosnetworks.com
Sam Hartman
Painless Security
EMail: hartmans-ietf@mit.edu
Dacheng Zhang
Huawei Technologies Co., Ltd.
Beijing
China
EMail: dacheng.zhang@gmail.com
Acee Lindem (editor)
Cisco
United States
EMail: acee@cisco.comThat's the whole RFC, bestie! 🌈✨ OSPFv2 is officially secured with extended sequence numbers and we are SO done 💅👑
📦 where this page comes from
- ietf: rfc7474 2015-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms