diff options
Diffstat (limited to 'doc/rfc/rfc6863.txt')
| -rw-r--r-- | doc/rfc/rfc6863.txt | 619 |
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc6863.txt b/doc/rfc/rfc6863.txt new file mode 100644 index 0000000..615358f --- /dev/null +++ b/doc/rfc/rfc6863.txt @@ -0,0 +1,619 @@ + + + + + + +Internet Engineering Task Force (IETF) S. Hartman +Request for Comments: 6863 Painless Security +Category: Informational D. Zhang +ISSN: 2070-1721 Huawei Technologies Co., Ltd. + March 2013 + + + Analysis of OSPF Security According to the + Keying and Authentication for Routing Protocols (KARP) Design Guide + +Abstract + + This document analyzes OSPFv2 and OSPFv3 according to the guidelines + set forth in Section 4.2 of the "Keying and Authentication for + Routing Protocols (KARP) Design Guidelines" (RFC 6518). Key + components of solutions to gaps identified in this document are + already underway. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6863. + +Copyright Notice + + 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) in effect on the date of + publication of this document. Please review these documents + carefully, as 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 are provided without warranty as + described in the Simplified BSD License. + + + +Hartman & Zhang Informational [Page 1] + +RFC 6863 OSPF Analysis March 2013 + + +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 + + This document analyzes the current state of OSPFv2 and OSPFv3 + according to the requirements of [RFC6518]. It builds on several + previous analysis efforts regarding routing security. The OPSEC + working group put together an analysis of cryptographic issues with + routing protocols [RFC6039]. Earlier, the RPSEC working group put + together a detailed analysis of OSPF vulnerabilities [OSPF-SEC]. + Work on solutions to address gaps identified in this analysis is + underway [OSPF-MANKEY] [RFC6506]. + + OSPF meets many of the requirements expected from a manually keyed + routing protocol. Integrity protection is provided with modern + cryptographic algorithms. Algorithm agility is provided: the + algorithm can be changed as part of rekeying an interface or peer. + Intra-connection rekeying is provided by the specifications, although + apparently some implementations have trouble with this in practice. + OSPFv2 security does not interfere with prioritization of packets. + + However, some gaps remain between the current state and the + requirements for manually keyed routing security expressed in + [RFC6862]. This document explores these gaps and proposes directions + for addressing the gaps. + + + + + + + + + + + +Hartman & Zhang Informational [Page 2] + +RFC 6863 OSPF Analysis March 2013 + + +1.1. Requirements to Meet + + There are a number of requirements described in Section 3 of + [RFC6862] that OSPF does not currently meet. The gaps are as + follows: + + o Secure Simple Pre-Shared Keys (PSKs): Today, OSPF directly uses + the key as specified. Related key attacks, such as those + described in Section 4.1 of [OPS-MODEL], are possible. + + o Replay Protection: The requirements document addresses + requirements for both inter-connection replay protection and + intra-connection replay protection. OSPFv3 has no replay + protection at all. OSPFv2 has most of the mechanisms necessary + for intra-connection replay protection. Unfortunately, OSPFv2 + does not securely identify the neighbor with whom replay + protection state is associated in all cases. This weakness can be + used to create significant denial-of-service issues using intra- + connection replays. OSPFv2 has no inter-connection replay + protection; this creates significant denial-of-service + opportunities. + + o Packet Prioritization: OSPFv3 uses IPsec [RFC4301] to process + packets. This complicates implementations that wish to process + some packets, such as Hellos and Acknowledgements, above others. + In addition, if IPsec replay mechanisms were used, packets would + need to be processed at least by IPsec even if they were low + priority. + + o Neighbor Identification: In some cases, OSPF identifies a neighbor + based on the IP address. This operation is never protected with + OSPFv2 and is not typically protected with OSPFv3. + + The remainder of this document explains how OSPF fails to meet these + requirements, and it proposes mechanisms for addressing 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 describes the security mechanisms built into OSPFv2 and + OSPFv3. There are two goals to this section. First, this section + gives a brief explanation of the OSPF security mechanisms to those + familiar with connectionless integrity mechanisms but not with OSPF. + + + +Hartman & Zhang Informational [Page 3] + +RFC 6863 OSPF Analysis March 2013 + + + Second, this section provides the background necessary to understand + how OSPF fails to meet 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 contains a key ID, the length of the + authentication data, and a sequence number. A Message Authentication + Code (MAC) is 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. While MD5 has not been + broken as a MAC, it is 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 described in + RFC 5709 meets modern standards for per-packet integrity protection. + Thus, OSPFv2 meets the requirement for strong algorithms. Since + multiple algorithms are defined and a new algorithm can be selected + with each key, OSPFv2 meets the requirement for algorithm agility. + In order to provide cryptographic algorithms believed to have a + relatively long useful life, RFC 5709 mandates support for SHA-2 + rather than SHA-1. + + These security services provide integrity protection on each packet. + In addition, limited replay detection is provided. The sequence + number is non-decreasing. So, once a router has increased its + sequence number, an attacker cannot replay an old packet. + Unfortunately, sequence numbers are not required to increase for each + packet. For instance, because existing OSPF security solutions do + not specify how to set the sequence number, it is possible that some + implementations use, for example, "seconds since reboot" as their + sequence numbers. The sequence numbers are thus increased only every + second, permitting an opportunity for intra-connection replay. Also, + no mechanism is provided to deal with the loss of anti-replay state; + if sequence numbers are reused when a router reboots, then inter- + connection replays are straight forward. In [OSPF-MANKEY], the + OSPFv2 sequence number is expanded to 64 bits, with the least + significant 32-bit value containing a strictly increasing sequence + number and the most significant 32-bit value containing the boot + count. The boot count is retained in non-volatile storage for the + deployment life of an OSPF router. Therefore, the sequence number + will never decrease, even after a cold reboot. + + + + + +Hartman & Zhang Informational [Page 4] + +RFC 6863 OSPF Analysis March 2013 + + + Also, because the IP header is not protected, the sequence number may + not be associated with the correct neighbor, a situation that opens + up opportunities for outsiders to perform replay attacks. See + Section 3 for analysis of these attacks. In [OSPF-MANKEY], this + issue is addressed 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. In this way, the source address from the IP + header is incorporated in the cryptographic authentication + computation, and any change of the IP source address will be + detected. + + The mechanism provides good support for key rollover. There is a key + ID. In addition, mechanisms are described for managing key lifetimes + and starting the use of a new key in an orderly manner. Performing + orderly key rollover requires that implementations support accepting + a new key for received packets before using that key to generate + packets. Section D.3 of RFC 2328 requires this support in the form + of four configurable lifetimes for each key: two lifetimes control + the beginning and ending period for acceptance, while two other + lifetimes control the beginning and ending period for generation. + These lifetimes provide a superset of the functionality in the key + table [CRYPTO-KEYS] regarding lifetime. + + The OSPFv2 replay mechanism does not handle prioritized transmission + of OSPF Hello and Link State Acknowledgement (LSA) packets as + recommended in [RFC4222]. When OSPF packets are transmitted with + varied prioritization, they can arrive out of order, which results in + packets with lower prioritization being discarded. + +2.2. OSPFv3 + + "Authentication/Confidentiality for OSPFv3" [RFC4552] describes how + the IPsec authentication header and encapsulating security payload + mechanism can be used to protect OSPFv3 packets. This mechanism + provides 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 requirements related to algorithm selection and + agility. + + The Security Parameter Index (SPI) [RFC4301] provides an identifier + for the security association. This identifier, along with other + IPsec facilities, provides a mechanism for moving from one key to + another, meeting the key rollover requirements. + + Because manual keying is used, no replay protection is provided for + OSPFv3. Thus, the intra-connection and inter-connection replay + requirements are not met. + + + +Hartman & Zhang Informational [Page 5] + +RFC 6863 OSPF Analysis March 2013 + + + There is another serious problem with the OSPFv3 security: rather + than being integrated into OSPF, it is based on IPsec. In practice, + this has lead to deployment problems. + + OSPF implementations generally prioritize packets in order to + minimize disruption when router resources such as CPU or memory + experience contention. When IPsec is used with OSPFv3, the offset of + the packet type, which is used to prioritize packets, depends on + which integrity transform is used. For this reason, prioritizing + packets may be more complex for OSPFv3. One approach is to establish + per-SPI filters to find the packet type and then act accordingly. + +3. Impacts of OSPF Replays + + As discussed, neither version of OSPF meets the requirements of + inter-connection or intra-connection replay protection. In order to + mount a replay, an attacker needs some mechanism to inject a packet. + Physical security can limit a particular deployment's vulnerability + to replay attacks. This section discusses 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, the sequence number is remembered as part of an + adjacency: if an attacker can cause an adjacency to go down, then + replay state is lost. Database Description packets also include a + per-LSA sequence number that is part of the information that is + flooded. Even if a packet is replayed, the per-LSA sequence number + will prevent 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 that 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, then the database exchange + process will be restarted. + + + +Hartman & Zhang Informational [Page 6] + +RFC 6863 OSPF Analysis March 2013 + + + 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, then + replay attacks should not disrupt OSPFv2. Unfortunately, OSPFv2 does + not have a procedure for dealing with sequence numbers reaching the + maximum value. It may be possible to figure out a set of rules + sufficient to disrupt the damage of packet replays while minimizing + the 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 sequence number + decrease. If this happens, then the replayed packet will be accepted + and the sequence number will be updated. However, the legitimate + sender will be using a lower sequence number, so legitimate packets + will be rejected. A similar attack is possible in cases where 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 causes a replay from a neighbor with a high sequence number + to appear to be from a neighbor with a low sequence number, then + 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 areas in which it fails to meet the general + requirements outlined in the threats and requirements document. This + section explains how some of these general requirements map + specifically onto the OSPF protocol and enumerates 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 later is 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 + + + +Hartman & Zhang Informational [Page 7] + +RFC 6863 OSPF Analysis March 2013 + + + from forming or cannot disrupt an existing adjacency. In terms of + meeting the requirements for intra-connection and inter-connection + replay protection, a significant gap exists 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. + This is another gap that needs to be addressed. Because the replay + protection will depend on neighbor identification, the 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. + + In order 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. + + In order 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 + sufficient to permit key migration without disrupting adjacencies. + + Specify the proper use of the key table for OSPF. + + + +Hartman & Zhang Informational [Page 8] + +RFC 6863 OSPF Analysis March 2013 + + + 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. + + In analyzing proposed improvements to OSPF per-packet security, it is + desirable to consider how these 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, then that work will need to provide a + solution that meets the needs of the per-packet replay defense as + well as protects routing data from insider attack. An experimental + solution is discussed in [RFC2154] that 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 in 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 of 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. + + + + + + + + + +Hartman & Zhang Informational [Page 9] + +RFC 6863 OSPF Analysis March 2013 + + +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 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 + + [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. + + + + +Hartman & Zhang Informational [Page 10] + +RFC 6863 OSPF Analysis March 2013 + + + [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 + + 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 + + + + + + + + + +Hartman & Zhang Informational [Page 11] + |