Summary

  • The RSVP authentication v2 draft says that if the last applicable security association expires, a system should notify management and continue treating that association as valid until it is extended, deleted or replaced.
  • This is a fail-operational choice, not a claim that expired cryptography is harmless: reverting to unauthenticated RSVP is unacceptable, while abruptly disrupting reservations could cause a wider network fault.
  • The decisive evidence is not the configured expiry timestamp. It is a completed successor transition: replacement association active, overlap observed, receiver handshakes complete and management action recorded.

At midnight, a key expired. Nothing stopped.

The router continued to accept authenticated RSVP messages. Reservations were not torn down. The event might have produced a syslog or SNMP notification, but the packet path looked ordinary. In the specification now before the IETF's Traffic Engineering Architecture and Signaling working group, this is not necessarily a defect. It is the prescribed escape from a worse choice.

Revision 02 of RSVP Cryptographic Authentication Version 2 was posted on 27 September 2026 and is in working-group Last Call. It remains an Internet-Draft, intended for possible publication as a Proposed Standard; it is neither an RFC nor evidence that any named network has implemented the design. If approved, it would replace the authentication rules in RFC 2747 and RFC 3097.

Its most revealing passage is labelled “Pathological Case.” All security associations applicable to an RSVP exchange have expired. Returning to an unauthenticated condition is unacceptable. Yet disrupting current reservations, the draft warns, could contribute to a broader network fault. The recommended response is therefore twofold: tell the network manager that the last RSVP security association has expired, and treat that association as having an infinite lifetime until management extends it, deletes it or installs a new one.

That rule was already present in revision 01. The news is not that revision 02 invented it. The news is that a draft containing this operational bargain has reached its current review point. Reviewers are being asked to judge a design that turns expiry from an automatic enforcement boundary into an alarm and a local decision.

To understand why, it helps to be precise about what the key protects. RSVP, defined in RFC 2205 and extended for traffic engineering by RFC 3209, signals resource reservations. The new draft authenticates RSVP messages hop by hop with an INTEGRITY object. Here “sender” and “receiver” mean adjacent RSVP-speaking systems on that hop, not necessarily the application endpoints.

The object carries a 48-bit Key Identifier, a 64-bit sequence number and authentication data. A receiver combines the Key Identifier with the sending address to select a security association. That association also contains the cryptographic transform, authentication key, peer or interface scope, and start and end times. Associations are simplex: the two directions can use different keys.

These details make a bounded claim. An accepted message came from a peer holding the configured key, under the selected transform, with a sequence value the receiver regards as fresh. They do not make RSVP confidential; the draft explicitly leaves messages visible. They do not prove that an application was entitled to reserve capacity. They do not prove admission-control policy, data-plane forwarding or delivered service. Message validity is one reality layer, not the whole operational outcome.

Replay protection adds another dependency. The sequence number must be unique and increase during the life of the key. When a receiver restarts, it needs a safe current value. The draft therefore requires implementations to support an Integrity Handshake and recommends enabling it by default. The receiver sends an unpredictable cookie; the sender returns that cookie and its current sequence number inside a protected response. The unprotected challenge is acceptable because the value matters only when it comes back under authentication.

Every RSVP session must either use that handshake or keep sequence state in stable storage. Otherwise a restart can make old traffic look new. RFC 4086 and RFC 8937 supply the randomness discipline behind the cookie; they do not remove the need to know which receivers have actually completed the exchange.

Rollover is designed as an overlap, not a single timestamp. An implementation must support at least two simultaneous security associations and should support many. The replacement should start before the old one ends, with an overlap of at least twice the uncertainty between their clocks; the draft notes that five minutes is often sufficient. Each receiver must perform the handshake on the new association.

That sequence reveals the real transition condition. “New key configured” is not enough. The new association has to be applicable to the same communication surface, active according to a trustworthy clock, available at the sender, selectable at the receiver and initialized with a safe sequence value. Only then can the old key expire without opening a continuity gap.

Time is part of the security mechanism. If association lifetimes depend on clocks, those clocks must be sufficiently synchronized, and the draft says the time-distribution mechanism should be authenticated. RFC 5905 describes NTPv4, but citing a time protocol is not proof that the deployed time source is healthy. A rollover record needs actual clock status and uncertainty, not merely a configured NTP server.

The ordinary expired-key rule is strict. If a packet names an expired association while another applicable association is valid, the receiver must discard it without performing the cryptographic calculation. A rate-limited security error should be logged. That behavior prevents a peer from choosing the old key after the transition is genuinely available.

The last-key case reverses the outcome. With no valid alternative, the receiver is told to validate the packet under the expired association as though it were not expired. The design refuses two failure modes at once: it will not silently accept unauthenticated RSVP, and it will not automatically sacrifice running reservations to the calendar.

This is fail-operational security. It preserves a last-known authenticated relationship while declaring that the planned transition failed. The strength of that choice is continuity. Its danger is invisibility. Because traffic keeps working, an emergency exception can become a permanent operating state.

The word “infinite” matters. The draft gives the exception three exits: extend the association's lifetime, delete it through management, or configure a new association. It does not impose an automatic grace period. The protocol therefore cannot answer how long an organisation may tolerate the old key, who accepts the residual risk, which services can continue, or when continuity becomes less safe than a controlled interruption. Those are local decisions, but leaving them local does not make them optional.

Key management itself is outside the draft. Manual key distribution must be supported. A manually entered association may be configured to last forever, though the document discourages doing so. Algorithm agility is provided through an IANA registry for RSVP cryptographic transforms. Legacy HMAC-MD5 compatibility remains visible in the format, while RFC 6151 explains why MD5-era assurance requires care. None of this distributes a fresh secret to the right peers.

The minimum useful evidence set follows the transition rather than the expiry label. Record the Key Identifier and sending address that identify the association; its peer and interface scope; transform; configured start and end; the successor identifier; overlap window; clock offset and uncertainty; the receivers expected; handshake completion for each; first message accepted after expiry; notification delivery and acknowledgement; and the exact management action that ended the exception. Secrets need not enter the incident record. State provenance must.

That ledger separates four events dashboards often collapse: a key was created, a key became active, a receiver proved current sequence state, and the old key ceased to be the only usable association. The last event—not the first three independently—is the evidence that rollover completed.

Heng Lu's Running-Code Primacy offers the right reading discipline. The timestamp is a symbol; the packet-processing state is the running reality. Minimum Initial Specification explains why the shared protocol can remain narrow while local operators decide escalation and recovery. Reality Layers warns against confusing the label “expired” with proof that trust has actually ceased.

The draft does not hide that distinction. It makes it impossible to ignore. When the last key expires, RSVP does not solve the governance problem. It preserves the authenticated path, raises its hand and waits for someone to decide.

Sources