Security Extension for OSPFv2 When Using Manual Key Management
Extracted elements (22)
Incorporating the IP source address into Apad rather than into the OSPF packet itself is the minimal change needed to bind the IP header to the authentication: it reuses the RFC 5709 hash framework and requires only that the Apad initialization change, leaving the overall cryptographic process unchanged.
OSPFv2 per-packet sequence numbers are maintained as adjacency state; when an adjacency is torn down the sequence numbers are reinitialized, enabling inter-session replay attacks. Additionally, sequence number rollover is unspecified, enabling intra-session replay. These gaps motivated the 64-bit extended sequence number design.
The pre-existing cryptographic authentication (RFC 2328, RFC 5709) does not cover the IP header. Because OSPFv2 on broadcast and NBMA networks uses the IP source address to identify neighbors, an attacker can change the source address to disrupt adjacency state, reflect Hello packets, or replay Database Description packets. This document addresses the omission by binding the IP source address into the authentication hash.
Authentication Type 3 is backward compatible: when an OSPFv2 packet is received with an AuType that does not match the interface's configured authentication type, the packet is dropped per RFC 2328, the same behavior as any other authentication type mismatch.
A separate OSPF boot count (independent of the SNMPv3 snmpEngineBoots variable) is RECOMMENDED, because it decouples OSPF reinitialization from SNMP reinitialization and can also be incremented in the rare event the lower-order 32-bit counter wraps.
OSPF routers MUST use available mechanisms to preserve the strictly increasing property of the sequence number for the deployed life of the router, including cold restarts. This is achieved by incrementing the boot count in non-volatile storage each time prior sequence number state is lost.
OSPFv2 implementations are REQUIRED to retain the boot count in non-volatile storage for the entire deployment life of the OSPF router, so that the 64-bit sequence number's strictly increasing property is preserved across cold restarts.
The lower-order 32-bit sequence number MUST be incremented for every OSPF packet sent. Upon reception, the received sequence number MUST be greater than the sequence number in the last accepted OSPF packet of that type from the same neighbor; otherwise the packet MUST be treated as a replay and dropped.
When receiving an OSPFv2 packet, implementations MUST initialize the first 4 octets of Apad to the IP source address from the IP header of the incoming packet. This ensures that any alteration of the IP source address will cause authentication verification to fail.
When sending an OSPFv2 packet, implementations MUST initialize the first 4 octets of the Apad constant to the IP source address that would be used, with the remainder filled with 0x878FE1F3 repeated (L-4)/4 times, where L is the hash output length in octets.
When XORing Ko with Ipad or Opad during HMAC computation, Ko MUST be padded with zeros to the length of Ipad or Opad. This was previously unspecified in RFC 5709.
A 64-bit sequence number is defined: the most significant 32 bits hold a boot count (persisted across restarts in non-volatile storage) and the least significant 32 bits hold a strictly increasing per-packet counter. The combined value provides replay protection across both session boundaries (inter-session) and within a session (intra-session).
Authentication Type 3, 'Cryptographic Authentication with Extended Sequence Numbers', is defined for the OSPFv2 header AuType field. It replaces the in-header sequence number of earlier types with an extended 64-bit sequence number appended after the OSPF packet, included in the IP header length but not the OSPF header length.
For multicast key selection (AllSPFRouters or AllDRouters), the key's Peers field must first match the area ID; if absent, 'all' is used. The key's Interfaces field must match the sending interface or 'all', and Direction must be 'out' or 'both'. The most recent SendLifetimeStart key wins among multiple matches.
For packet reception, the Key ID in the OSPFv2 header is used directly to locate the corresponding key. Because OSPFv2 keys are symmetric, LocalKeyName and PeerKeyName are identical. The Direction field must be 'in' or 'both', and the receiving interface must be associated with the key.
For unicast key selection, the required key must have a Peers field matching the area ID (or 'all'), a Direction of 'out' or 'both', and an Interfaces field matching the outgoing interface. When multiple keys match, the key with the most recent SendLifetimeStart is preferred to facilitate graceful key rollover. For virtual links, the Peers field must encode both the transit area ID and the virtual endpoint's router ID.
To prevent cross-protocol replay attacks when keys are shared between routing protocols, the two-octet OSPFv2 Cryptographic Protocol ID (value 3, registered with IANA under KARP Parameters) is appended to the authentication key K before key preparation, yielding a Protocol-Specific Authentication Key Ks.
IANA registered code point 3 ('Cryptographic Authentication with Extended Sequence Numbers') in the 'OSPF Shortest Path First (OSPF) Authentication Codes' registry.
IANA registered code point 3 for OSPFv2 in the 'Authentication Cryptographic Protocol ID' registry under 'Keying and Authentication for Routing Protocols (KARP) Parameters', used to construct a protocol-specific authentication key that prevents cross-protocol replay attacks.
If the non-volatile storage holding the boot count is lost (e.g., due to hardware repair or router replacement), the authentication keys MUST be changed to prevent replay attacks, since an adversary could replay packets with sequence numbers from before the loss.
Using a single cryptographic sequence number leaves a router vulnerable to replay attacks on point-to-point unnumbered links sharing the same IP source address. In environments where an attacker can tap such links, different manual keys SHOULD be configured on each unnumbered interface.
Authentication Type 3 redefines the 64-bit OSPFv2 header authentication field: a 24-bit zero field, an 8-bit Auth Data Length, and a 32-bit Key ID (expanded from 16 bits). The 64-bit sequence number (32-bit boot count followed by 32-bit packet counter) is placed in the 8 octets immediately following the OSPFv2 packet, protected by the authentication digest but excluded from the OSPF packet header length field.