Open Shortest Path First IGP P. Jakma Working Group DCS, Uni. of Glasgow Internet-Draft M. Bhatia Updates: 2328 (if approved) Alcatel-Lucent Intended status: Standards Track October 13, 2010 Expires: April 16, 2011 Stronger, Automatic Integrity Checks for OSPF Packets draft-jakma-ospf-integrity-00 Abstract This document describes an extension to OSPFv2 and OSPFv3 to allow a stronger integrity check to be applied to the protocol packets, than the default OSPF checksum, which is known to be weak. The extension allows OSPF speakers to negotiate the use of a CRC integrity check, as a new psuedo-authentication type. 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 16, 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 Jakma & Bhatia Expires April 16, 2011 [Page 1] Internet-Draft OSPF Integrity Checks October 2010 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. Table of Contents 1. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Stronger Checksum mechanism for OSPFv2 . . . . . . . . . . . . 3 3.1. Null Authentication Data . . . . . . . . . . . . . . . . . 4 4. Stronger Checksum mechanism for OSPFv3 . . . . . . . . . . . . 4 4.1. EC-Bit in Options Field . . . . . . . . . . . . . . . . . . 4 4.2. Extended Checksum Data Block . . . . . . . . . . . . . . . 5 5. Generation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Verification . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Stronger Integrity Algorithm Types . . . . . . . . . . . . . . 7 7.1. CRC32 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.2. MD5-Digest . . . . . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Jakma & Bhatia Expires April 16, 2011 [Page 2] Internet-Draft OSPF Integrity Checks October 2010 1. Requirements Language 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. Introduction The integrity of Open Shortest Path First versions 2 (OSPFv2)[RFC2328] and 3 (OSPFv3)[RFC5340] packets is protected either through the standard internet protocol checksum, or through some cryptographic integrity scheme within OSPF, or, more rarely, through IPSec. This provides a check against errors that can not be caught by the link-layer integrity checks, e.g. errors in lower layers of the software stack or in hardware of the host. The internet protocol checksum is known to have weaknesses[partridge]. In particular it can not detect re-ordered words and certain patterns of bit flips. If stronger integrity checks are desired, the only option is to use cryptographic HMACs, either with MD5 (all conforming [RFC2328] implementations) or, if supported, the stronger algorithms specified by [RFC5709]. There are some disadvantages though to using the existing support for cryptographic HMACs purely for integrity checking. The algorithms require more computation, which may be noticable on less powerful and/or energy-sensitive platforms. Additionally, the need to configure key material is an additional administrative burden. This documents extends OSPF to allow for the automatic and backward compatible use of stronger integrity checks. Backward compatibility implies the default null authentication type must be used and extended. 3. Stronger Checksum mechanism for OSPFv2 The null authentication mode of OSPFv2 is extended to make use of the authentication data field of the OSPFv2 packet header. Where previously this field was ignored for null authentication, now an OPTIONAL "Null Authentication Data" structure is recognised there. Implementations MUST provide a means to disable this extension, in case there are non-conforming RFC2328 implementations. Implementations MAY wish to generate a CRC32 checksum by default via this extension, and SHOULD attempt to verify any received, regardless of whether they generate the same or not. Jakma & Bhatia Expires April 16, 2011 [Page 3] Internet-Draft OSPF Integrity Checks October 2010 3.1. Null Authentication Data 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum Type | 0xA5 | Data Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ignored | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Null Authentication Data The authentication data field in the standard OSPFv2 packet header is redefined as shown above, when null authentication is used. The new field definitions are as follows: Checksum Type: This field indicates the new checksum algorithm that the routers must use and is described in detail in the later sections. Magic: This field is set to 0xA5. This magic, in combination with the OSPF and IP packet lengths, signals the use of this extension. Data Length: The length in 4-octet words of the extended checksum data block appended to the OSPFv2 packet. 4. Stronger Checksum mechanism for OSPFv3 OSPFv3 uses IPSec for protection and does not carry any authentication information in its headers. Thus it is not possible to overload the Null Authentication type as was done in case of OSPFv2. 4.1. EC-Bit in Options Field A new EC-bit (EC stands for Extended Checksum) is introduced into the OSPFv3 Options field. Routers MUST set the EC-bit in all OSPFv3 packets to indicate that the packet is carrying the new extended checksum data. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+--+--+--+--+--+ | | | | | | | | | | | | | |EC|L|AF|*|*|DC| R| N|MC| E|V6| +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+--+--+--+--+--+ Jakma & Bhatia Expires April 16, 2011 [Page 4] Internet-Draft OSPF Integrity Checks October 2010 Figure 2: OSPFv3 Options Field 4.2. Extended Checksum Data Block The data block for carrying extended checksum in OSPFv3 is formatted as described below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum Type | 0xA5 | Data Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Extended Checksum Data Block ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: OSPFv3 Options Field The Checksum Type is of two octets and indicates the new checksum algorithm that the routers must use. This is described in detail in the later sections. The next field is a reserved magic field set to 0xA5. The Data length field is of two octets and carries the size of the entire extended checksum data block that has been appended to the OSPFv3 payload, specified in units of 4-octet words. The Extended Checksum Data Block carries the checksum data that the recievers will use to verify the integrity of the OSPFv3 protocol payload. 5. Generation The same steps are followed as for D.4.1 of [RFC2328]. Additionally, a 2nd integrity check algorithm is also computed over the packet data, with at least the same amount of zero padding, to produce an "extended checksum", which is appended to the OSPFv2 packet. Its is size accounted for in the Null Authentication Data "data length" field and in the IP length, but not in the OSPFv2 packet header, in a similar fashion to the standard OSPFv2 cryptographic authentication mechanism. The "Checksum Type" and "Data Length" fields are set to the appropriate values for the 2nd integrity check algorithm. In case of OSPFv3 the entire extended checksum block is appended to the OSPFv3 packet, with its size accounted for in the IPv6 payload length, but not in the OSPFv3 packet header. Jakma & Bhatia Expires April 16, 2011 [Page 5] Internet-Draft OSPF Integrity Checks October 2010 Implementations MUST append the extended checksum data, that is carried as part of the OSPF protocol payload, before the link local signaling (LLS) [RFC5613] block (if it exists). +---------------------+ -- -- +---------------------+ | IP Header | ^ ^ | IPv6 Header | | Length = HL+X+Y+Z | | Header Length | | Length = HL+X+Y+Z | | | v v | | +---------------------+ -- -- +---------------------+ | OSPF Header | ^ ^ | OSPFv3 Header | | Length = X | | | | Length = X | | | | | | | | NULL Authentication | | | | | | Length = Y | | | | | |.....................| | X | X |.....................| | | | | | | | OSPFv2 Data | | | | OSPFv3 Data | | | v v | | +---------------------+ -- -- +---------------------+ | | ^ ^ | | | Extended Checksum | | Y | Y | Extended Checksum | | | v v | | +---------------------+ -- -- +---------------------+ | | ^ ^ | | | LLS Data | | Z | Z | LLS Data | | | v v | | +---------------------+ -- -- +---------------------+ ` Figure 4: Extended Checksum Block in OSPFv2 and OSPFv3 6. Verification The packet data is padded out, as required by [RFC2328]. In case of OSPFv2, the Null Authentication Data "0xA5" magic field is examined. If it does not match, then verification proceeds as per D.5.1 of [RFC2328]. If it matches, then the IP length in the header MUST be verified. An incoming packet will only contain a valid extended checksum if the length in the IP header = length in OSPF header + "data length" in the NULL Authentication header + data length in the LLS [RFC5613] block (if it exists). Implementations can trivially determine if an LLS block is being carried by inspecting the "L" bit in the OSPF Options field in the HELLOs and DDs. Implementations MUST proceed with regular checksum if these numbers dont match. If they do then the IP checksum field of the OSPF header MUST be ignored. Instead the stronger integrity Jakma & Bhatia Expires April 16, 2011 [Page 6] Internet-Draft OSPF Integrity Checks October 2010 algorithm specified by the "Checksum Type" field is used, and verified against the corresponding checksum. The packet MUST be discarded if the computed checksum does not match with what's carried in the OSPF packet. In case of OSPFv3, the presence of the EC-bit in the OSPFv3 Options field will indicate that a new checksum algorithm is being used. Routers MUST parse the packet till the end of the OSPFv3 payload till it reaches the start of the extended checksum data block. The processing that follows next is similar to the way its done for OSPFv2 as explained earlier. 7. Stronger Integrity Algorithm Types 7.1. CRC32 The CRC32 algorithm, as used with IEEE 802.3 and defined by [hammond] is used to calculate its 4-byte digest. The length set in the Null Authentication Data thus will be 1. 7.2. MD5-Digest The MD5 algorithm, as per 5ref17 of [RFC2328] is used in plain digest mode (i.e. solely over the data, unlike the HMAC mode used by cryptographic authentication) to calculate its 8-byte digest. The length set in the Null Authentication Data thus will be 2. 8. IANA Considerations OSPFv2 Null Authentication Checksum Types are maintained by the IANA. Extensions to OSPFv2 that require a new Checksum Type must be reviewed by a designated expert from the routing area. This document assigns OSPF Null Authentication Checksum Types 1 and 2, for CRC32 and MD5-Digest respectively. IANA is also requested to allocate EC-bit in the OSPFv3 "Options Registry" 9. Security Considerations This extension does not raise any new security concerns. It only is used where operators have chosen not to configure cryptographic security mechanisms. Jakma & Bhatia Expires April 16, 2011 [Page 7] Internet-Draft OSPF Integrity Checks October 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. [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008. [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. [hammond] Hammond, J., Brown, J., and S. Lui, "Development of a Transmission Error Model and an Error Control Model", Technical Report Georgia Institute of Technology, May 1975, . 10.2. Informative References [RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. Yeung, "OSPF Link-Local Signaling", RFC 5613, August 2009. [partridge] Stone, J., Greenwald, M., Partridge, C., and J. Hughes, "Performance of checksums and CRC's over real data", IEEE/ ACM Trans. Netw. vol 6, num 5, pages 529-543, 1998, . Authors' Addresses Paul Jakma School of Computing Science, University of Glasgow Lilybank Gardens Glasgow G12 8QQ Scotland Email: paulj@dcs.gla.ac.uk Jakma & Bhatia Expires April 16, 2011 [Page 8] Internet-Draft OSPF Integrity Checks October 2010 Manav Bhatia Alcatel-Lucent Bangalore, India Phone: Email: manav.bhatia@alcatel-lucent.com Jakma & Bhatia Expires April 16, 2011 [Page 9]