Your front-ends answer with SYN cookies, but a botnet completes every handshake — what does the defence still stop?

## Naming the scope precisely Stateless admission answers exactly one question: should I spend memory on a peer that has not yet shown it can receive what I send? Its answer is no, and it enforces that by putting everything it would have remembered into the reply and verifying it when the peer hands it back. The whole defensive value lives in the fact that a sender with a forged source address never receives the reply and therefore can never return it. Remove the forgery and the value goes with it. A device in a botnet using its own address receives the reply, returns it, and the server does what it would do for any customer: builds a socket, hands it to the application, runs a TLS handshake if there is one, parses a request, and does whatever that request costs behind it. Admission was never the contested resource in this attack, so a defence that operates only at admission contributes nothing. ## What actually changed It would be wrong to conclude the control is useless. Two things really did change, and a senior answer names both. First, an entire cheap attack class is gone. A flood of forged SYNs is the least expensive way to deny a service, because the sender needs no return path and commits nothing per packet. Removing that for the price of some degraded connections is a good trade almost everywhere. Second, the adversary's economics moved. To get past admission they must use addresses that route back to them, which means their sources are real, enumerable and blockable, and the traffic becomes attributable in a way a forged flood never is. They must also hold state of their own for every connection they keep open, so their cost per unit of pressure on you rose. This is the useful sentence to say in an interview: the control did not stop the flood, it forced the flood into a form you can see and the adversary can afford less of. ## The new bill There is also a cost that appears only while the mechanism is engaged. Verification is arithmetic performed per candidate packet rather than a lookup, so an attacker sending forged acknowledgements that will never verify still makes the host compute the check on each one. You have converted an exhaustion problem in a bounded, fixed-size queue into a load problem on a resource that degrades gradually. That is almost always the better failure mode — a queue that fills refuses everyone abruptly, while CPU pressure slows things — but it is a conversion, not an elimination, and someone will eventually ask you what the ceiling is. ## Writing the caveat The chair this question is really asked from is the one where you have to say, in writing, what the control does not do, because someone is about to record the front-ends as protected. A caveat that survives contact with a review says three things: - **Scope in terms of the adversary.** It defends against floods from senders that do not complete the handshake. It has no effect on floods from hosts that do complete it, on request-level exhaustion behind admission, or on saturation of the link in front of it. - **The residual, with an owner.** Everything past admission — socket capacity, worker pools, the cost of the requests themselves, upstream bandwidth — is unaddressed here and needs its own answer, its own budget and a named person who accepts it until it has one. - **A falsification test.** State what would disprove a claim of protection, and then run it: a load generator that completes handshakes and issues real requests. If the front-ends fold under that, the word protected does not belong in the document. This matters because the tempting evidence — the graphs stayed green through the last flood — only shows that the last flood was the kind this control happens to answer. ## The thing candidates get backwards The common failure is to treat a control that works against one variant as coverage for the class, and it is worth being explicit about the direction of the claim. The absence of an outage during a flood proves that this flood was survivable, not that the estate is defended. And the reverse also holds: because the mechanism only engages on overflow, a quiet period proves nothing either way about whether it would engage in time. Both claims have to be earned by a test you ran, not inferred from a period in which nothing bad happened.