The TCP Authentication Option
obsoletes
- rfc-2385 — Protection of BGP Sessions via the TCP MD5 Signature Option
Extracted elements (30)
MAC algorithm specifications are placed in a separate document (RFC 5926) rather than in TCP-AO itself, to allow algorithm requirements to be updated independently of the protocol specification as the cryptographic landscape evolves.
TCP-AO deliberately does not provide in-band cryptographic key negotiation because TCP SYN segments lack sufficient remaining option space to handle such a negotiation (only ~25 bytes remain after common options, and TCP-AO itself consumes 16). Out-of-band MKT management is assumed instead.
TCP-AO uses a different option Kind (29) than TCP MD5 (19) to allow both to coexist for different connections simultaneously (supporting legacy interoperability) while ensuring they are never permitted on the same connection. The explicit Kind avoids any ambiguity about which mechanism protects a given segment.
TCP-AO cannot interoperate natively across NAT/NAPT devices because the IP addresses and/or ports included in the MAC computation are modified in transit. Traversal may require encapsulation (e.g., in UDP) analogous to IPsec NAT traversal.
TCP-AO may interact with non-NAT middleboxes that modify TCP options. When such middleboxes are present, TCP-AO must be configured to exclude TCP options from the MAC calculation on affected connections, which reduces protection since option modifications would go undetected.
TCP MD5-protected connections cannot be migrated to TCP-AO because TCP MD5 does not support changes to a connection's security algorithm once established. TCP-AO and TCP MD5 use different option Kind values (29 vs. 19) and MUST NOT be used simultaneously on the same connection.
A single TCP segment MUST NOT have more than one TCP-AO in its options sequence. When multiple TCP-AOs appear, TCP MUST discard the segment.
A TCP-AO implementation MUST allow configuration of behavior for segments with TCP-AO that do not match any MKT; the initial default SHOULD be to silently accept such connections. Silent discard events SHOULD be signaled as warnings; both warnings MUST be accessible via the STATUS interface.
A TCP-AO implementation MUST default to ignoring incoming ICMPv4 Type 3 Codes 2–4 (protocol/port unreachable, fragmentation needed) and ICMPv6 Type 1 Codes 1 and 4 intended for synchronized TCP connections that match MKTs, to prevent ICMP-based connection teardown attacks.
All TCP segments MUST be checked against the set of MKTs for matching TCP connection identifiers. TCP segments whose TCP-AO does not validate MUST be silently discarded.
An endpoint MUST NOT use TCP-AO for the same connection in which TCP MD5 is used. When both options appear on a segment, TCP MUST silently discard that segment.
Components of an MKT MUST NOT change during a connection. The set of MKTs MAY change during a connection (new MKTs can be installed and a connection can switch which MKT it uses).
Connections using TCP-AO SHOULD also use TCP keepalives to ensure that connections whose keys are lost (e.g., after a reboot) are terminated after a finite time. BGP connections SHOULD require support for graceful restart when using TCP-AO.
MKT IDs MUST support any value 0–255 inclusive with no reserved values, and IDs MUST NOT be assumed to be randomly assigned. The IDs of MKTs MUST NOT overlap where their TCP connection identifiers overlap.
TCP-AO MUST be the first TCP option processed on incoming segments, because its MAC calculation may include other option values that could change during option processing; this also protects other TCP options from spoofed segments.
TCP-AO MUST be the last TCP option processed on outgoing segments, because its MAC calculation may include the values of other TCP options.
TCP-AO SYN segments (SYN set, ACK not set) MUST use a destination ISN of zero whether sent or received; all other segments use the known ISN pair for traffic key derivation.
TCP implementations that support TCP MD5 MUST support TCP-AO. A system supporting both MUST use TCP-AO unless not supported by its peer, at which point it MAY use TCP MD5. A TCP implementation MUST NOT use both TCP-AO and TCP MD5 for the same connection.
The TCP-AO Length field MUST be greater than or equal to 4; when less than 4, TCP MUST discard the segment. The Length MUST also be consistent with the TCP header length; when invalid, TCP MUST discard the segment.
A Master Key Tuple (MKT) describes TCP-AO properties for one or more connections. It includes: TCP connection identifier (socket pair, possibly wildcarded), a TCP option flag controlling whether options other than TCP-AO are included in MAC computation, SendID and RecvID (each 0–255), a master key byte sequence, a Key Derivation Function (KDF), and a MAC algorithm.
MKT key change coordination uses two per-connection pointers: current_key (the MKT used to authenticate outgoing segments, its SendID inserted as TCP-AO KeyID) and rnext_key (the preferred incoming MKT, its RecvID inserted as TCP-AO RNextKeyID). current_key is updated by TCP-AO on receipt; rnext_key is updated only by user/management intervention.
Sequence Number Extensions (SNEs) extend TCP's 32-bit sequence number to 64 bits to prevent replay attacks within long-lived connections. Each connection maintains SND.SNE and RCV.SNE, both initialized to zero. The SNE is incremented by inference when the TCP sequence number wraps, using a flag-based algorithm.
The MAC input data sequence is: (1) the 32-bit Sequence Number Extension (SNE), (2) the IP pseudoheader, (3) the TCP header with checksum and TCP-AO MAC field zeroed (options included or excluded per MKT TCP option flag), and (4) the TCP data payload.
Traffic keys are derived per-connection and are directional. A single MKT yields up to four traffic keys: Send_SYN_traffic_key, Receive_SYN_traffic_key, Send_other_traffic_key, and Receive_other_traffic_key. The KDF context includes source/destination IP addresses, ports, and both ISNs (destination ISN set to zero for SYN segments).
TCP-AO uses TCP option Kind value 29, assigned by IANA from the TCP Option Kind Numbers registry. This is distinct from TCP MD5's Kind value of 19.
After a reboot, a TCP-AO endpoint has lost its traffic keys, so TCP's RST mechanism cannot clear stale state on the peer. BGP connections without graceful restart SHOULD save traffic keys in persistent storage across reboots to mitigate this; otherwise keepalives eventually clear the state.
TCP-AO prevents replay attacks across connection instances by including both endpoint ISNs in the traffic key derivation context, ensuring that each connection instance generates unique traffic keys even when the same MKT and socket pair are reused. The 32-bit ISN space makes reuse unlikely except under reboot.
Per-connection TCP-AO maintains current_key and rnext_key. On outgoing SYN: find matching MKT; on receipt of a segment whose RNextKeyID matches an available MKT's SendID and differs from current_key's SendID, current_key transitions to the RNextKeyID MKT. 'Backing up' to a previously used MKT is permitted to handle reordered segments.
TCP-AO uses Kind=29, a 1-byte Length (minimum 4), a 1-byte KeyID identifying the MKT used to generate the MAC, a 1-byte RNextKeyID indicating the preferred incoming MKT, and a variable-length MAC field. Typical MACs are 96–128 bits (12–16 bytes).
The KDF context for traffic key derivation includes: source address, destination address, source port, destination port, source ISN (32 bits), and destination ISN (32 bits); for SYN segments the destination ISN is zero. IPv4 and IPv6 formats differ in address width.