A front door records every challenge token it issues; under a spoofed flood, why does that fail and what does the fix cost?

## The trap A challenge is worth building only if an unproven client is cheap. The obvious implementation is not: generate a random token, store it in a map keyed by token or by client, and look it up when the client returns. Under a spoofed flood every single packet mints an entry, none of them ever return, and the entries sit there until they expire. You have not removed the per-client allocation, you have moved it from the connection queue into a hash map — and the hash map is usually the softer target, because it is in your application's heap rather than in a tuned kernel structure with its own overflow behaviour. The attacker does not have to change a thing. ## The self-validating token The construction that actually works is a token the front door can verify by recomputing rather than remembering: token = MAC(server_key, source_address | coarse_timestamp | scope) The client is handed the token and, on its next attempt, sends it back. The front door recomputes the same value over the source address of the packet that carried it and compares. If they match, the address was reachable recently and the front door may now allocate. If they do not, it costs a hash to say no. The two properties that matter are that verification requires **no lookup** (so there is nothing to fill) and that the token is **unforgeable** (so an attacker cannot mint their own and skip the trip). A random token you store fails the first test; a random token you do not store fails the second, because you cannot tell your token from a made-up one. ## The bill **CPU per verification.** A keyed hash is cheap but not zero, and an attacker can send garbage tokens purely to make you compute. It is a good trade — a hash against an allocation — but it is a real line, and it is one reason the check belongs as early in the path as you can put it. **Key distribution.** Every front-door instance must hold the same key, or a client validated by one instance is challenged again by the next and loops forever behind a load balancer. That means a shared secret, in memory, never logged, delivered the same way to every instance. **Key rotation with overlap.** Rotate on a schedule, and accept the previous key for one validity window, or every token in flight at the moment of rotation is rejected and every honest client is re-challenged at once. **A replay window.** Anyone who holds a valid token can reuse it until it expires. Two mitigations: bind it to the source address so a token minted for one address fails from another, and keep the lifetime short — seconds to a minute, not hours. Binding to the address is what stops one solved token from being distributed to a whole botnet; the residual risk is replay from the same address, which is bounded by the lifetime. **Coarse time.** The timestamp has to be coarse enough that a client re-presenting a token a moment later still recomputes to the same value, which in practice means bucketing time and accepting the current and previous bucket. ## What the token is not It is not a session cookie and it is not an identity. It authorises exactly one thing — that the front door may now spend resources on this address — and it carries no claim about who the client is or whether the request is welcome. Conflating the two produces the memorable failure where a validation token is treated downstream as an authenticated session. ## The direction of the guarantee A verified token proves that the address received something you sent recently. It does not prove the client is the same client, that it is honest, or that the request behind it is safe. Every one of those is a separate control, and the challenge exists only to make it affordable to run them.