State You Never Allocate

## The allocation this removes A TCP server cannot complete a connection in one packet. It receives a SYN, replies with a SYN-ACK, and then has to wait — possibly for seconds — for the client's ACK. In the ordinary implementation the server writes down a half-open record for that pending connection: the peer's address and port, the sequence numbers, the options the client asked for, and a retransmission timer so it can resend the SYN-ACK if the reply is lost. That record occupies a slot in a bounded queue of half-completed handshakes, and it is held until the handshake finishes or the timer gives up. That bounded queue is the resource the attack aims at. Because a sender that forges its source address never has to receive anything, a flood of SYNs from addresses that do not answer costs the sender one small packet each while costing the server a record and a timer that live for tens of seconds. The queue fills, and from then on a genuine client's SYN arrives at a server with nowhere to put it. ## What engages, and what the reply has to do Stateless admission is the refusal to make that allocation. When the queue of half-completed handshakes overflows, the server stops writing records and instead answers the SYN with a reply it can verify later without having stored anything. Everything it will need at the third packet has to be carried in the reply itself and returned by the peer; when an ACK arrives that matches no known connection, the server recomputes the expected value from the connection's identifying fields and a coarse clock and compares. If it matches, the socket is built at that moment. If it does not, the packet is discarded. Nothing is ever looked up, because nothing was ever written. The consequence for the attack is direct. A forged source never sees the reply and so can never return it, and the server has committed no memory on its behalf. The flood's cost to the server collapses to the packet it had to process anyway. Note that this is a threshold behaviour, not a mode someone turns on for the day: below the overflow point the server negotiates normally, so most connections in the estate are untouched — which is exactly why the harm it does is hard to notice afterwards. ## What holding nothing costs Four things follow from having no record, and a candidate who only knows the benefit will miss all four. **No retransmission.** A record carried the timer. Without it, a SYN-ACK lost on a lossy path is simply gone; the server will never resend it, and the client must wait out its own retransmission timeout — often a second or more — and resend its SYN. On a mobile path during a flood, that is added connect latency that shows up as slowness, not as failure. **No memory of what the client offered.** The options a client proposes in its SYN are negotiated once, and the server has to remember the client's side of that negotiation to honour it later. With no record, the reply can carry only a very small amount back, so several negotiated features are dropped and the connection is admitted with degraded parameters that persist for its whole life. **A limited validity window.** Because the check depends on a coarse clock, a returning ACK is only accepted for a bounded period; a peer that answers long afterwards is not admitted. **A new cost, in a different currency.** Verification is per-packet arithmetic rather than a memory lookup. An attacker who floods ACK packets that will never verify still makes the host do that work. This is usually an excellent trade — a bounded queue is the thing that failed, and CPU is elastic where a fixed queue is not — but it is a trade, not a free win. ## What it does not claim The control has exactly one job: do not commit resources to a client that has not proved it can receive. A peer that does complete the exchange is admitted like any other client and consumes a real socket and real work behind it. Anyone recording the host as protected against connection floods on the strength of this has confused the half-open case with the general one. ## How you would know it happened Nothing fails, so nothing alerts. The evidence is a record of when the degraded path engaged, and the fact that connections established during those windows carry different parameters from ones established either side of them. If you are not capturing that, the only report you will ever get is a customer saying the service feels slower, weeks later.