Summary

  • RFC 2385 permitted synchronized key changes but supplied no in-protocol negotiation or identifier for coordinating them.
  • RFC 5925 gave TCP-AO each segment a KeyID and RNextKeyID: the first names the MKT used to send this segment, while the second announces the MKT the sender is ready to use for future segments it receives.

The awkward moment is not when an authenticated TCP session begins. It is hours or months later, when the key should change while the session still carries useful state. If both endpoints switch at an agreed wall-clock instant, packets already in flight can arrive under the old key. If one side moves early, valid traffic can look forged. Rebuilding the connection avoids the overlap but sacrifices the continuity that made the session valuable.

RFC 2385, published in 1998 for protecting BGP sessions, attached a 16-byte MD5 digest to every protected TCP segment. The key remained an independently configured secret known to both endpoints. The document allowed a key to change during a connection if both sides synchronized the change, yet defined no negotiation for achieving that synchronization. The option carried the digest, not a key identifier or a declaration of what key the peer should use next.

RFC 5925's TCP Authentication Option, published in 2010, replaced that arrangement with explicit state. A Master Key Tuple, or MKT, binds connection selectors, identifiers, keying material, algorithms and parameters. TCP-AO derives directional traffic keys for a particular connection rather than using the configured master key as identical packet material everywhere. The components of an instantiated MKT stay fixed, but the set of MKTs available to a connection may change, and the connection may switch which MKT it uses.

Two one-byte fields make the transition observable. KeyID identifies the MKT used to authenticate the segment being sent. RNextKeyID announces the incoming MKT the sender is ready to use for future segments it receives; the peer uses that signal under the rollover rules to determine when to switch its own outgoing MKT and KeyID. The numbers are local coordination indexes, not secrets and not globally meaningful names. Because traffic keys are directional, each endpoint separately controls what it sends and what it is prepared to receive.

That distinction removes the need for a perfectly simultaneous cutover. An endpoint can install the next incoming MKT and advertise its readiness through RNextKeyID. Its peer observes the announcement and uses the RFC's rollover rules to determine when to move its own outgoing traffic to the corresponding KeyID; the signal does not require an immediate switch on the next segment. During the transition, the receiver can retain enough overlap to verify segments already in flight with the previous key. The wire now carries evidence of rollover progress instead of forcing operators to infer it solely from clocks and failed MAC checks.

The protocol does not become its own key-management system. TCP-AO neither negotiates master secrets nor decides who is authorized to provision them. MKTs arrive through static configuration or an external, out-of-band mechanism. The protocol coordinates the use of already authorized material; it does not manufacture that authority.

Nor could an existing TCP MD5 connection simply become TCP-AO in place. RFC 5925 assigns a different option and prohibits using TCP MD5 and TCP-AO on the same connection. TCP MD5 had no facility for changing the security algorithm after establishment. Migration therefore remained a connection-boundary decision even though later TCP-AO key rollover could occur inside the new connection.

RFC 5926 completes a narrower interoperability gap by defining required MAC and key-derivation profiles. It does not choose an operator's master key or rotation schedule. TCP-AO authenticates and integrity-protects segments and adds replay protections across long-lived and repeated connection instances, but it does not encrypt application data.

Primary sources