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.

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

1.  Introduction

The OSPFv2 [RFC2328] (Moy, J., “OSPF Version 2,” April 1998.) cryptographic authentication as described in [RFC2328] (Moy, J., “OSPF Version 2,” April 1998.) and later updated in [RFC5709] (Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., Li, T., and R. Atkinson, “OSPFv2 HMAC-SHA Cryptographic Authentication,” October 2009.) 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] (Jaeggli, J., Hares, S., Bhatia, M., Manral, V., and R. White, “Issues with existing Cryptographic Protection Methods for Routing Protocols,” August 2010.). 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] (Hartman, S. and D. Zhang, “Analysis of OSPF Security According to KARP Design Guide,” June 2010.).

[RFC2328] (Moy, J., “OSPF Version 2,” April 1998.) 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] (Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., Li, T., and R. Atkinson, “OSPFv2 HMAC-SHA Cryptographic Authentication,” October 2009.) in future deployments.

This draft proposes a simple change in the cryptographic authentication mechanism, as currently described in [RFC5709] (Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., Li, T., and R. Atkinson, “OSPFv2 HMAC-SHA Cryptographic Authentication,” October 2009.), to prevent such IP layer attacks.

2.  Cryptographic Authentication Mechanism in OSPFv2

The overall cryptographic authentication process defined in [RFC5709] (Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., Li, T., and R. Atkinson, “OSPFv2 HMAC-SHA Cryptographic Authentication,” October 2009.) 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] (Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., Li, T., and R. Atkinson, “OSPFv2 HMAC-SHA Cryptographic Authentication,” October 2009.).

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.

3.  Proposed Enhancement

This document updates the definition of Apad which is currently a constant defined in [RFC5709] (Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., Li, T., and R. Atkinson, “OSPFv2 HMAC-SHA Cryptographic Authentication,” October 2009.) 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] (Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., Li, T., and R. Atkinson, “OSPFv2 HMAC-SHA Cryptographic Authentication,” October 2009.). Besides changing the value of Apad this document does not introduce any other changes to the authentication mechanism described in [RFC5709] (Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., Li, T., and R. Atkinson, “OSPFv2 HMAC-SHA Cryptographic Authentication,” October 2009.).

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.

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.

5.  IANA Considerations

This document has no actions for IANA.

6.  Acknowledgements

7.  References

7.1. Normative References

7.2. Informative References

Author's Address