KARP Working Group M. Bhatia Internet-Draft Alcatel-Lucent Intended status: Standards Track October 7, 2010 Expires: April 10, 2011 Mechanism to protect OSPFv2 authentication from IP Layer Issues draft-bhatia-karp-ospf-ip-layer-protection-00 Abstract The IP header is not covered by the MAC in the cryptographic authentication scheme as described in RFC 2328 and RFC 5709, and an attack can be made to exploit this omission. This draft proposes a simple change in how the authentication is computed to eliminate most of such attacks. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 10, 2011. 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 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. Bhatia Expires April 10, 2011 [Page 1] Internet-Draft OSPF IP Layer Protection October 2010 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 [RFC2119]. When used in lower case, these words convey their typical use in common language, and are not to be interpreted as described in RFC2119 [RFC2119]. Bhatia Expires April 10, 2011 [Page 2] Internet-Draft OSPF IP Layer Protection October 2010 1. Introduction The OSPFv2 [RFC2328] cryptographic authentication as described in [RFC2328] and later updated in [RFC5709] does not include the IP header. This can be exploited to launch several attacks as the source address in the IP header is no longer protected. The OSPF specification, in certain cases, requires the implementations to look at the source address carried in the IP header to determine the neighbor the packet was recieved from. Changing the source address of a packet can thus, confuse the reciever which can be exploited to produce a number of denial of service attacks. [I-D.ietf-opsec-routing-protocols-crypto-issues]. 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 [I-D.hartman-ospf-analysis]. [RFC2328] states that implementations MUST offer keyed MD5 authentication. It is likely that this will be deprecated in favor of the stronger algorithms described in [RFC5709] in future deployments. This draft proposes a simple change in the cryptographic authentication mechanism, as currently described in [RFC5709], to prevent such IP layer attacks. Bhatia Expires April 10, 2011 [Page 3] Internet-Draft OSPF IP Layer Protection October 2010 2. Cryptographic Authentication Mechanism in OSPFv2 The overall cryptographic authentication process defined in [RFC5709] remains unchanged. To reduce the potential for confusion, this section minimises the repetition of text from RFC 5709 and is incorporated here by reference [RFC5709]. RFC 5709, Section 3.3, describes how the cryptographic authentication must be computed. It requires OSPFv2 packet's Authentication Trailer (which is the appendage described in RFC 2328, Section D.4.3, Page 233, items (6)(a) and (6)(d)) to be filled with the value Apad where Apad is a hexadecimal constant value 0x878FE1F3 repeated (L/4) times, where L is the length of the hash being used and is measured in octets rather than bits. Bhatia Expires April 10, 2011 [Page 4] Internet-Draft OSPF IP Layer Protection October 2010 3. Proposed Enhancement This document updates the definition of Apad which is currently a constant defined in [RFC5709] to the source address thats carried in the IP header of the OSPFv2 protocol packet. Routers at the sending side must initialize Apad to a value of the source address that would be used when sending out the OSPFv2 packet, repeated L/4 times, where L is the length of the hash, measured in octets. The basic idea is to incorporate the source address from the IP header in the cryptographic authentication computation so that any change there can be detected. At the recieving end implementations MUST initialize Apad as the source address that exists in the IP Header of the incoming OSPFv2 protocol packet, repeated L/4 times, instead of the constant that's currently defined in [RFC5709]. Besides changing the value of Apad this document does not introduce any other changes to the authentication mechanism described in [RFC5709]. This would prevent all attacks where a rogue OSPF router changes the source address of the protocol packet and reflects it on some other interface as the authentication check would fail and all such packets would get rejected. Bhatia Expires April 10, 2011 [Page 5] Internet-Draft OSPF IP Layer Protection October 2010 4. Security Considerations This document enhances the security of OSPFv2 and provides a solution to prevent certain denial of service attacks that can be launched by changing the source address of the OSPFv2 protocol packet. The proposal defined does not introduce any new security concerns. Bhatia Expires April 10, 2011 [Page 6] Internet-Draft OSPF IP Layer Protection October 2010 5. IANA Considerations This document has no actions for IANA. Bhatia Expires April 10, 2011 [Page 7] Internet-Draft OSPF IP Layer Protection October 2010 6. Acknowledgements Bhatia Expires April 10, 2011 [Page 8] Internet-Draft OSPF IP Layer Protection October 2010 7. References 7.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. [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. 7.2. Informative References [I-D.hartman-ospf-analysis] Hartman, S. and D. Zhang, "Analysis of OSPF Security According to KARP Design Guide", draft-hartman-ospf-analysis-01 (work in progress), June 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-07 (work in progress), August 2010. Bhatia Expires April 10, 2011 [Page 9] Internet-Draft OSPF IP Layer Protection October 2010 Author's Address Manav Bhatia Alcatel-Lucent Bangalore, India Phone: Email: manav.bhatia@alcatel-lucent.com Bhatia Expires April 10, 2011 [Page 10]