Stronger, Automatic Integrity Checks for OSPF Packets

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 .

The integrity of Open Shortest Path First versions 2 (OSPFv2) and 3 (OSPFv3) 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. 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 implementations) or, if supported, the stronger algorithms specified by . 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.

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.

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: This field indicates the new checksum algorithm that the routers must use and is described in detail in the later sections. This field is set to 0xA5. This magic, in combination with the OSPF and IP packet lengths, signals the use of this extension. The length in 4-octet words of the extended checksum data block appended to the OSPFv2 packet.

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.

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.

The data block for carrying extended checksum in OSPFv3 is formatted as described below.

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.

The same steps are followed as for D.4.1 of . 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. Implementations MUST append the extended checksum data, that is carried as part of the OSPF protocol payload, before the link local signaling (LLS) block (if it exists).

The packet data is padded out, as required by . 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 . 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 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 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.

The CRC32 algorithm, as used with IEEE 802.3 and defined by is used to calculate its 4-byte digest. The length set in the Null Authentication Data thus will be 1.

The MD5 algorithm, as per 5ref17 of 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.

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"

This extension does not raise any new security concerns. It only is used where operators have chosen not to configure cryptographic security mechanisms.