Summary

  • The TEAS working group's RSVP Cryptographic Authentication v2 draft is in Working Group Last Call through 30 September 2026; revision 02 was posted on 27 September. It is still an Internet-Draft, not an approved RFC.
  • If a received RSVP message uses an expired security association and another valid one exists, the draft says to discard it. If all applicable associations have expired, the draft instead describes validation with the old association and a continuity exception for the last one.
  • That exception does not make expiration irrelevant or authorize unauthenticated signalling. It shifts responsibility to the operator to detect the exceptional state, arrange replacement and establish when the old association finally ceased to be accepted.

At midnight, an operator might expect a key to stop working because its configured lifetime ended. RSVP signalling complicates that expectation. A replacement association may have been missed, while dropping authenticated messages can disrupt reservations and their downstream network behaviour. The TEAS draft does not resolve this by letting unauthenticated messages through. It proposes keeping the final expired security association available until someone extends its lifetime, deletes it, or configures a new one.

The distinction between two expiry cases is essential. In the draft's receive procedure, a message bearing an expired association is discarded without cryptographic processing when a different valid association is available. With no valid replacement at the time of receipt, the expired association is used for validation. Section 5.4 then addresses the wider failure in which all applicable associations have expired: the system SHOULD notify a network manager and SHOULD treat the last association as having an infinite lifetime temporarily. A message still needs its cryptographic authentication checked.

The exceptional extension concerns the lifetime rule, not a switch to plaintext trust.

This is a governance choice embedded in protocol behaviour. A calendar limit is easy to audit only when a successor exists and takes over. Without one, the draft prefers authenticated continuity over an automatic signalling cliff. Its language also calls the all-expired condition strongly undesirable and urges operators to prevent it. The remaining hard question is not whether the old key has become young again; it has not. It is how long the operator lets a known exception persist and what evidence closes it.

The draft builds a normal route away from that corner. Implementations must be able to hold at least two active security associations for each protected interface or peer, and overlapping lifetimes allow a key change despite clock uncertainty. A receiving node can select the association through the sender address and Key Identifier. None of those design provisions demonstrates that any particular network has staged a replacement or tested its rollback. Nor does an Internet-Draft by itself change an installed configuration.

The process record should be read with equal care. TEAS began its Working Group Last Call on 16 September, asking for responses by the 30th. A Security Area Directorate reviewer marked revision 01 Ready on 21 September, saying earlier key-management concerns and the pathological-case trade-off had been addressed. Revision 02 followed on 27 September. A comparison of the official drafts shows editorial changes, added references and a proposed registry note; the last-association exception was not invented by this revision.

An early security review is input to standards work, not approval by the IESG or evidence that operators have deployed the mechanism.

Algorithm agility is another separate boundary. The base text specifies a mechanism independent of a mandatory cryptographic transform. Its proposed IANA registry initially lists HMAC-MD5 as SHOULD while noting that it is legacy and to be deprecated; a distinct HMAC-SHA2 working-group draft describes other transforms. None of these labels says which algorithm a router is running or proves that its keys were rotated before expiry.

For a live operator, a useful local record would timestamp the first all-expired alert, identify the affected association and neighbours, record which authenticated messages were accepted under the exception, and show when a tested replacement became active. That is this article's proposed accountability practice, not a TEAS requirement. Without such a record, “still authenticated” risks being mistaken for “still within policy.” The draft keeps those statements apart; the operator has to keep them apart in operations too.

Sources