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, <http://handle.dtic.mil/100.2/ADA013939>.
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,
<http://dx.doi.org/10.1109/90.731187>.
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]