Summary

  • RFC 7474 joins a 32-bit boot count to a 32-bit packet counter so OSPFv2 freshness survives loss of volatile adjacency state. A receiver rejects a counter that does not exceed the last accepted value for that packet type, even when the digest is otherwise valid.
  • Acee Lindem edited the four-author standard with Manav Bhatia, Sam Hartman and Dacheng Zhang. Its limits are as important as its mechanism: losing persistent boot state requires new keys, automatic key management is out of scope, and safe rollover depends on time, peer, interface and direction matching in running routers.

The packet that waited for a reboot

Imagine an attacker recording an authenticated OSPF Database Description packet. The key is not known, and the digest cannot be forged. The packet is therefore useless while the receiving router remembers a later sequence number. Then the adjacency drops, the process restarts and the old receiver state disappears. The recorded packet has not become more authentic. It has become dangerous because the verifier has forgotten why it was old.

That distinction is the centre of RFC 7474, published on the Standards Track in April 2015. Earlier OSPFv2 cryptographic authentication attached sequence numbers to neighbour-adjacency state. When the adjacency went down, those values could be reinitialised. A digest could establish that a holder of the key produced a packet, yet the receiver could no longer establish where the packet belonged in time.

The document names Manav Bhatia, Sam Hartman, Dacheng Zhang and Acee Lindem, with Lindem serving as editor. The IETF Datatracker record connects Lindem to the publication and a wider routing record. It does not make him sole inventor, owner of OSPF or guarantor of any implementation. The useful attribution is narrower: his documented contribution belongs to a collective attempt to make protocol memory survive the failure boundary that previously erased it.

A stronger hash did not answer “when”

RFC 5709 had already added HMAC-SHA algorithms to OSPFv2 authentication. Its authors are Manav Bhatia, Vishwas Manral, Michael Fanto, Russ White, Michael Barnes, Tony Li and Randall Atkinson—not Lindem. Stronger algorithms improved resistance to forgery and replaced dependence on keyed MD5. They did not, by themselves, make a correctly authenticated packet current.

RFC 6039, by Vishwas Manral, Manav Bhatia, Joel Jaeggli and Russ White, described broader weaknesses in manual-key protection for routing protocols: long-lived shared keys, difficult rollover, replay exposure and incomplete binding between a packet and the context in which it should be accepted. Again, Lindem is not an author. The source belongs here because it explains the problem class that RFC 7474 narrows for OSPFv2.

The resulting lesson is easy to miss in security dashboards. “Authentication succeeded” answers one question about possession of key material and integrity of protected bytes. It does not answer whether this packet belongs to the present session, arrived from the protected source context or was intended for this protocol. Freshness, origin context and protocol separation need their own authenticated facts.

The router carries an epoch through the dark

RFC 7474 expands the cryptographic sequence number to 64 bits. The most significant 32 bits contain a boot count. The least significant 32 bits contain a strictly increasing packet counter. Together they form an epoch and a position inside that epoch.

The boot count must live in non-volatile storage for the deployed life of the OSPFv2 router. Whenever the implementation loses its previous packet-sequence state—including a cold restart—it increments that count. The document permits use of the SNMPv3 snmpEngineBoots value, but recommends a separate OSPF count because SNMP and OSPF may reinitialise for different reasons. The separation prevents one subsystem's lifecycle from becoming an accidental clock for another.

For every OSPF packet sent, the lower 32-bit counter increases. A receiver compares the combined freshness state with the last packet of the same OSPF packet type accepted from that neighbour. A value that is not greater is replayed and must be dropped. Packet types are tracked separately because prioritisation can reorder, for example, Hello and Link State Update traffic without making either a replay.

When the lower counter eventually wraps, the boot count can advance again so the aggregate remains strictly increasing. The design does not pretend a reboot never happened. It turns the reboot into an authenticated, monotonic change that an older recording cannot overtake.

The 64-bit value does not fit in the old header field. RFC 7474 places eight octets after the OSPF packet and includes them in the digest. It defines authentication type 3 and expands the Key ID to 32 bits. These are not packaging details detached from the security property. If the epoch were outside the authenticated material, an attacker could replace it. If the receiver compared one global stream instead of packet-type streams, lawful reordering could look hostile.

The source address joins the proof

The older authentication computation did not cover the IPv4 header. On broadcast and non-broadcast multi-access networks, OSPF uses the IP source address to identify the sending neighbour. An attacker able to change that address on a captured packet could therefore alter which neighbour's sequence state was updated without invalidating the old digest.

RFC 7474 changes the padding input used by RFC 5709 so its first four octets contain the IPv4 source address. The sender authenticates the address it will use; the receiver authenticates the address that arrived. A changed source now produces an authentication failure. This blocks the documented class of reflected or relabelled packets that could make a neighbour appear one-way or disturb Database Description exchange.

The boundary is exact. The document does not authenticate every mutable field in the IPv4 header. It adds the source fact that OSPF actually uses for neighbour identity. That is a minimum shared specification with a visible operational purpose: protect the field whose unauthenticated meaning can redirect protocol state.

One secret should not speak every protocol

Long-lived key databases can expose the same secret to more than one routing protocol. If the authentication input contains no protocol identity, a valid message construction from one use can sometimes be transplanted into another. RFC 7474 appends a two-octet OSPFv2 Cryptographic Protocol ID to the authentication key before the hash uses it.

This is domain separation. The underlying secret may be shared by operator choice, but the effective key context says “OSPFv2.” A packet cannot claim that context merely because it was authenticated somewhere else with the same stored bytes.

Domain separation does not excuse broad key sharing. Compromise of the long-lived secret still matters, and independent keys reduce the blast radius. The protocol identifier supplies a defensive boundary when shared infrastructure exists; it is not a statement that one key across systems is good custody.

Rollover is an interval, not a midnight switch

Manual keys have lifetimes in both directions. A transmit key is eligible only when the current time falls between its SendLifetimeStart and SendLifetimeEnd. A receive key uses its own accept interval. The difference allows a new key to be accepted before every sender begins using it and lets an old key remain acceptable briefly after transmit preference moves. That overlap is where safe rollover lives.

RFC 7474 then narrows selection by scope. The key must match the security algorithm, peer or area, interface and direction. An explicit interface or peer match outranks a catch-all. If several transmit keys still qualify, the one with the most recent send-lifetime start is selected. The packet carries its 32-bit Key ID; the receiver uses that ID, together with interface, peer, direction, algorithm and accept lifetime, to find the symmetric key.

This choreography converts a key change from an instantaneous assumption into an observable transition. First distribute the new key. Then open its accept interval. Then move transmit selection. Keep the old accept interval long enough for delayed packets and unsynchronised devices within the approved tolerance. Finally close and remove the old key after every required adjacency proves the new selection.

Time is therefore part of routing availability. A clock error can select no transmit key, reject the neighbour's new key or preserve the old key longer than intended. A configuration system that reports “both keys installed” has not proved that their send and accept windows overlap correctly on both ends.

Compatibility means refusing ambiguity

Authentication type 3 is new. A receiver whose configured interface expects a different authentication type drops the packet under existing OSPF rules. There is no silent negotiation down to an older type and no attempt to interpret the new trailer as the old format.

That behaviour can prevent adjacency during a partial rollout. It is still the safer compatibility result. Forming an adjacency while each endpoint assigns different freshness meaning to the same authenticated packet would make the link appear healthy by discarding the security property being introduced.

An operator must therefore treat deployment as an adjacency migration, not a local checkbox. Both ends need compatible code, matching type, matching effective keys, usable lifetime overlap and monotonic state. The gate is symmetric packet acceptance, followed by stable adjacency and forwarding—not successful configuration on the first router.

When memory is lost, the key is old too

RFC 7474 states its hardest operating rule plainly. If repair, upgrade or router replacement loses the non-volatile boot count, the authentication keys must change. Reusing the old key with a reset epoch would let recordings made under that key compete with the new low sequence space.

This turns device replacement into a cryptographic lifecycle event. Restoring the configuration file is insufficient. The replacement may have the same router ID, addresses, areas and key bytes while lacking the one fact that distinguished today's packets from yesterday's. Identity continuity on paper becomes replay vulnerability in running code.

There are further limits. If a router is taken completely out of service, replay of an entire identical adjacency-establishment exchange remains a stated but very unlikely scenario; rotating the relevant keys defeats it. If one source IP and one crypto sequence are used on two tapped unnumbered point-to-point links, the document recommends different keys per interface. Automatic key management remains outside its scope.

These cautions prevent a false conclusion. RFC 7474 does not make manual keys self-maintaining or make replay impossible under every topology. It supplies a bounded, testable improvement and names the events that invalidate its assumptions.

Minimal wire rules, local custody

Lu Heng's later Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption offers Sofia Ren an analytical lens for this design. The shared layer can be small: sequence structure, authenticated source, protocol identifier, key identifier and rejection semantics. The operator retains decisions about key generation, storage, interface scope, lifetime overlap, rollout units and recovery.

If the shared layer prescribed every custody system, it would overreach. If it omitted the monotonic epoch and receiver rule, interoperable packets could carry incompatible ideas of freshness. The useful boundary standardises what two routers must agree on while leaving each network responsible for protecting and proving its implementation.

Running-Code Primacy raises the evidence threshold. A configured algorithm and Key ID are only intent. Proof links persistent boot state, emitted sequence, selected key, source-bound digest, receiver comparison, replay-drop counter, adjacency state and forwarding. The Heng texts are a later editorial framework; they are not evidence of Lindem's private intention or of IETF consensus beyond the RFCs.

The resulting rule is severe because the threat is patient. The attacker can remember what the router forgets. RFC 7474 reverses that advantage by requiring the router's security identity to cross the reboot boundary. When that memory cannot be trusted, the old key can no longer safely authenticate a new life.

Sources