TCP In-Band Single Packet Authentication (TCP-SPA)

Internet-facing TCP services are continuously probed by scanners, bots, and opportunistic attackers. Even when a service is properly hardened — strong passwords, TLS, privilege separation — the act of completing or even initiating a TCP handshake consumes server resources: socket allocation, kernel scheduler wakeups, TLS state machine initialization. At scale, or under a targeted SYN-flood, this cost becomes significant. The ideal property would be: a server never allocates any resource for a connection until it has cryptographic proof that the remote party holds a valid secret. In particular, the proof should arrive in the very first packet — the TCP SYN — so that an illegitimate SYN can be discarded at the lowest possible layer without ever touching the socket layer. Additional desiderata: The mechanism MUST NOT require any out-of-band communication channel, pre-flight packet, or extra round trip. Authentication and connection establishment must be a single atomic operation from the client's perspective. The mechanism MUST be transparent to the application. A standard connect(2) call, with no modification to the application, should automatically carry the authentication token. The mechanism MUST be NAT traversal-friendly. Many legitimate clients are behind one or more Network Address Translators. Any mechanism that binds authentication to the client's IP address creates a timing race when NAT rewrites the address and breaks address-bound tokens. The mechanism SHOULD allow key rotation without service interruption. The cryptographic overhead per SYN MUST be small enough to run inside a kernel data path (e.g., XDP or TC eBPF) without measurable latency impact. No existing IETF-standardized mechanism satisfies all five properties simultaneously. explains why.

defines a TCP option (kind 19) that carries an MD5 signature over the full TCP segment, the IP pseudo-header, and a shared secret. It was designed to protect BGP sessions between routers in a known topology. It fails the stated requirements for several reasons: NAT incompatibility (violates property c): The MAC input includes the source and destination IP addresses from the IP pseudo-header. A NAT device that rewrites the source address after the client has computed the signature will cause verification to fail at the server. There is no way to make work through NAT without defeating its security guarantee. Wrong threat model (different problem): is designed to prevent session hijacking on a long-lived BGP session between two known peers. It authenticates every segment, including data segments, and requires both peers to share the same key for the lifetime of the session. The problem addressed here is authenticating the initiating SYN from an arbitrary client before any session state is created. These are fundamentally different problems. MD5 is no longer considered secure: MD5 is cryptographically broken. was written specifically to replace .

replaces with a more modern construction. It supports multiple MAC algorithms, master keys and traffic keys (via a key derivation function defined in ), and key rotation. It still fails the stated requirements: NAT incompatibility (violates property c): Like its predecessor, TCP-AO includes the IP source and destination addresses in the MAC computation (Section 5.1.3 of , the "connection identifier"). A NAT that rewrites the source address breaks authentication. explicitly notes (Section 7) that NAT is incompatible with TCP-AO unless the NAT also updates the MAC, which is impossible without the shared key — defeating the purpose. Designed for peer authentication, not port authorization (different problem): TCP-AO secures an established TCP session between two long-lived peers (typically routers or servers) whose addresses and keys are known in advance. The problem addressed here is pre-authentication of arbitrary clients attempting to initiate a new connection, where the client population changes dynamically and may be behind NAT. Requires kernel support and configuration on both ends: TCP-AO must be configured via socket options before the connection is established. This requires application modification (violates property b) or OS-level transparent interception, which TCP-AO was not designed to support. In summary: TCP-AO is an excellent solution to the problem it was designed for (securing BGP and similar sessions between known peers). It is not a solution to pre-connection port authorization for arbitrary, NAT-traversing clients.

The most widely deployed SPA implementation is fwknop . Its protocol, while not an IETF standard, is the reference point for the SPA concept. The model is:

The client sends a specially crafted UDP packet (or ICMP packet, or similar) to the server. This packet contains a token: a MAC over the client's IP address, a timestamp, and a shared secret.
The server's SPA daemon (running in userspace, monitoring a raw socket or pcap) receives the packet, verifies the token, and temporarily installs a firewall rule to open the target port for the source IP of the packet.
The client then initiates a normal TCP connection.

This fails properties (a) and (c): Requires an extra round trip (violates property a): Steps 1-2 must complete before step 3 can succeed. The client needs a separate tool (not just connect(2)) to send the SPA packet. There is an unavoidable timing window between firewall-rule installation and the TCP SYN arriving. Source-IP binding is NAT-hostile (violates property c): The firewall rule opened in step 2 is keyed to the source IP seen in the SPA UDP packet. If the client is behind a NAT that uses a different source IP for UDP and TCP traffic (e.g., due to NAPT hairpinning or load balancing), the TCP SYN will arrive from a different address than the one whitelisted, and the connection will be refused. In practice, fwknop deployments work around this by accepting a timing window long enough to account for NAT, which widens the attack surface. Plaintext source IP in the token (additional concern): The token explicitly encodes the client's IP address. This means the authenticating data is not independent of NAT-rewritten fields.

Port knocking predates SPA. The client sends a sequence of packets to a sequence of closed ports; the server observes the sequence and opens a port. It is entirely unauthenticated in the cryptographic sense: any observer who captures the sequence can replay it. Some variants add encryption, but the fundamental fragility remains. Port knocking is not considered a serious candidate for the requirements in and is mentioned only for completeness.

TCP In-Band SPA embeds the authentication token inside the TCP SYN packet as a TCP option, using kind 253 (the first experimental kind reserved by ) with a registered ExID to avoid collisions with other experiments. The high-level model is:

A client that wants to connect to a protected server computes a SipHash-2-4 MAC over a small input struct that includes a coarse timestamp, a Key ID, and the TCP Initial Sequence Number (ISN) of the SYN.
The client writes this MAC, along with the Key ID, version, and timestamp, into a TCP option field of the outgoing SYN. This is done transparently inside the kernel (e.g., via a TC eBPF egress program), requiring no application modification.
The server, at the earliest possible processing point (e.g., XDP), reads the TCP option, looks up the corresponding key by Key ID, recomputes the expected MAC, and either passes or drops the SYN.

This satisfies all five properties from : Single step: the SYN itself carries the proof. No pre-flight packet is needed. Transparent: the TC eBPF hook injects the option before the packet leaves the NIC; no application change is required. NAT friendly: the MAC input does NOT include the source IP address. A NAT that rewrites the source IP does not invalidate the MAC. The TCP ISN, which is carried in the SYN and is not rewritten by standard NAT, ties the token to the specific connection. Key rotation: the Key ID field allows multiple keys to coexist. A client can use a new key immediately; the server keeps old keys until they expire. Lightweight: SipHash-2-4 over 14 bytes is a handful of XOR and rotate operations, well within the cycle budget of an XDP program.

The SPA option is carried as a TCP option with kind 253 (experimental, ) and the following layout:

Total option length: 20 octets. Fields:

Kind (1 octet): 253, as defined in .
Length (1 octet): 20 (total option length including Kind and Length octets).
ExID (2 octets): Experiment Identifier, network byte order. Disambiguates this experiment from other users of kind 253, per . A value of 0x0001 is used in the current implementation; a formal assignment from IANA would be sought for any Standards Track version of this specification.
Version (1 octet): Protocol version. MUST be 1 in this version of the specification.
Reserved (1 octet): MUST be zero on send; ignored on receive.
Key ID (2 octets): Selects which pre-shared key the sender used. Allows the receiver to maintain multiple keys simultaneously for rotation purposes. Network byte order.
Time Step (4 octets): A coarse, monotonically increasing counter used for replay prevention. The granularity is implementation-defined; a step of 30 seconds is RECOMMENDED. Network byte order.
Authentication Tag (8 octets): The truncated SipHash-2-4 output as described in .

The Authentication Tag is computed as follows:

where k0 and k1 are the two 64-bit halves of the 128-bit pre-shared key identified by Key ID. The TCP ISN (tcp_seq) is included so that the tag is cryptographically bound to this specific SYN and cannot be replayed in a different connection with a different ISN. The source IP address is deliberately excluded from the hash input. Including it would break authentication through NAT (see ). SipHash-2-4 is defined in . It produces a 64-bit output. All 64 bits are used as the Authentication Tag.

The client MUST:

Select a Key ID and retrieve the corresponding 128-bit pre-shared key.
Obtain a current Time Step value.
Generate a normal TCP SYN, allowing the TCP stack to select an ISN.
Intercept the outgoing SYN before transmission (e.g., at the TC egress hook).
Populate the spa_input struct with the chosen ExID, version, Key ID, Time Step, and the TCP ISN from the SYN header.
Compute the Authentication Tag.
Prepend the tcp_opt_spa option to the existing TCP option list, shifting other options forward.
Update tcphdr.doff to reflect the added option bytes.
Recompute the TCP checksum and IP total length.

The client SHOULD check that the resulting TCP header does not exceed 60 octets (the maximum allowed by the 4-bit doff field). If the option list is already full, the client MAY omit less-critical options (e.g., TCP timestamp) to make room, or MAY fail open (send without the SPA option) if configured to allow it.

The server MUST:

At the earliest possible processing point (XDP is RECOMMENDED), inspect all incoming TCP packets.
For each TCP SYN destined to a protected (IP, port) pair:
1. Search the TCP option list for an option with kind 253 and the expected ExID. If absent, DROP the SYN.
2. Extract Key ID from the option.
3. Look up the pre-shared key by (destination, Key ID). If not found, DROP the SYN.
4. Populate spa_input from the option fields and the SYN's ISN.
5. Compute the expected tag and compare it to the tag in the option. If they differ, DROP the SYN.
6. Validate the Time Step: it MUST be within a configurable acceptance window of the server's current time (e.g., +/- 1 step). If outside the window, DROP the SYN (replay or excessively stale packet).
7. Pass the SYN to the normal TCP stack (XDP_PASS or equivalent).
For non-SYN packets (including ACK, data, FIN) destined to protected addresses, the server SHOULD pass them without re-checking the SPA option. The SPA option is not present in non-SYN segments.
For TCP SYN+ACK (the server's handshake reply), no SPA option is required.

The Time Step field provides coarse replay prevention. A captured SYN with a valid SPA option can be replayed during the acceptance window. To reduce this risk:

The acceptance window SHOULD be as small as clock skew and network delay allow (one step, e.g., 30 seconds, is RECOMMENDED).
The TCP ISN binds the tag to a specific SYN. An attacker who replays a captured SYN will be replaying an exact packet including the ISN; the server's TCP stack will likely reject the duplicate SYN through standard ISN validation, even if the SPA tag passes.
Implementations MAY maintain a short-lived cache of recently seen (Key ID, Time Step, ISN) tuples to detect and reject exact duplicates within the acceptance window.

This document does not define a key exchange protocol. Pre-shared keys MUST be distributed through an out-of-band secure channel. The Key ID field (16 bits) allows up to 65535 distinct keys per (destination, server) pair. This is sufficient for key rotation: a new key is distributed before the old one expires, and the server accepts both Key IDs during the overlap period.

Standard (port-preserving) NAPT rewrites the source IP address and possibly the source TCP port. This implementation deliberately excludes both from the MAC computation, so NAPT does not break authentication. The TCP ISN is not rewritten by standard NAT. If a middlebox were to rewrite the ISN (ISN randomization on NAT, which some NAT implementations do), the MAC would fail. This is a known limitation. Implementations SHOULD document this. The SPA TCP option itself is not rewritten by any known NAT implementation; TCP options other than the Timestamp option () are generally passed through unmodified. However, some deep-packet-inspection (DPI) middleboxes may strip unknown TCP options. In environments where this is a concern, the SPA option MUST be placed as the last option before EOL so that stripping it does not corrupt other options.

Authentication strength: SipHash-2-4 with a 128-bit key produces a 64-bit tag. An attacker who does not know the key has a 2^-64 probability of forging a valid tag for a given (Key ID, Time Step, ISN) tuple. At line rate this is a negligible risk; at 1 Mpps the expected forgery time exceeds 584,000 years. SipHash was designed for exactly this use case (short-input PRF) and has withstood public cryptanalysis since 2012 . Key secrecy: The security of this mechanism depends entirely on the secrecy of the pre-shared key. Keys MUST be generated with a cryptographically secure random number generator and distributed via a confidential, integrity-protected channel. Denial-of-service: The server-side verification runs at XDP, before any socket or kernel TCP state is allocated. Illegitimate SYNs are dropped at the cost of a map lookup and a SipHash computation — both are O(1) and extremely fast. This mechanism is therefore more DoS-resistant than approaches that require socket allocation before authentication. Option stripping: An on-path attacker who strips the SPA option from a SYN would cause the connection to be dropped by the server (which expects the option on protected destinations). This is a denial-of- service capability, not an authentication bypass. Replay: see . Key ID enumeration: An attacker can observe which Key IDs are used (the field is not encrypted) and attempt brute-force against a specific Key ID. The 64-bit tag size makes this computationally infeasible within any realistic time window.

This document uses TCP option kind 253, which is permanently allocated to IANA for experimental use by . defines an ExID sub-registry; the ExID value 0x0001 used in the current prototype is a placeholder. A publication-ready version of this specification would request a formal ExID assignment from IANA. No other IANA actions are required.