Summary

  • TCP-AO's KeyID identifies the Master Key Tuple used for the segment being sent. RNextKeyID advertises which incoming MKT the sender is ready to use. Neither field carries a secret, acknowledges delivery or proves that the peer has changed its outgoing key.
  • Rollover state is directional. Each endpoint has one current outgoing key and one preferred incoming key, while the key-management mechanism remains outside TCP-AO. A single “active key” dashboard field erases the state operators need to judge readiness.
  • The old key may be retired only after both directions visibly transmit and verify the new epoch, BGP remains stable, reconnect behavior is tested and the rollback state is preserved. Matching configuration and a green session are evidence inputs, not completion authority.

The failed maintenance begins with a reasonable plan. A security team generates a replacement secret and sends it through an approved out-of-band channel. Router A loads an MKT with SendID 42 and RecvID 42. Router B loads the same secret but, under its local convention, assigns SendID 43 and RecvID 43. Both configurations contain the new bytes. Both change tickets say “key 42.” Only the wire protocol sees the disagreement that matters.

Router A makes the new MKT its preferred incoming key. Its next segments still use old KeyID 17 for their MACs, but advertise RNextKeyID 42. Router B receives and successfully authenticates those segments under the old MKT. It then asks a local question: do I have a ready MKT for this socket pair whose SendID matches 42? It does not. RFC 5925 therefore gives it no switch to perform. No rejection, negotiation or emergency message is required. This failed request concerns B-to-A traffic: B continues sending with 17. If B later advertises RNextKeyID=43, A likewise cannot move A-to-B unless it has a ready outgoing MKT with SendID 43.

The monitoring layer sees 42 and reports readiness. The protocol sees an unresolved local label and does nothing. When the old MKT is removed, the distinction becomes an outage.

Two identifiers describe two different directions

TCP-AO appears compact on the wire. TCP option Kind 29 contains a length, a one-byte KeyID, a one-byte RNextKeyID and a Message Authentication Code. That brevity is deliberate. The option coordinates the use of keys that already exist at the endpoints; it is not a key-distribution protocol.

KeyID describes the present segment. It names the Master Key Tuple used to derive the traffic key that produced the MAC. On transmission, its value comes from the active MKT's SendID. On receipt, the same byte is matched to an MKT's RecvID together with the TCP socket pair. The names are local and directional: one endpoint's SendID must meet the other endpoint's RecvID for that direction.

RNextKeyID points the other way. The sender uses it to say which MKT it is ready and prefers to use when authenticating future segments it receives. Its value comes from the preferred incoming MKT's RecvID. The receiving endpoint compares that request with its own outgoing possibilities. If a matching MKT is ready, it can make that MKT current for subsequent transmission.

Neither byte has cryptographic strength. Values from zero through 255 are merely labels. They need not be random, sequential or globally unique. The two directions may use different numbers, and numerical equality carries no special meaning. Seeing 42 on both screens is no stronger than seeing two drawers marked 42. The contents, scope and direction of the drawers still have to match.

This is why language matters. RNextKeyID does not mean “the next key that both sides have.” It means “the receive identifier I currently prefer, if you possess a compatible outgoing MKT.” The field is a request conditioned on local state, not a receipt.

The MKT is the authority behind the label

An MKT binds more than secret bytes: local and remote addresses and ports, SendID and RecvID, master key, derivation and MAC algorithms, and the policy for authenticating other TCP options. An incoming segment must resolve to exactly one MKT through its socket pair and KeyID. The same secret attached to the wrong address family, routing instance, direction, identifier, algorithm or option policy is not an operational match.

The inventory must therefore retain socket scope, SendID, RecvID, algorithm, MAC length, option policy, lifetime, current or receive-next role and connection epoch. “Peer 42 has the right secret” is too weak to reconstruct the decision.

A master key does not sign packets directly

TCP-AO derives unidirectional traffic keys from the MKT, socket pair and connection context, including both Initial Sequence Numbers after establishment. Sequence Number Extensions preserve replay protection across 32-bit sequence wrap. The same master key can therefore yield different traffic keys by peer, direction and epoch; a reconnect changes the authenticated context. A matching secret fingerprint cannot prove that identifiers, scope, algorithms, option policy or connection state agree.

The rollover is two coupled state machines

For each non-idle TCP-AO connection, RFC 5925 defines at most one current_key and at most one rnext_key. current_key is the MKT used for outgoing segments. rnext_key is the MKT preferred for incoming segments. Each endpoint maintains both pointers, creating four material pieces of state across one BGP session.

Imagine A and B begin with epoch 17 in both directions. The safe change can be described without pretending it is atomic.

First, install the replacement MKT on both endpoints while 17 remains valid. Confirm the effective socket state, not only the saved configuration. At this point neither side needs to transmit under the new MKT.

Second, A may make the new MKT its rnext_key. A continues sending with KeyID 17 but advertises the new RecvID. B authenticates the old-key segment, resolves the request against its local MKT set and, if a matching outgoing MKT exists, changes its current_key. B's next authenticated segment visibly carries the new KeyID.

Third, B advertises its preferred incoming MKT and A independently switches its outgoing key. Only then can both directions be in the new epoch. The order can vary, and one direction may change before the other. That partial state is supported behavior, not necessarily an error.

Fourth, operators hold an overlap interval and prove that no live or reconnect path still uses 17. Then key management—not TCP-AO—expires or removes the old MKT.

A product interface that reports one session-level “current key” cannot represent this sequence. At minimum it must show A-to-B active KeyID, A's advertised RNextKeyID, B-to-A active KeyID, B's advertised RNextKeyID, and the local MKT that each value resolved to. Readiness is a matrix.

Silence is a valid response to an impossible request

The dangerous case is not always a loud MAC failure. A received RNextKeyID can be authenticated perfectly under the old key while asking for an MKT that the receiver does not have. RFC 5925 says that when no matching MKT is available, no action is required.

That silence preserves the existing connection. It avoids letting a remote label force an endpoint into an unconfigured key. The peer may advertise a preference, but the local implementation changes only when its own verifiable state makes the change possible.

Operations often misread this safety property as a coordination failure. They wait for an acknowledgement the protocol never defined, or they infer success from the mere continued health of BGP. Both are category errors. Continuity under key 17 says nothing about readiness for 42.

The proof must observe the actual outgoing KeyID after the request. If it does not change, inspect the local MKT database and counters. An unknown-key or RNext-request trace can explain the gap. If the platform provides no such signal, packet capture plus exact key readback is still stronger than the dashboard's aggregate label.

Provisioning sits outside the protocol

RFC 5925 assumes an out-of-band or manual mechanism supplies and removes MKTs. It does not define the human authority, vault, approval path or recovery process. The wire coordinates labels only after compatible local state exists; it never makes secret distribution true.

RFC 6518 and RFC 7211 supply the lifecycle discipline: bounded lifetimes, reception before transmission, expiry notice, key-table consistency and time awareness. The control record must identify generation and custody, each endpoint's effective scope and IDs, receive and send validity, old-key expiry and rollback authority. Operators need direct access to that state because a remote dashboard cannot see both directions.

Retirement is the irreversible edge

Installing a new MKT adds dormant secret exposure; activating it in one direction leaves partial dependence; deleting the old MKT removes fallback. Permanent overlap is also unsafe because a compromised credential remains accepted. Retirement needs a bounded interval covering propagation, retransmission, telemetry lag, reconnect testing and rollback.

During that interval, prove both directions send the new KeyID, good-MAC counters rise, old-KeyID traffic reaches zero, BGP and routes remain stable, and a fresh connection selects the new state. Then remove the old MKT in a narrow canary while watching authentication, TCP, BGP and route evidence. Linux can appoint replacement current and receive-next keys during forced deletion, but warns that removing a key still requested by the peer may break the connection; force is not bilateral proof.

A valid MAC does not authorize a route

TCP-AO authenticates a TCP segment within a configured key context; it does not authorize the peer operator or a prefix. RFC 4272 and RFC 7454 keep transport protection separate from GTSM, control-plane filtering, prefix and AS-path policy and max-prefix limits. A bad MAC should fail before BGP parsing, while a correctly authenticated but unauthorized route should fail import policy.

Audit segment authenticity, session continuity, message validity, route authority and forwarding outcome separately. A cryptographically correct new key can accompany a bad operational change, and a stable authenticated peer can still advertise an unacceptable route.

The bilateral canary must prove four transitions

Begin with an exact session identity: routing instance, local and remote addresses, TCP ports, BGP peer, connection epoch and route baseline. Enumerate all MKTs matching that socket pair on both endpoints. Record SendID, RecvID, algorithm, MAC length, option policy, receive/send validity and current/rnext role. Compare secret material through a protected fingerprint or test; never place the secret itself in tickets or captures.

The first transition is distribution. Both endpoints must show the new MKT effective for reception while old traffic still verifies. Saved configuration is insufficient if a daemon reload, key-chain activation or socket binding has not occurred.

The second transition is B-to-A transmission. A advertises its new receive preference. Capture B's next outgoing KeyID and prove A's good-MAC counter rises for the matching new MKT. A continued old KeyID is not automatically failure, but it means the transition is incomplete and must be explained.

The third transition is A-to-B transmission. Repeat independently in the reverse direction. Do not infer it from the first. At this point exercise KEEPALIVEs and a controlled route refresh or bounded UPDATE, comparing Adj-RIB counts and selected routes with the baseline.

The fourth transition is retirement. After the overlap and reconnect test, prove zero old-KeyID dependence, remove the old MKT in the canary scope and repeat transport and route checks. Retain packet timestamps, key readbacks, counters and BGP evidence under one epoch identifier.

Rollback restores a complete compatible state on both endpoints. It may return both directions to 17, keep the new MKT installed but inactive, or appoint another approved epoch. What matters is that the plan names current and receive-next pointers, IDs, scope, algorithms, lifetimes and secret source explicitly.

The narrow protocol signal is a virtue. TCP-AO lets two independently managed systems coordinate which pre-existing key context to use without turning the wire into a secret-distribution authority. Trouble begins when an operator asks the signal to prove more than it contains.

The next key is not real because a ticket announced it, a dashboard named it or one byte carried its label. It becomes operationally authoritative when both endpoints can resolve the label, both directions produce and verify the expected MACs, BGP survives the new connection context, the old dependency reaches zero and a reversible record remains. That is the difference between declaring a key epoch and running one.