Summary

  • TCP-AO can coexist with a middlebox that leaves addresses and ports intact but rewrites TCP options only if both endpoints exclude all non-AO options from MAC coverage.
  • NAT or NAPT presents a harder boundary because TCP-AO treats both IP addresses and both TCP ports as part of the connection being authenticated; changing them cannot be solved by the option-coverage switch.

One packet, two kinds of intervention

Imagine the same authenticated TCP segment crossing two devices. The first leaves the endpoints’ addresses and ports alone but adjusts a timestamp option. The second translates an address or port before forwarding the segment. Both devices have changed bytes between the sender and receiver, yet RFC 5925 gives them different consequences.

The option-rewriting device can be accommodated, although not for free. TCP-AO has a Master Key Tuple flag that decides whether TCP options other than TCP-AO are included in the MAC calculation. If a path contains a device that changes an option, the endpoints can configure the protected connection to exclude those options from the calculation.

The address translator cannot use the same escape hatch. TCP-AO includes source and destination addresses and source and destination ports among the parameters that identify its protected connection. The RFC’s requirements evaluation is explicit: address coverage is not optional because IP addresses define a connection, and port coverage is not optional because ports define a connection.

The difference is easy to miss if every middlebox is treated as one category. TCP-AO did not decide that modification in transit was always impossible. It decided that some fields could be removed from protection through a named configuration choice, while the socket pair remained part of the identity that the MAC was proving.

The all-or-nothing option concession

The TCP-option flag is broader than an exception for one troublesome option. When enabled, all options other than TCP-AO are included in their transmitted order. When disabled, all of them are skipped. TCP-AO itself remains in the MAC input with its MAC field zeroed, preserving protection for its length and key identifiers.

That design lets a non-NAT middlebox modify options without causing every segment to fail authentication. It also makes the security cost visible. RFC 5925 warns that ignored options can then be altered in transit. A changed timestamp can reduce efficiency. A changed window-scale option can prevent correct operation. Those exposures apply to the connections configured to ignore options; the compatibility setting is not a general statement that the fields no longer matter.

There is therefore no precise configuration meaning “trust every TCP option except the one this device rewrites.” The available choice is to protect the class or exclude the class. A network design that depends on option manipulation must accept that larger boundary and document it as part of the connection’s security parameters.

Why translation changes more than a field

NAT and NAPT rewrite the address-and-port tuple. For ordinary TCP forwarding, a translator maintains enough mapping state to make the two endpoint views correspond. For TCP-AO, however, those endpoint views also feed the authentication calculation. A sender and receiver that calculate over different tuples do not merely disagree about a header detail; they authenticate different connection identities.

RFC 5925 consequently says TCP-AO cannot interoperate natively across NAT/NAPT. It sketches routes around that boundary rather than weakening the identity rule: encapsulate the protected segment in another transport, adapt a traversal mechanism, or use IPsec with NAT traversal instead. If translated values can be coordinated, a sender may calculate with the values seen by the receiver. If they cannot, the RFC says a tunnel is required.

Those statements do not establish one universal deployment recipe. The RFC does not standardize a TCP-AO NAT traversal protocol, measure current translator prevalence or say which tunnel an operator should choose. It defines why an uncoordinated translator is incompatible and leaves the surrounding architecture to other mechanisms.

A boundary drawn around connection identity

The historical choice was not simply “security versus middleboxes.” TCP-AO preserved a narrow distinction between mutable transport decoration and the endpoint tuple that gives a TCP connection its name. It allowed implementations to surrender authentication of non-AO options for selected connections. It did not allow them to surrender authentication of the addresses and ports while still claiming to protect the same connection.

That boundary also explains why apparent reachability is not enough evidence. A connection may pass through an option-rewriting device because option coverage was disabled. A TCP flow may pass through a translator because it is inside a tunnel whose outer headers absorb the translation. Neither observation proves that native TCP-AO authenticated post-translation headers end to end.

The reliable question is more specific: which bytes did each endpoint place in the MAC input, and which path element was allowed to change them? Once phrased that way, compatibility becomes an auditable property of the connection rather than a label attached to the middlebox.

Sources