RFC 4552
Authentication/Confidentiality for OSPFv3
RFC 4552: Authentication/Confidentiality for OSPFv3 ✨
Okay bestie, this one is a Standards Track doc from the Network Working Group, dated June 2006 🎀. The authors are M. Gupta from Tropos Networks and N. Melam from Juniper Networks 🧚. It doesn't obsolete or update anything.
Status of This Memo 📜
This doc specifies an Internet standards track protocol for the whole Internet community, and it's literally asking for discussion and suggestions for improvements 💬. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈.
Copyright Notice ⚖️
Copyright (C) The Internet Society (2006).
Abstract 🔐
So basically this doc explains how to give OSPFv3 authentication and confidentiality using an IPv6 Authentication Header/Encapsulating Security Payload (AH/ESP) extension header. It's giving security glow-up 💖.
Table of Contents 🗂️
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................2
2. Transport Mode vs. Tunnel Mode ..................................3
3. Authentication ..................................................3
4. Confidentiality .................................................3
5. Distinguishing OSPFv3 from OSPFv2 ...............................4
6. IPsec Requirements ..............................................4
7. Key Management ..................................................5
8. SA Granularity and Selectors ....................................7
9. Virtual Links ...................................................8
10. Rekeying .......................................................9
10.1. Rekeying Procedure ........................................9
10.2. KeyRolloverInterval .......................................9
10.3. Rekeying Interval ........................................10
11. IPsec Protection Barrier and SPD ..............................10
12. Entropy of Manual Keys ........................................12
13. Replay Protection .............................................12
14. Security Considerations .......................................12
15. References ....................................................13
15.1. Normative References .....................................13
15.2. Informative References ...................................131. Introduction ✨
OSPF Version 2 [N1] is the one with the AuType and Authentication fields in its protocol header for security. Then OSPF for IPv6 (OSPFv3) [N2] yeeted both of those authentication fields right out of the OSPF headers 💀. So instead, OSPFv3 leans on the IPv6 Authentication Header (AH) and IPv6 Encapsulating Security Payload (ESP) to get integrity, authentication, and/or confidentiality 👑.
This doc describes how IPv6 AH/ESP extension headers can be used to give OSPFv3 authentication/confidentiality. It's the main character of this whole RFC 🦋.
It's assumed you already know OSPFv3 [N2], AH [N5], ESP [N4], the concept of security associations, tunnel and transport mode of IPsec, and the key management options for AH and ESP (manual keying [N3] and Internet Key Exchange (IKE)[I1]). If not, go catch up first 🙈.
1.1. Conventions Used in This Document
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 [N7]. Those words are the rules, so read them carefully 🫶.
2. Transport Mode vs. Tunnel Mode 🌸
The transport mode Security Association (SA) is generally used between two hosts, or between routers/gateways when they're acting as hosts. The SA must be a tunnel mode SA if either end of the security association is a router/gateway. Two hosts MAY establish a tunnel mode SA between themselves 💅.
OSPFv3 packets are exchanged between routers. However, since the packets are locally delivered, the routers take on the role of hosts in the context of tunnel mode SA. It's giving role-play 🎭.
All implementations conforming to this specification MUST support transport mode SA to provide required IPsec security to OSPFv3 packets. They MAY also support tunnel mode SA to provide required IPsec security to OSPFv3 packets 🔥.
3. Authentication 🔑
Implementations conforming to this specification MUST support authentication for OSPFv3. Non-negotiable, bestie 💖.
To provide authentication to OSPFv3, implementations MUST support ESP and MAY support AH 🧚.
If ESP in transport mode is used, it will only provide authentication to OSPFv3 protocol packets. It skips the IPv6 header, extension headers, and options 🙈.
If AH in transport mode is used, it will provide authentication to OSPFv3 protocol packets, selected portions of the IPv6 header, selected portions of extension headers, and selected options 🌈.
When OSPFv3 authentication is enabled:
- OSPFv3 packets that are not protected with AH or ESP MUST be silently discarded.
- OSPFv3 packets that fail the authentication checks MUST be silently discarded.
4. Confidentiality 🤫
Implementations conforming to this specification SHOULD support confidentiality for OSPFv3. It's a strong recommendation, not a maybe 💜.
If confidentiality is provided, ESP MUST be used 🎀.
When OSPFv3 confidentiality is enabled:
- OSPFv3 packets that are not protected with ESP MUST be silently discarded.
- OSPFv3 packets that fail the confidentiality checks MUST be silently discarded.
5. Distinguishing OSPFv3 from OSPFv2 🪞
The IP/IPv6 Protocol Type for OSPFv2 and OSPFv3 is the same (89), so OSPF tells them apart using the OSPF header version number. But current IPsec standards don't let you use arbitrary protocol-specific header fields as selectors 😭. That means the OSPF version field in the OSPF header can't be used to tell OSPFv3 packets from OSPFv2 packets.
The good news is OSPFv2 is only for IPv4 and OSPFv3 is only for IPv6. So the version field in the IP header can be used to distinguish OSPFv3 packets from OSPFv2 packets 🦋✨.
6. IPsec Requirements 📋
To implement this specification, the following IPsec capabilities are required. Here's the checklist, bestie 🍓.
Transport mode
IPsec in transport mode MUST be supported. [N3]
Multiple Security Policy Databases (SPDs)
The implementation MUST support multiple SPDs with an SPD selection function that provides an ability to choose a specific SPD based on interface. [N3]
Selectors
The implementation MUST be able to use source address, destination address, protocol, and direction as selectors in the SPD.
Interface ID tagging
The implementation MUST be able to tag the inbound packets with the ID of the interface (physical or virtual) via which it arrived. [N3]
Manual key support
Manually configured keys MUST be able to secure the specified traffic. [N3]
Encryption and authentication algorithms
The implementation MUST NOT allow the user to choose stream ciphers as the encryption algorithm for securing OSPFv3 packets, since stream ciphers are not suitable for manual keys. Stream ciphers are a no-go here 🙅♀️.
Except when in conflict with the above statement, the key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", and "SHOULD NOT" that appear in the [N6] document for algorithms to be supported are to be interpreted as described in [N7] for OSPFv3 support as well 💅.
Dynamic IPsec rule configuration
The routing module SHOULD be able to configure, modify, and delete IPsec rules on the fly. This is needed mainly for securing virtual links 🌊.
Encapsulation of ESP packet
IP encapsulation of ESP packets MUST be supported. For simplicity, UDP encapsulation of ESP packets SHOULD NOT be used 🫠.
Different SAs for different Differentiated Services Code Points (DSCPs)
As per [N3], the IPsec implementation MUST support the establishment and maintenance of multiple SAs with the same selectors between a given sender and receiver. This lets the implementation associate different classes of traffic with the same selector values, which supports Quality of Service (QoS) ✨👑.
7. Key Management ✨
okay so bestie, OSPFv3 sends both multicast AND unicast packets 🫶 and when you run it over a broadcast interface, the auth/confidentiality you need is "one to many" 💅. Now IKE is built on Diffie-Hellman and only works for TWO parties, so it literally can't do that "one to many" thing 😭. This spec says to use Manual Keying with current IPsec implementations 🔐. Later specs can look at KINK/GSAKMP once they're widely around 🌸. With manual keying, the SAs get statically installed on the routers, and those static SAs are what authenticate and encrypt the packets 🎀.
So the next part is kinda spicy 🙈. Using different SAs for inbound and outbound traffic is not scalable and is practically infeasible for that "one to many" security 💀. So implementations MUST use manually configured keys with the SAME SA parameters (Security Parameter Index (SPI), keys, etc.) for both inbound and outbound SAs (see Figure 3) 👑.
A |
SAa ------------>|
SAb <------------|
|
B |
SAb ------------>|
SAa <------------| Figure 1
|
C |
SAa/SAb ------------>|
SAa/SAb <------------|
|
Broadcast
Networkok so if we look at A and B in Figure 1, everything seems fine 🥰. A uses SAa for outbound and B uses it for inbound, and vice versa 🦋. But if we add C and C sends a packet using SAa, only A can read it 😬. And if C uses SAb, only B can read it 💔. Since the packets are multicast and both A and B have to process them, there is NO SA C can use that both of them understand 🙅♀️.
A |
SAa ------------>|
SAb <------------|
SAc <------------|
|
B |
SAb ------------>|
SAa <------------| Figure 2
SAc <------------|
|
C |
SAc ------------>|
SAa <------------|
SAb <------------|
|
Broadcast
Networkyou can fix this by configuring SAs for every node on every other node, like Figure 2 🧚. So A, B and C use SAa, SAb and SAc for outbound 🌈. Each node looks up the SA based on the source (A uses SAb and SAc for packets from B and C) 🎀. BUT this is also not scalable or practical 😩, since each node needs a ton of SAs configured, and adding one node means adding another SA on every other node 💅.
A |
SAo ------------>|
SAi <------------|
|
B |
SAo ------------>|
SAi <------------| Figure 3
|
C |
SAo ------------>|
SAi <------------|
|
Broadcast
Networkthe fix is to use the SAME SA parameters (SPI, keys, etc.) for both inbound (SAi) and outbound (SAo) SAs, like Figure 3 👑✨.
8. SA Granularity and Selectors 🦋
okay so the user SHOULD get to choose whether they share ONE SA across multiple interfaces or use a unique SA per interface 💖.
OSPFv3 can run multiple instances over one interface using the "Instance Id" field in the OSPFv3 header 🌸. BUT IPsec can't use arbitrary protocol header fields as selectors, so you can't use different SAs for different OSPFv3 instances on the same interface 😭. That means all OSPFv3 instances on the same interface MUST use the same SA 🔐. In OSPFv3 RFC terms, SAs are per-link, not per-interface 🧚.
9. Virtual Links 🌈
A virtual link MUST get a DIFFERENT SA than the underlying interface 💅. Packets sent on virtual links use unicast NON-link-local IPv6 addresses as the source, while packets on other interfaces use multicast and unicast link-local addresses 🫶. That difference in source address is what tells virtual link packets apart from other OSPFv3 interface types ✨.
Here's the tricky part 🙈. The virtual link endpoint IPv6 addresses aren't known ahead of time, so you can't install SPD/Security Association Database (SAD) entries at configuration time 😭. Those addresses are learned during the routing table computation, and the packet exchange over virtual links only starts AFTER the endpoint addresses are discovered 🔍. To protect these exchanges, the routing module MUST install the matching SPD/SAD entries before they start 🎀. The manual SA parameters are preconfigured, but they don't get installed in the SAD until the endpoint addresses are learned 💜.
According to the OSPFv3 RFC [N2], the virtual neighbor's IP address is set to the first prefix with the "LA-bit" set from the prefixes in intra-area-prefix-Link State Advertisements (LSAs) that the virtual neighbor originated 🌸. BUT for the source address on virtual link packets, [N2] just suggests using one of the router's own global IPv6 addresses 🤷♀️. To install the security rules for virtual links, the source address has to be predictable too 🔐. So routers that implement this spec MUST change how source and destination addresses are chosen for virtual link packets when IPsec is enabled 👑.
The FIRST IPv6 address with the "LA-bit" set in the prefixes advertised in intra-area-prefix-LSAs in the transit area MUST be used as the source address for packets on the virtual link 💖. If multiple intra-area-prefix-LSAs are originated, they're treated as concatenated and ordered by ascending Link State ID 🧚.
The FIRST IPv6 address with the "LA-bit" set in the prefixes received in intra-area-prefix-LSAs from the virtual neighbor in the transit area MUST be used as the destination address for packets on the virtual link 🦋. Same deal with multiple LSAs: they're concatenated and ordered by ascending Link State ID 🌈.
Put together, this makes both the source AND destination addresses of virtual link packets predictable when IPsec is enabled 🎀✨.
10. Rekeying 🔑
okay so to keep a link secure, the authentication and encryption key values SHOULD be changed periodically 💅.
10.1. Rekeying Procedure 🌸
The following three-step procedure SHOULD be provided to rekey the routers on a link WITHOUT dropping OSPFv3 protocol packets or disrupting the adjacency 🫶.
(1) For every router on the link, create an additional inbound SA for the interface being rekeyed, using a new SPI and the new key 🌱.
(2) For every router on the link, replace the original outbound SA with one using the new SPI and key values 🔄. The SA replacement operation should be atomic with respect to sending OSPFv3 packets on the link, so that no OSPFv3 packets get sent without authentication/encryption 🔐.
(3) For every router on the link, remove the original inbound SA 🧹.
Note that ALL routers on the link must finish step 1 before ANY of them begin step 2 🚦. Likewise, ALL routers on the link must finish step 2 before ANY of them begin step 3 ⭐.
One way to control the progression from one step to the next is for each router to have a configurable time constant called KeyRolloverInterval ⏰. After a router begins step 1 on a given link, it waits for this interval and then moves to step 2 🦋. Then after moving to step 2, it waits for this interval again and moves to step 3 💜.
To get a smooth key transition, all routers on a link should use the SAME value for KeyRolloverInterval and should start the key rollover process within this time period 🎀.
At the end of this procedure, all the routers on the link will have a single inbound and outbound SA for OSPFv3 with the new SPI and key values 👑✨.
10.2. KeyRolloverInterval 💖
The configured value of KeyRolloverInterval should be long enough to let the administrator change keys on all the OSPFv3 routers 🗓️. Since this value can vary a lot depending on the implementation and deployment, it's left up to the administrator to pick an appropriate value 🧚.
10.3. Rekeying Interval ⏳
This section analyzes the security provided by manual keying and recommends that the encryption and authentication keys SHOULD be changed at least every 90 days 🔐. Bestie, this part is important 😭.
The WEAKEST security from the mechanisms in this spec is when NULL encryption (for ESP) or no encryption (for AH) is used with HMAC-MD5 authentication 💀. Any other algorithm combo will be at least as hard to break as that one 💪. Here's why, with some reasonable assumptions 🧠:
o NULL Encryption and HMAC-SHA-1 Authentication will be more secure, because HMAC-SHA-1 is considered more secure than HMAC-MD5 🔒.
o NON-NULL Encryption and NULL Authentication is not applicable, because this spec mandates authentication when OSPFv3 security is enabled 🚫.
o Data Encryption Security (DES) Encryption and HMAC-MD5 Authentication will be more secure because of the extra security DES provides 🛡️.
o Other encryption algorithms like 3DES and the Advanced Encryption Standard (AES) will be more secure than DES 🌟.
RFC 3562 [I4] analyzes the rekeying requirements for the TCP MD5 signature option 📜. The analysis in RFC 3562 also applies to this spec, because the analysis doesn't depend on data patterns 🫶.
11. IPsec Protection Barrier and SPD 🛡️
okay so the IPsec protection barrier MUST be wrapped around the OSPF protocol 💖 which means ALL inbound and outbound OSPF traffic goes through IPsec processing. no exceptions, bestie 💅
The SPD selection function MUST return an SPD with this rule for every interface where OSPFv3 authentication/confidentiality is disabled:
No. source destination protocol action
1 any any OSPF bypassThe SPD selection function MUST return an SPD with these rules for every interface where OSPFv3 authentication/confidentiality is enabled:
No. source destination protocol action
2 fe80::/10 any OSPF protect
3 fe80::/10 any ESP/OSPF or AH/OSPF protect
4 src/128 dst/128 OSPF protect
5 src/128 dst/128 ESP/OSPF or AH/OSPF protectfor rules 2 and 4, "protect" means encrypting and calculating the Integrity Check Value (ICV) and adding an ESP or AH header 🔐. for rules 3 and 5, "protect" means decrypting/authenticating the packets and stripping the ESP or AH header. two different jobs, same vibe ✨
rule 1 bypasses OSPFv3 packets with zero IPsec processing on the interfaces where OSPFv3 authentication/confidentiality is disabled 🦋
rules 2 and 4 drop inbound OSPFv3 packets that haven't been secured with ESP/AH headers. not me being picky, it's the rule 🙅♀️
"ESP/OSPF or AH/OSPF" in rules 3 and 5 just means it's an OSPF packet that's secured with ESP or AH 🧚
rules 2 and 3 are there to secure the unicast and multicast OSPF packets that are NOT being exchanged over virtual links 🌸
rules 4 and 5 are for the packets exchanged over virtual links 🌈 these rules get installed AFTER you learn the virtual link end point IPv6 addresses. they MUST be installed in the SPD for the interfaces connected to the transit area for the virtual link. they MAY alternatively be installed on ALL the interfaces, and here's why that matters 👀 if they're NOT on all interfaces, clear text or malicious OSPFv3 packets with the same source and destination addresses as the virtual link end point IPv6 addresses will get delivered to OSPFv3. OSPFv3 drops them since they weren't received on the right interface, BUT it still receives some clear text or malicious packets even with security enabled 😭
installing these rules on all the interfaces means OSPFv3 never receives those clear text or malicious packets when security is enabled 🫶 the tradeoff is that it adds processing overhead on interfaces that have no other IPsec processing. so whether you install them everywhere or just on the transit-area interfaces is a private decision, and it doesn't affect interoperability in any way. hence it's an implementation choice 💖
12. Entropy of Manual Keys 🔑
the implementations MUST let the administrator configure the cryptographic and authentication keys in hexadecimal format, instead of limiting them to a subset of ASCII characters (letters, numbers, etc.) 🍓 a restricted character set cuts key entropy way down, as discussed in [I2]. so don't be lazy with your keys, periodt 💅
13. Replay Protection 🔁
ngl this one's a bummer. since the current standards can't provide complete replay protection while you're using manual keying, the proposed solution does NOT protect against replay attacks 🙈
detailed analysis of the vulnerabilities in routing protocols (and OSPF specifically) is in [I3] and [I2]. the conclusion? replaying OSPF packets can disrupt adjacencies, which can lead to a DoS attack on the network 💀 it can also make the database exchange process happen continuously, which causes CPU overload and micro loops in the network. literally chaotic 😭
14. Security Considerations 🛡️✨
this memo talks about using the IPsec AH and ESP headers to secure OSPFv3 for IPv6, so security is basically in every corner of this document 💜
OSPF Security Vulnerabilities Analysis [I2] identifies OSPF vulnerabilities in two scenarios: one with no authentication or simple password authentication, and one with cryptographic authentication. the solution in this specification protects against ALL the vulnerabilities identified for the cryptographic authentication scenario, with the following exceptions:
Limitations of manual key:
This specification mandates the usage of manual keys. these are the known limitations of using manual keys, and they're a lot 😭
- As the sequence numbers cannot be negotiated, replay protection cannot be provided. This leaves OSPF insecure against all the attacks that can be performed by replaying OSPF packets.
- Manual keys are usually long lived (changing them often is a tedious task). This gives an attacker enough time to discover the keys.
- As the administrator is manually configuring the keys, there is a chance that the configured keys are weak (there are known weak keys for DES/3DES at least).
Impersonating attacks:
using the same key on all the OSPF routers connected to a link leaves them ALL insecure against impersonating attacks if any one of those routers is compromised, malfunctioning, or misconfigured. one bad router and the whole link is cooked 🙃
Detailed analysis of various vulnerabilities of routing protocols is discussed in [I3].
15. References 📚
15.1. Normative References
- [N1] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
- [N2] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999.
- [N3] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
- [N4] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
- [N5] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
- [N6] Eastlake 3rd, D., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4305, December 2005.
- [N7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
15.2. Informative References
- [I1] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
- [I2] Jones, E. and O. Moigne, "OSPF Security Vulnerabilities Analysis", Work in Progress.
- [I3] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", Work in Progress.
- [I4] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003.
Acknowledgements 💌
the authors want to send a huge thank-you to Marc Solsona, Janne Peltonen, John Cruz, Dhaval Shah, Abhay Roy, Paul Wells, Vishwas Manral, and Sam Hartman for sharing useful information and critiques on this memo 🫶 special thanks to Acee Lindem for all the editorial changes 🎀
we also want to thank the members of the IPsec and OSPF WG for their valuable review comments 🌷
Authors' Addresses 🏡
Mukesh Gupta
Tropos Networks
555 Del Rey Ave
Sunnyvale, CA 94085
Phone: 408-331-6889
EMail: mukesh.gupta@tropos.com
Nagavenkata Suresh Melam
Juniper Networks
1194 N. Mathilda Ave
Sunnyvale, CA 94089
Phone: 408-505-4392
EMail: nmelam@juniper.netFull Copyright Statement ⚖️
Copyright (C) The Internet Society (2006).
this document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
this document and the information in it are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🧾
the IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or on the extent to which any license under such rights might or might not be available. it also doesn't claim to have made any independent effort to identify any such rights. info on the procedures for rights in RFC documents is in BCP 78 and BCP 79.
copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users of this specification to use such proprietary rights can be found in the IETF online IPR repository at http://www.ietf.org/ipr.
the IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology required to implement this standard. send that info to the IETF at ietf-ipr@ietf.org 📬
Acknowledgement 💕
funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA) 🌈
📦 where this page comes from
- ietf: rfc4552 2006-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms