Summary

  • A TCP Fast Open Cookie is server-generated evidence tied to the client's source-IP context. It is not a user credential or an application request identifier.
  • Valid TFO can let SYN data reach the application before the three-way handshake completes, while RFC 7413 explicitly preserves a rare duplicate-delivery risk for that early data.
  • A durable execution record must join transport sequence evidence to authenticated principal, request identity, deduplication, commit state and response outcome.

The fast path ended before the business answer

Consider a client with a cached Fast Open Cookie sending a reservation or configuration change in the opening SYN. The server validates the cookie, buffers the data and notifies the application. It also acknowledges the SYN and data. Before the client receives a useful response, the exchange fails. A fallback or later retry sends the logical request again.

Nothing in the cookie tells the application whether the second request duplicates the first. Nothing in the TCP acknowledgment says a database commit finished, an authorization rule passed or the response reached the client. The transport can have behaved exactly as designed while the business outcome remains uncertain.

That is the evidence gap. TFO compresses connection setup and data exchange; it does not merge transport identity, user identity and transaction identity into one proof.

What the Fast Open Cookie authenticates

RFC 7413 describes the cookie as an opaque value generated by the server. Its intended construction is a message-authentication tag that authenticates the source IP address of the client's SYN and cannot be fabricated by the client. The server may encode other implementation-specific information, accept more than one valid cookie for a client and expire cookies at any time.

This scope is useful against spoofed-address resource and amplification attacks. It is not an application login. Source addresses can be shared, translated or reassigned, and the RFC itself discusses risks around reassigned addresses. A valid cookie establishes that the server accepts the presented source-IP context for Fast Open under its current key and policy. It does not establish which human or workload authored the payload.

TFO is not enabled implicitly for every service. RFC 7413 requires an application to request it explicitly on a per-service-port basis and to evaluate the changed semantics. A listener can disable Fast Open or stop admitting new Fast Open requests when its pending-request limit is reached. Cookie validity, listener admission and application authorization are separate decisions.

How SYN data is admitted or deferred

With a valid cookie and an enabled listener below its limit, the server buffers SYN data, notifies the application, marks the connection FastOpened and sends a SYN-ACK acknowledging the SYN and data. If the cookie is invalid or Fast Open is unavailable, the server drops the SYN data and acknowledges only the SYN. The client then retransmits unacknowledged data in the ACK after the handshake.

Middleboxes or servers can also drop SYN packets carrying payload or unfamiliar options. RFC 7413 recommends timeout fallback using an ordinary SYN carrying neither data nor a Fast Open option. The client may cache the server's MSS because early data is sent before the current SYN-ACK announces it; sending too much can require retransmission.

These branches mean “the client called Fast Open” is not one outcome. The early bytes may have reached the application, may have been discarded before delivery, or may be retransmitted through ordinary TCP. A useful record must say which branch occurred.

A TCP ACK ends at the transport boundary

RFC 9293 defines cumulative acknowledgment in TCP sequence space. An acknowledgment number says that octets up to that sequence point were received by the TCP peer. That is strong transport evidence and supports retransmission control.

It is not an application commit message. A TCP endpoint can accept bytes into its receive path before application code validates credentials, checks a request key, completes storage or produces a durable result. The SYN-ACK acknowledgment of TFO data therefore cannot substitute for application-level idempotency or an authenticated result.

Replay is an application design condition

RFC 7413 warns that data in a SYN can be delivered more than once to the remote application in rare circumstances. The risk is limited to the early SYN data, not all subsequent data, but it changes which operations are suitable. Applications must tolerate that boundary; idempotent transactions are the natural fit.

Idempotent here cannot mean “we usually retry safely.” The application needs a stable request identifier, a defined deduplication scope, atomic handling of first and repeated arrivals, and a retrievable outcome. A non-idempotent mutation placed in early data without those controls turns a latency optimization into an ambiguity amplifier.

Sources