Summary

  • RFC 5304 permits a transition mode that sends HMAC-MD5 but does not verify received HMAC-MD5, and permits a non-implementing system to accept a PDU carrying that type. A MAC observed on the wire is not proof of receiver enforcement.
  • Password sets, purge-specific acceptance and rollover recovery create separate authority decisions. Even a successfully authenticated PDU proves only origin/integrity under the accepted key policy; it does not prove that the router is correct, the LSDB converged or traffic was delivered.

The seal belonged to the message, the decision to the gate

RFC 5304 extends the IS-IS Authentication Information TLV. Authentication type 54 identifies HMAC-MD5; the digest is computed over the PDU after the Authentication Value is zeroed, with additional treatment for the LSP checksum and remaining lifetime. Those mechanics describe how a verifier can reproduce a value. They do not say that every receiver attempted the reproduction.

The standard explicitly allows transition mode. A system may include HMAC-MD5 Authentication Information in the PDUs it sends while declining to verify that information in PDUs it receives. This helps a network introduce authentication without cutting over every neighbor at once. It also creates a state in which packet capture shows cryptographic material even though the inbound gate remains open.

A second compatibility clause is sharper still: an implementation that does not implement HMAC-MD5 may accept a PDU containing the HMAC-MD5 type. The field cannot compel enforcement by a system that lacks the mechanism. Observing the TLV, or even confirming that one peer generates it correctly, is evidence about the sender. It is not evidence about the receiving policy.

For an implementation that does implement HMAC-MD5 and receives the corresponding Authentication Information, the rule is firm: an incorrect Authentication Value must cause discard. Operational proof therefore requires the missing facts between syntax and effect: mechanism implemented, verification enabled, applicable key set loaded, digest evaluated, result recorded, PDU admitted or rejected, and resulting protocol state observed.

RFC 5304 is a 2008 Standards Track document that obsoleted RFC 3567. This article uses it to analyze enforcement semantics. It does not recommend HMAC-MD5 for a new deployment, and its historical assessment of cryptographic research is not current algorithm guidance.

One accepted digest may conceal several candidate keys

Key scope already varies by PDU. Level 1 Sequence Number PDUs use the area authentication string; Level 2 SNPs use the domain string; IIHs use a link-level string that may differ from LSP authentication. “IS-IS authentication enabled” hides which surface is protected by which secret.

During password change, an implementation may test a set of passwords. That makes incremental rollover possible, but acceptance alone no longer identifies the winning key. A green verification counter can mean “new key active,” “old key still accepted,” or “one of several candidates matched.” Without key-selection telemetry, the operator cannot prove that a deprecated secret has left the trust set.

This is a policy boundary rather than a cryptographic flaw. The verifier is intentionally authorized to accept more than one credential for a period. The important controls are the candidate set, ordering, activation and retirement times, scope, and evidence that the overlap ended. An indefinite overlap transforms a migration aid into permanent additional authority.

RFC 5310 later introduced Key IDs and generic HMAC-SHA security associations, making algorithm and key selection more explicit. Its existence does not rewrite RFC 5304's historical behavior, nor does it make a Key ID sufficient proof that the intended key was provisioned everywhere. The wider lesson is stable: the packet can name a mechanism, but receiver state decides what name means in practice.

Purge is a different kind of authenticated act

An ordinary authenticated LSP advertises state. A purge attempts to remove state by driving Remaining Lifetime to zero. RFC 5304 therefore does not let purge authority ride on ordinary parsing alone. A router implementing HMAC-MD5 and initiating a purge must strip the LSP body and add the authentication TLV. Such routers must reject unauthenticated purges and must reject purges containing TLVs other than authentication.

The restriction answers a concrete attack. Without it, a hostile system could receive a legitimate LSP, set its lifetime to zero and flood the result, causing removal without knowing the authentication password. The special form converts deletion into a separately constrained act.

This distinction belongs in operational evidence. “LSP authenticated” and “purge accepted under the purge profile” are not equivalent events. A purge record should show that the message had the required stripped shape, contained only the allowed authentication TLV, passed verification under the applicable policy, and caused the intended state removal. A rejected full-body purge is not a parser annoyance; it is the authority boundary working.

Rollover can strand a router behind its own old state

The most revealing implementation issue begins immediately after password rollover. Suppose the router or IS-IS process restarts. It originates under the new password with LSP sequence number 1. Neighbors still hold the router's older LSP at a higher sequence and reject the new lower sequence.

Ordinarily, the router would learn the higher value from the copy flooded back by its neighbors and advance its own sequence. But that copy is authenticated with the old password, which the restarted process may no longer accept. It cannot authenticate its own old state, so it cannot use the normal path to regain sequence authority. It may wait until neighbors age the old LSP out.

RFC 5304 suggests a bounded recovery: if an inbound LSP fails authentication, carries the local System ID and has a higher sequence, the process should advance accordingly and reflood. Yet an adversary can deliberately trigger the same condition. The RFC therefore recommends a counter.

This is not “accept unauthenticated routing.” It is a narrow use of untrusted metadata to repair a local sequence coordinate, followed by fresh authenticated origination. The counter matters because it exposes how often the exception is invoked. Recovery logic that affects sequence authority but produces no audit evidence turns a rare rollover case into an invisible control surface.

Authentication proves neither truth nor harmlessness

RFC 5304 says the mechanism raises the work factor compared with cleartext passwords. It also states its limits. It does not prevent replay in itself, although IS-IS rejects old information in many cases. It does not generally prevent denial of service. It does not protect the domain from a compromised, malfunctioning or misconfigured router.

That last boundary is the most important. HMAC validation can show that a PDU was produced by a holder of accepted keying material and arrived without the covered modification. It cannot show that the advertised topology is semantically correct, that the key holder was authorized to make this particular change, that every receiver selected the same key policy, or that the resulting route delivered traffic.

Assurance also depends on an entire chain: algorithm strength, key strength, correct implementation, and confidentiality of the shared key among every party. A valid digest is conditional evidence inside that chain. If a shared key escapes from one participant, the digest cannot distinguish that participant from another holder.

Limits of this analysis

The historical text records the cryptographic analysis available in 2008. It must not be used as current advice to deploy HMAC-MD5. Later specifications and current security guidance govern new design decisions. Nor does the RFC prove that a current implementation exposes transition mode, accepts unsupported authentication, reports selected keys or handles rollover in a particular way.

Verifying a live network requires implementation documentation, configuration, packet captures, rejection counters, selected-key evidence, rollover timing, purge logs, LSDB comparison and forwarding tests. This article does not supply those observations.

Its narrower claim is enough: authentication material, authentication capability, verification policy, accepted key, PDU-specific authority and routing outcome are separate facts. An audit that records only the first leaves the most consequential gates unexamined.

Sources