Making the Client Pay

## The claim a source address makes Every IP packet carries a source address and nothing in IP verifies it. Where an upstream network does not filter outbound traffic to the prefixes it actually owns (BCP38-style ingress filtering, or uRPF on the access edge), a host can put any address it likes in that field. Spoofing costs the attacker nothing per packet, and it buys two things: the flood is unattributable, and any state you allocate on arrival is allocated for a client that does not exist. The one thing the spoofer gives up is the return path — whatever you send back goes to the address they forged, not to them. An address-validation round trip is built entirely on that giveaway. ## What the round trip is Before committing anything expensive — a connection table entry, a session, a worker thread, a buffer, a database lookup — send something to the claimed address and require it back. The forms differ by protocol and all do the same job: - TCP's own handshake: the server picks a sequence number and will not treat the connection as established until the client acknowledges it. Only somebody receiving traffic at that address can. - QUIC's Retry: the server refuses to allocate a connection, replies with an opaque token, and requires the client to re-send its Initial carrying that token. - DNS answering over UDP with the truncation bit set, forcing the resolver to retry over TCP, which has a handshake in it. - An HTTP redirect that sets a token the client must present on the next request. ## What it proves, precisely Exactly one fact: the source address is *return-routable* — traffic sent there arrives at the party you are talking to. That is worth a great deal. It removes spoofed traffic, it removes reflected traffic whose apparent source is somebody else's victim, and it turns the survivors into a finite set of real addresses you can count, group by network, and block. It also raises the attacker's unit cost from a packet to a host that must hold state. ## What it does not prove It says nothing about identity, intent, or whether a human is present. A botnet of real devices, or rented capacity in somebody's cloud account, uses genuine addresses and passes every validation you can devise; the toll is simply paid. It also does nothing at all before the packet reaches you — if the uplink upstream of the front door is saturated, no challenge is ever issued, because no request ever arrives. ## The price the defender pays - **A round trip on every honest client.** On a protocol designed to establish quickly this is a real regression, and it lands hardest on the users furthest away. - **Issuance must itself be stateless.** If validating an address costs you a table row per unvalidated client, you have moved the flood from the connection queue into the validation table and gained nothing. - **Anti-amplification.** Anything you send to an address you have not validated may be going to somebody else's victim. QUIC caps a server at three times the bytes received from an unvalidated address for exactly this reason, and the same discipline applies to any UDP-borne challenge: never answer an unproven address with substantially more than it sent you, or your defence becomes someone else's reflector. - **Client compatibility.** A redirect-plus-token challenge assumes a client that follows redirects and keeps the token. Plenty of legitimate machine clients do neither. ## How it is actually used As the first and cheapest gate in a stack, not as the answer. Validation strips the free traffic — the spoofed and reflected share, which for many floods is most of it — and leaves a smaller, attributable population for the more expensive controls to judge. The engineer who describes it as proof of legitimacy has the direction of the claim wrong, and that error shows up later as blocking decisions made on evidence that never supported them.