Summary

  • RFC 2154 attached a persistent digital signature to each OSPF LSA and distributed a certified router key in a Public Key LSA, preserving origin and covered-byte integrity beyond one neighbour.
  • The certificate constrained identity, role and permitted address ranges; it did not measure whether a link existed, a metric was honest, an external route was authorized or a destination was reachable.
  • A defensible routing record therefore needs separate receipts for trust anchor, key generation, LSA currency, policy approval, corroboration, SPF choice, FIB installation and observed delivery.

The seal crossed the network intact

Picture an LSA leaving one router with a seal that every later router can inspect but none may replace. It crosses two intermediate systems, enters three link-state databases and retains the same origin evidence. The seal verifies. Then an engineer walks to the advertised stub network and finds an empty rack.

That is not a paradox. It is the exact limit that makes RFC 2154 historically useful. Published as Experimental in June 1997, the proposal moved protection from the OSPF packet exchanged by neighbours to the individual routing statement being flooded. Hello, Database Description, Request and Update packets still needed neighbour authentication. Each LSA inside an Update acquired its own signature from the advertising router.

The distinction mattered because an intermediate router could relay an LSA without becoming its author. A successful check said the covered bytes came from the key associated with the Advertising Router and had not been modified along the flood path. If the information was wrong, the signature gave investigators a source. It did not repair the information.

A key needed a history of its own

A public key alone cannot identify a router; anyone can publish a key and claim a Router ID. RFC 2154 therefore created the Router Public Key LSA, or PKLSA. Its certificate was signed by a Trusted Entity and carried Router ID, router role, allowed address ranges, a creation time, algorithm and public key. Receivers first checked the TE certification and the router's signature on the PKLSA. Failure of either check meant discard.

That design created a chain, not a single green light. The TE public key had to be installed outside OSPF. The PKLSA had to be current. The signed LSA had to name the corresponding router key. If an LSA arrived before its key, it could wait only for the configured MAX_TRANSIT_DELAY before discard. When a newer certified key superseded an older one, the router had to re-originate its LSAs and the network had to retire material signed under the old key.

The certificate's address ranges narrowed what an internal router could claim. They did not prove that an address was occupied, that a port was up or that an administrator had approved this metric. Certificate validity was provenance about a key and a permitted envelope.

Time could change without breaking the seal

OSPF LSA age changes as information travels, so RFC 2154 normally excluded age from the signature. A special exception covered an originator-created MaxAge LSA: only the originator could sign the age value that requested a synchronized flush. A relay could still let an orphaned LSA age out locally, but could not forge the originator's signed withdrawal.

This improved custody at a cost. Signed LSAs from a failed router would reach MaxAge independently in different databases instead of being flushed everywhere when one router observed MaxAge. The document accepted slower convergence to close a deletion vulnerability. It also allowed signed and unsigned areas to coexist only through deliberate ABR boundaries; a summary created across that boundary was a new statement under the ABR's authority.

These details show why “signature valid” is an incomplete operational status. Which TE key did the verifier trust? Which router-key generation was current? Which bytes were covered? Was this an originator-signed MaxAge or ordinary local ageing? Did a new key arrive within the expected transit interval? The mathematics cannot answer those lifecycle questions without state around it.

The RFC named the liar without making it truthful

Section 9 is unusually candid. An internal router may sign the wrong metric for a real link, claim that a link is up when it is down, or advertise a nonexistent stub network or host route. A false transit link often needs a matching claim from the other endpoint before SPF uses it, but a stub has no second endpoint to corroborate it.

ABRs can originate false summaries about another area or the backbone. The RFC considered having ABRs cross-check or duplicate one another's summaries, then left that protection out because it required more processing and traffic. ASBRs were harder still: the document said there was no internal authority equivalent to the address-range certificate for authorizing the external networks they could announce.

The signature made blame more precise when a contradiction became visible. It did not discover every contradiction. Nor did RFC 2154 protect data-packet forwarding. A verified LSA could enter the LSDB, influence a correct SPF calculation and install a route whose next hop still dropped the packet.

Preserve nine receipts, not one verdict

A trustworthy record begins with the TE trust anchor and the administrator who installed it. Next come the router certificate, role, address range, key generation and revocation state. The LSA receipt preserves identity, sequence, covered-byte hash and signature result. A currency receipt explains key replacement, age and MaxAge handling.

Authorization belongs in a separate change or policy record. Corroboration may come from the other end of a transit link, interface state or independent topology observation. The SPF receipt records which LSDB generation produced the selected path. RIB and FIB state prove installation. Only a destination-specific probe and application result can establish delivery inside a declared window.

The RFC Editor record, Datatracker record and document history establish the Experimental paper trail; the errata page corrects only an editorial typo. RFC 2328 supplies standard OSPFv2 context. RFC 6039 later reported no deployment experience, while RFC 6863 kept end-to-end routing-data protection separate from packet replay defense. RFC 7474 solved a different problem: preserving authenticated packet freshness across reboot. An expired individual draft criticized insider resistance but never acquired IETF standing.

Heng Lu's Running-Code Primacy puts the observed execution result after the document. Minimum Initial Specification supports a narrow, locally verifiable common claim. Reality Layers warns against lending executable authority to a symbolic credential. Those are disclosed editorial lenses, not requirements imposed by RFC 2154.

Sources