RFC 6863

Analysis of OSPF Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guide

📅 published March 2013, from ietf

Analysis of OSPF Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guide 🎀

okay bestie, here's the vibe check on this RFC 💅 It's an Informational doc, not a standards-track spec, so it's a deep-dive analysis and not a rulebook. The authors are S. Hartman from Painless Security and D. Zhang from Huawei Technologies Co., Ltd. It came out in March 2013, and its ISSN is 2070-1721 ✨. Its title block doesn't list anything it obsoletes or updates, so it's standing on its own 🦋.

Abstract

This doc analyzes OSPFv2 and OSPFv3 using the guidelines in Section 4.2 of the "Keying and Authentication for Routing Protocols (KARP) Design Guidelines" (RFC 6518) 🧚. The key pieces for fixing the gaps it finds are already in progress, so help is on the way 💖.

Status of This Memo

This document is not an Internet Standards Track specification. It's published for informational purposes 🌸.

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 for the details 🤓.

For the current status, any errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc6863 🔍.

Copyright (c) 2013 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 of publication. Please read these carefully because they spell out your rights and restrictions for this doc 📜. 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 . . . . . . . . . . . . . . . . . . . . . . . . .  2
  1.1.  Requirements to Meet . . . . . . . . . . . . . . . . . . .  3
  1.2.  Requirements Notation  . . . . . . . . . . . . . . . . . .  3
2.  Current State  . . . . . . . . . . . . . . . . . . . . . . . .  3
  2.1.  OSPFv2 . . . . . . . . . . . . . . . . . . . . . . . . . .  4
  2.2.  OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . .  5
3.  Impacts of OSPF Replays  . . . . . . . . . . . . . . . . . . .  6
4.  Gap Analysis and Specific Requirements . . . . . . . . . . . .  7
5.  Solution Work  . . . . . . . . . . . . . . . . . . . . . . . .  8
6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
  8.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
  8.2.  Informative References . . . . . . . . . . . . . . . . . . 10

1. Introduction ✨

okay so this doc analyzes where OSPFv2 and OSPFv3 are right now, based on the requirements in [RFC6518] 🎯. It builds on earlier security work. The OPSEC working group looked at cryptographic issues with routing protocols in [RFC6039] 🔐. Before that, the RPSEC working group wrote a detailed analysis of OSPF vulnerabilities in [OSPF-SEC] 🕵️‍♀️. Work on fixing the gaps from this analysis is in progress, in [OSPF-MANKEY] and [RFC6506] 🛠️.

Honestly, OSPF is giving a lot of what you'd want from a manually keyed routing protocol 💜. Integrity protection uses modern cryptographic algorithms. Algorithm agility is there too: the algorithm can change as part of rekeying an interface or peer 🦋. Intra-connection rekeying is covered by the specifications, although apparently some implementations struggle with it in practice 😭. And OSPFv2 security doesn't get in the way of packet prioritization 🚀.

BUT some gaps are still open between where things are and the requirements for manually keyed routing security in [RFC6862] 🙈. This doc digs into those gaps and suggests directions for closing them 🌸.

1.1. Requirements to Meet

There are a bunch of requirements from Section 3 of [RFC6862] that OSPF doesn't currently meet 🥲. Here are the gaps:

  • Secure Simple Pre-Shared Keys (PSKs): Right now OSPF uses the key directly, as specified. Related key attacks, like the ones in Section 4.1 of [OPS-MODEL], are possible 💀.
  • Replay Protection: The requirements doc covers both inter-connection replay protection and intra-connection replay protection. OSPFv3 has no replay protection at all 😱. OSPFv2 has most of the mechanisms it needs for intra-connection replay protection, but it doesn't securely identify the neighbor that the replay protection state belongs to in every case 🫠. That weakness can be used to cause serious denial-of-service issues with intra-connection replays. OSPFv2 also has no inter-connection replay protection, which creates big denial-of-service openings 🚨.
  • Packet Prioritization: OSPFv3 uses IPsec [RFC4301] to process packets. That makes things harder for implementations that want to process some packets, like Hellos and Acknowledgements, ahead of others 🐢. And if IPsec replay mechanisms were used, packets would need to be processed by IPsec at least, even when they're low priority 😤.
  • Neighbor Identification: Sometimes OSPF identifies a neighbor by IP address. That's never protected in OSPFv2 and usually isn't protected in OSPFv3 🫣.

The rest of this doc explains how OSPF misses these requirements and proposes mechanisms to fix them 🎀.

1.2. Requirements Notation

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 [RFC2119] 📖.

2. Current State 💅

This section covers the security mechanisms built into OSPFv2 and OSPFv3 🔐. It has two goals. First, it explains the OSPF security mechanisms for people who know connectionless integrity mechanisms but aren't familiar with OSPF 🧠.

Second, it gives the background you need to understand how OSPF misses some of the requirements proposed for routing security 🫶.

2.1. OSPFv2

Appendix D of [RFC2328] describes the basic procedure for cryptographic authentication in OSPFv2 📜. An authentication data field in the OSPF packet header holds a key ID, the length of the authentication data, and a sequence number 🔑. A Message Authentication Code (MAC) gets appended to the OSPF packet. This code protects all fields of the packet, including the sequence number, but not the IP header 🛡️.

RFC 2328 defines the use of a keyed-MD5 MAC. MD5 hasn't been broken as a MAC, but it's not the algorithm of choice for new MACs 🙃.

However, RFC 5709 [RFC5709] adds support for the SHA family of hashes [FIPS180] to OSPFv2 🎉. The cryptographic authentication in RFC 5709 meets modern standards for per-packet integrity protection, so OSPFv2 meets the requirement for strong algorithms 💪. Since several algorithms are defined and a new one can be picked with each key, OSPFv2 also meets the requirement for algorithm agility ✨. To provide cryptographic algorithms that are expected to stay useful for a long time, RFC 5709 mandates support for SHA-2 instead of SHA-1 👑.

These security services give integrity protection on each packet. There's also limited replay detection. The sequence number is non-decreasing, so once a router has increased its sequence number, an attacker can't replay an old packet 🔒. But sequence numbers aren't required to increase for each packet 😬. Because existing OSPF security solutions don't say how to set the sequence number, some implementations might use something like "seconds since reboot" as their sequence numbers. The sequence numbers then only increase every second, which leaves room for intra-connection replay 🕰️. Also, no mechanism deals with losing anti-replay state. If sequence numbers get reused when a router reboots, inter-connection replays are straight forward 🙈.

In [OSPF-MANKEY], the OSPFv2 sequence number is 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 🌟. The boot count is kept in non-volatile storage for the deployment life of an OSPF router. So the sequence number never decreases, even after a cold reboot 🥳.

Also, since the IP header isn't protected, the sequence number might not be tied to the correct neighbor. That opens the door for outsiders to run replay attacks 👀. See Section 3 for an analysis of these attacks. In [OSPF-MANKEY], this is fixed by changing the definition of Apad from a constant defined in [RFC5709] to the source address in the IP header of the OSPFv2 protocol packet. That way, the source address from the IP header gets included in the cryptographic authentication computation, and any change to the IP source address gets detected 🕵️‍♀️✨.

The mechanism does a good job with key rollover. There's a key ID. Mechanisms are also described for managing key lifetimes and starting to use a new key in an orderly way 🗓️. Orderly key rollover requires that implementations accept a new key for received packets before they use that key to generate packets 🔄. Section D.3 of RFC 2328 requires this in the form of four configurable lifetimes for each key 💖. Two lifetimes control the beginning and ending periods for acceptance, and two other lifetimes control the beginning and ending periods for generation 🧁. These lifetimes give a superset of the functionality in the key table [CRYPTO-KEYS] for lifetime 🌈.

The OSPFv2 replay mechanism doesn't handle prioritized transmission of OSPF Hello and Link State Acknowledgement (LSA) packets, which is recommended in [RFC4222] 🙁. When OSPF packets go out with different priorities, they can arrive out of order, and that means lower-priority packets get thrown away 🗑️💀.

2.2. OSPFv3 ✨

Okay so "Authentication/Confidentiality for OSPFv3" [RFC4552] explains how the IPsec authentication header and encapsulating security payload mechanism can protect OSPFv3 packets 🔐. It gives per-packet integrity and optional confidentiality using a wide variety of cryptographic algorithms 🧁. Because OSPF uses multicast traffic, only manual key management is supported 🙃. This mechanism meets the requirements related to algorithm selection and agility 💖.

The Security Parameter Index (SPI) [RFC4301] gives you an identifier for the security association 🪪. That identifier, along with other IPsec facilities, is how you move from one key to another, which covers the key rollover requirements 🔑🦋.

Because manual keying is used, no replay protection is provided for OSPFv3 😭. So the intra-connection and inter-connection replay requirements are not met 💀.

There's another serious problem too: rather than being integrated into OSPF, OSPFv3 security is based on IPsec. In practice, this has led to deployment problems 🫠.

OSPF implementations generally prioritize packets so that disruption is minimized when router resources like CPU or memory are under contention 🏃‍♀️. When IPsec is used with OSPFv3, the offset of the packet type (the thing used to prioritize) depends on which integrity transform is used 🌀. So prioritizing packets may be more complex for OSPFv3 🥴. One approach is to set up per-SPI filters to find the packet type and then act accordingly 🧚.

3. Impacts of OSPF Replays 🔁

As we covered, neither version of OSPF meets the requirements of inter-connection or intra-connection replay protection 🚫. To pull off a replay, an attacker needs some way to inject a packet 💉. Physical security can limit a particular deployment's vulnerability to replay attacks 🔒. This section is all about the impacts of OSPF replays 👀.

In OSPFv2, two facilities limit the scope of replay attacks 🛡️. First, when cryptographic authentication is used, each packet includes a sequence number that is non-decreasing 🔢. In the current specifications, that sequence number is remembered as part of an adjacency. So if an attacker can cause an adjacency to go down, the replay state is lost 😬. Database Description packets also include a per-LSA sequence number, which is part of the information that gets flooded 🌊. Even if a packet is replayed, the per-LSA sequence number prevents an old LSA from being installed 🙅‍♀️. Unlike the per-packet sequence number, the per-LSA sequence number must increase when an LSA is changed 📈. As a result, replays cannot be used to install old routing information 🎉.

While the LSA sequence number provides some defense, the Routing Protocol Security Requirements (RPSEC) analysis [OSPF-SEC] describes a number of attacks that are possible because of per-packet replays 📋. The most serious appear to be attacks against Hello packets, which may cause an adjacency to fail 💔. Other attacks may cause excessive flooding or excessive use of CPU 🔥.

Another serious attack concerns Database Description packets 😱. In addition to the per-packet sequence number (which is part of cryptographic authentication for OSPFv2) and the per-LSA sequence numbers, Database Description packets also include a Database Description sequence number 🧾. If a Database Description packet with the incorrect sequence number is received, the database exchange process will be restarted 🔄.

The per-packet OSPFv2 sequence number can be used to reduce the window in which a replay is valid ⏳. A receiver will harmlessly reject a packet whose per-packet sequence number is older than the one most recently received from a neighbor 🙆‍♀️. Replaying the most recent packet from a neighbor does not appear to create problems 🤷‍♀️. So if the per-packet sequence number is incremented on every packet sent, replay attacks should not disrupt OSPFv2 ✨. Unfortunately, OSPFv2 does not have a procedure for dealing with sequence numbers that reach the maximum value 😩. It may be possible to figure out a set of rules that is sufficient to limit the damage from packet replays while minimizing use of the sequence number space 🧠.

As mentioned previously, when an adjacency is dropped, replay state is lost 🫥. So after rebooting, or when all adjacencies are lost, a router may allow its sequence number to decrease 📉. An attacker can cause significant damage by replaying a packet captured before the sequence number decrease, at a time after the decrease 😈. If this happens, the replayed packet will be accepted and the sequence number will be updated 🫣. However, the legitimate sender will now be using a lower sequence number, so legitimate packets will be rejected 🚨. A similar attack is possible when OSPF identifies a neighbor based on source address 🎭. An attacker can change the source address of a captured packet and replay it. If the attacker makes a replay from a neighbor with a high sequence number appear to come from a neighbor with a low sequence number, connectivity with that neighbor will be disrupted until the adjacency fails 📴.

OSPFv3 lacks the per-packet sequence number but has the per-LSA sequence number 🤔. As such, OSPFv3 has no defense against denial-of-service attacks that exploit replay 🥀.

4. Gap Analysis and Specific Requirements 🔍

The design guide requires each design team to enumerate a set of requirements for the routing protocol 📝. The only concerns identified with OSPF are the areas where it fails to meet the general requirements outlined in the threats and requirements document 🧐. This section explains how some of those general requirements map specifically onto the OSPF protocol, and lists the specific gaps that need to be addressed 🗺️.

There is a general requirement for inter-connection replay protection. In the context of OSPF, this means that if an adjacency goes down between two neighbors and is later re-established, replaying packets from before the adjacency went down cannot disrupt the adjacency 🙅‍♀️. In the context of OSPF, intra-connection replay protection means that replaying a packet cannot prevent an adjacency from forming, and cannot disrupt an existing adjacency 🛑. When it comes to meeting the requirements for intra-connection and inter-connection replay protection, there's a significant gap between the optimal state and where OSPF is today 📏.

Since OSPF uses fields in the IP header, the general requirement to protect the IP header and handle neighbor identification applies too 🪪. This is another gap that needs to be addressed 🕳️. Because replay protection depends on neighbor identification, replay protection cannot be adequately addressed without handling this issue as well 🔗.

In order to encourage deployment of OSPFv3 security, an authentication option is required that does not have the deployment challenges of IPsec 🚀.

To support the requirement for simple pre-shared keys, OSPF needs to make sure that when the same key is used for two different purposes, no problems result 🔐.

To support packet prioritization, it is desirable for the information needed to prioritize OSPF packets (the packet type) to be at a constant location in the packet 📍.

5. Solution Work 🛠️

It is recommended that the OSPF Working Group develop a solution for OSPFv2 and OSPFv3 based on the OSPFv2 cryptographic authentication option 👷‍♀️. This solution would have the following improvements over the existing OSPFv2 option:

  • Address most inter-connection replay attacks by splitting the sequence number and requiring preservation of state, so that the sequence number increases on every packet 🔢.
  • Add a form of simple key derivation so that if the same pre-shared key is used for OSPF and other purposes, cross-protocol attacks do not result 🔑.
  • Support OSPFv3 authentication without use of IPsec 🙌.
  • Specify processing rules sufficient to permit replay detection and packet prioritization 📜.
  • Emphasize requirements already present in the OSPF specification that are sufficient to permit key migration without disrupting adjacencies 🦋.
  • Specify the proper use of the key table for OSPF 🗂️.
  • Protect the source IP address 🛡️.
  • Require that sequence numbers be incremented on each packet ⏫.

The key components of this solution work are already underway 🏗️. OSPFv3 now supports an authentication option [RFC6506] that meets the requirements of this section. However, this document does not describe how the key tables are used for OSPF 🤏. OSPFv2 is being enhanced [OSPF-MANKEY] to protect the source address, provide inter-connection replay, and describe how to use the key table 💪.

6. Security Considerations 🚨

This memo discusses and compiles vulnerabilities in the existing OSPF cryptographic handling. Take this one seriously, bestie 😤.

In analyzing proposed improvements to OSPF per-packet security, it is desirable to consider how those improvements interact with potential improvements in overall routing security 🧩. For example, the impact of replay attacks currently depends on the LSA sequence number mechanism 🔗. If cryptographic protections against insider attackers are considered by future work, that work will need to provide a solution that meets the needs of the per-packet replay defense, as well as protecting routing data from insider attack 👹. An experimental solution is discussed in [RFC2154], which explores end-to-end protection of routing data in OSPF 🧪. It may be beneficial to consider how improvements to the per-packet protections would interact with such a mechanism, to future-proof these mechanisms 🔮.

Implementations have a number of options for minimizing the potential denial-of-service impact of OSPF cryptographic authentication 🧱. The Generalized TTL Security Mechanism (GTSM) [RFC5082] might be appropriate for OSPF packets, except for those traversing virtual links 🌐. Using this mechanism requires support from the sender. New OSPF cryptographic authentication could specify this behavior if desired 📨. Alternatively, implementations can limit the source addresses from which they accept packets 🚧. Non-Hello packets need only be accepted from existing neighbors 🙋‍♀️. If a system is under attack, Hello packets from existing neighbors could be prioritized over Hello packets from new neighbors 🏅. These mechanisms can be considered to limit the potential impact of denial-of-service attacks on the cryptographic authentication mechanism itself 🛡️💜.

7. Acknowledgements 🫶

Funding for Sam Hartman's work on this memo was provided by Huawei 💰.

The authors would like to thank Ran Atkinson, Michael Barnes, and Manav Bhatia for their valuable comments 🌸.

8. 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.

[RFC4552]      Gupta, M. and N. Melam, "Authentication/
               Confidentiality for OSPFv3", RFC 4552, June 2006.

[RFC6518]      Lebovitz, G. and M. Bhatia, "Keying and Authentication
               for Routing Protocols (KARP) Design Guidelines",
               RFC 6518, February 2012.

[RFC6862]      Lebovitz, G., Bhatia, M., and B. Weis, "Keying and
               Authentication for Routing Protocols (KARP) Overview,
               Threats, and Requirements", RFC 6862, March 2013.

8.2. Informative References ✨

okay bestie, these are the bonus reads 📚 the spec leans on for background. they aren't strictly required, but they're lowkey essential if you want the whole story 🧚

  • [CRYPTO-KEYS] Housley, R., Polk, T., Hartman, S., and D. Zhang, "Database of Long-Lived Symmetric Cryptographic Keys", Work in Progress, October 2012.
  • [FIPS180] US National Institute of Standards and Technology, "Secure Hash Standard (SHS)", August 2002.
  • [OPS-MODEL] Hartman, S. and D. Zhang, "Operations Model for Router Keying", Work in Progress, October 2012.
  • [OSPF-MANKEY] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, "Security Extension for OSPFv2 when using Manual Key Management", Work in Progress, October 2012.
  • [OSPF-SEC] Jones, E. and O. Moigne, "OSPF Security Vulnerabilities Analysis", Work in Progress, June 2006.
  • [RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital Signatures", RFC 2154, June 1997.
  • [RFC4222] Choudhury, G., "Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance", BCP 112, RFC 4222, October 2005.
  • [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
  • [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007.
  • [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.
  • [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.

Authors' Addresses 🎀

meet the authors, the people who actually wrote this 💅

Sam Hartman
Painless Security

EMail: hartmans-ietf@mit.edu
URI:   http://www.painless-security.com/


Dacheng Zhang
Huawei Technologies Co., Ltd.
Huawei Building No. 3 Xinxi Rd.
Shang-Di Information Industrial Base Hai-Dian District, Beijing
China

EMail: zhangdacheng@huawei.com
📦 where this page comes from