| Internet-Draft | TCP In-Band SPA | February 2026 |
| Asadi | Expires 27 August 2026 | [Page] |
This document describes a mechanism called TCP In-Band Single Packet Authentication (TCP-SPA). A client that wishes to open a TCP connection to a protected server embeds a compact Message Authentication Code (MAC) inside the TCP SYN packet itself, carried as an experimental TCP option (kind 253, per [RFC6994]). The server verifies the MAC at the earliest possible point in the network stack — before a socket is allocated or the TCP handshake proceeds — and drops the SYN if verification fails.¶
This approach differs from existing Single Packet Authentication (SPA) systems in that no out-of-band authentication packet is required: authentication and connection establishment are a single atomic step.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 27 August 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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. Section 2 explains why.¶
[RFC2385] 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 [RFC2385] work through NAT without defeating its security guarantee.¶
Wrong threat model (different problem): [RFC2385] 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. [RFC5925] was written specifically to replace [RFC2385].¶
[RFC5925] replaces [RFC2385] with a more modern construction. It supports multiple MAC algorithms, master keys and traffic keys (via a key derivation function defined in [RFC5926]), 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 [RFC5925], the "connection identifier"). A NAT that rewrites the source address breaks authentication. [RFC5925] 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 [FWKNOP]. Its protocol, while not an IETF standard, is the reference point for the SPA concept. The model is:¶
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 Section 1 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 [RFC6994]) with a registered ExID to avoid collisions with other experiments.¶
The high-level model is:¶
This satisfies all five properties from Section 1:¶
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, [RFC6994]) and the following layout:¶
0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kind (253) | Length (20) | ExID (2 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version (1B) | Reserved (1B) | Key ID (2 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time Step (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Tag (8 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Total option length: 20 octets.¶
Fields:¶
The Authentication Tag is computed as follows:¶
struct spa_input {
uint16_t exid; /* ExID, network byte order */
uint16_t ver; /* Version */
uint16_t key_id; /* Key ID, network byte order */
uint32_t time_step; /* Time Step, network byte order */
uint32_t tcp_seq; /* TCP ISN from the SYN, net order */
};
tag = SipHash-2-4(k0, k1, spa_input)
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 Section 10).¶
SipHash-2-4 is defined in [SIPHASH]. It produces a 64-bit output. All 64 bits are used as the Authentication Tag.¶
The client MUST:¶
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:¶
For each TCP SYN destined to a protected (IP, port) pair:¶
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:¶
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 ([RFC7323]) 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 [SIPHASH].¶
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 Section 8.¶
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 [RFC6994]. [RFC6994] 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.¶