Network Working Group S. Hartman Internet-Draft Painless Security Intended status: Informational D. Zhang Expires: December 19, 2010 Huawei June 17, 2010 Analysis of OSPF Security According to KARP Design Guide draft-hartman-ospf-analysis-00.txt Abstract This document analyzes OSPFv2 and OSPFv3 according to the guidelines set forth in section 4.2 of draft-ietf-karp-design-guide. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 19, 2010. Copyright Notice Copyright (c) 2010 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 Hartman & Zhang Expires December 19, 2010 [Page 1] Internet-Draft OSPF Analysis June 2010 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 BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 3. Current State . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. OSPFv2 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Replay Detection . . . . . . . . . . . . . . . . . . . . . . . 6 5. IP Layer Issues . . . . . . . . . . . . . . . . . . . . . . . 7 6. OSPF Security Requirements . . . . . . . . . . . . . . . . . . 8 7. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. OSPFv2 Replay Mechanism . . . . . . . . . . . . . . . . . 9 7.2. OSPFv3 Replay . . . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Hartman & Zhang Expires December 19, 2010 [Page 2] Internet-Draft OSPF Analysis June 2010 1. Introduction This document performs the initial analysis of the current state of OSPFv2 and OSPFv3 according to the requirements of [I-D.ietf-karp-design-guide]. This draft builds on several previous analysis efforts into routing security. The OPSEC working group put together [I-D.ietf-opsec-routing-protocols-crypto-issues] an analysis of cryptographic issues with routing protocols. Earlier, the RPSEC working group put together [I-D.ietf-rpsec-ospf-vuln] a detailed analysis of OSPF vulnerabilities. Hartman & Zhang Expires December 19, 2010 [Page 3] Internet-Draft OSPF Analysis June 2010 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]. Hartman & Zhang Expires December 19, 2010 [Page 4] Internet-Draft OSPF Analysis June 2010 3. Current State This section describes the security mechanisms built into OSPFv2 and OSPFv3. 3.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. RFC 2328 defined 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. RFC 5709 [RFC5709] adds support for the SHA [FIPS180] family of hashes to OSPFv2. The cryptographic authentication described in RFC 5709 meets modern standards for per-packet integrity protection. 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. See Section 4 for discussion of the impacts of these replay attacks. 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. 3.2. OSPFv3 RFC 4552 [RFC4552] describes how the 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. The Security Parameter Index (SPI) provides an identifier for the security association. This along with other IPsec facilities provides a mechanism for moving from one key to another. Because manual keying is used, no replay protection is provided for OSPFv3. Hartman & Zhang Expires December 19, 2010 [Page 5] Internet-Draft OSPF Analysis June 2010 4. Replay Detection 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. While the LSA sequence number provides some defense, there are a number of attacks that are possible because of a per-packet replay. The RPSEC analysis [I-D.ietf-rpsec-ospf-vuln] 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. 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 age. 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. 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. Hartman & Zhang Expires December 19, 2010 [Page 6] Internet-Draft OSPF Analysis June 2010 5. IP Layer Issues The OSPFv2 cryptographic authentication does not include the IP header. So, fields like the source address are not protected. The OSPF specification uses the source address in some locations: for some network types, the source address is used to match which neighbor a packet is from. Changing the source address of a packet can produce a number of denial of service attacks. If the packet is interpreted as coming from a different neighbor, the sequence number received from the neighbor may be updated. This may disrupt communication with the legitimate neighbor. Hello packets may be reflected to cause a neighbor to appear to have one-way communication. Old Database descriptions may be reflected in cases where the per-packet sequence numbers are sufficiently divergent in order to disrupt an adjacency. RFC 4552 requires the support of ESP and permits the use of AH. ESP does not provide any protection of the IP source address. Ah does provide such protection. Hartman & Zhang Expires December 19, 2010 [Page 7] Internet-Draft OSPF Analysis June 2010 6. OSPF Security Requirements This section describes requirements for OSPF security that should be met within the routing protocol. As with all routing protocols, per-packet protection with a cryptographic MAC is required. Mechanisms are required in order to support key rollover. Multiple approaches could be used. However since the existing mechanisms provide a protocol field to identify the key as well as management mechanisms to introduce and retire new keys, focusing on the existing mechanism as a starting point is prudent. Replay protection is required. The replay mechanism needs to be sufficient to prevent an attacker from creating a denial of service or disrupting the integrity of the routing protocol by replaying packets. Hartman & Zhang Expires December 19, 2010 [Page 8] Internet-Draft OSPF Analysis June 2010 7. Gap Analysis 7.1. OSPFv2 Replay Mechanism The OSPFv2 mechanism allows an attacker to replay packets until the sequence number increases. Implementations are expected to increase their sequence number once a second or so. As discussed in Section 4, this strategy creates several opportunities for attack. In order to avoid significant denial of service issues, the replay mechanism needs to be improved. Part of this improvement may come simply from rules about when the sequence number should be increased. Other improvements are required to prevent attacks where an old replay is made either when an adjacency is down or from a time when a sequence number is significantly greater than the current sequence number to disrupt an association. 7.2. OSPFv3 Replay The replay vulnerabilities for OSPFv3 are greater than for OSPFv2. There is no mechanism providing replay protection at all. Even for manual keying, some replay mechanism is required. Hartman & Zhang Expires December 19, 2010 [Page 9] Internet-Draft OSPF Analysis June 2010 8. 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 protection of routing data from insider attack. RFC 2154 [RFC2154] provides an experimental solution for 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. Hartman & Zhang Expires December 19, 2010 [Page 10] Internet-Draft OSPF Analysis June 2010 9. Acknowledgments Funding for Sam Hartman's work on this memo is provided by Huawei. Hartman & Zhang Expires December 19, 2010 [Page 11] Internet-Draft OSPF Analysis June 2010 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. [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. [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. 10.2. Informative References [FIPS180] US National Institute of Standards and Technology, "Secure Hash Standard (SHS)", August 2002. [I-D.ietf-karp-design-guide] Lebovitz, G. and M. Bhatia, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines", draft-ietf-karp-design-guide-00 (work in progress), February 2010. [I-D.ietf-opsec-routing-protocols-crypto-issues] Jaeggli, J., Hares, S., Bhatia, M., Manral, V., and R. White, "Issues with existing Cryptographic Protection Methods for Routing Protocols", draft-ietf-opsec-routing-protocols-crypto-issues-06 (work in progress), June 2010. [I-D.ietf-rpsec-ospf-vuln] Jones, E. and O. Moigne, "OSPF Security Vulnerabilities Analysis", draft-ietf-rpsec-ospf-vuln-02 (work in progress), June 2006. [RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital Signatures", RFC 2154, June 1997. Hartman & Zhang Expires December 19, 2010 [Page 12] Internet-Draft OSPF Analysis June 2010 Authors' Addresses Sam Hartman Painless Security Email: hartmans-ietf@mit.edu Dacheng Zhang Huawei Email: zhangdacheng@huawei.com Hartman & Zhang Expires December 19, 2010 [Page 13]