Unlike a filter that drops hostile traffic outright, a tarpit does not reject a suspicious connection; it holds the connection open and unproductive, leaving the attacker with a socket it cannot use and cannot cleanly close. That inversion, making each malicious connection expensive to keep rather than cheap to retry, is one of the defensive behaviours a thorough DDoS test has to put under real load. A TCP tarpit answers with a tiny or zero receive window so the peer can never send meaningful data; higher-layer tarpits trickle bytes to keep an automated client waiting on a response that never fully arrives.
How a tarpit works
The mechanism exploits the fact that a polite TCP peer will wait. When a server advertises a zero-length receive window, the sender is obliged to hold the connection and keep probing to ask whether the window has opened, and a tarpit simply never opens it. The connection is neither refused nor served: it hangs, consuming a slot in the attacker's own connection table for as long as the tarpit cares to keep it there.
The idea is old and specific. LaBrea, written by Tom Liston in 2001 in response to the Code Red worm's internet-wide scanning, answered connection attempts to unused addresses and stuck the scanner in a persistent, zero-window connection so its worm thread stalled instead of moving on to the next host. The same behaviour is available as the TARPIT target in the xtables-addons extensions to iptables, and the pattern recurs at the application layer: SMTP servers have long used a "teergrube" tactic of answering a suspected spam sender one slow byte at a time to tie up its sending process.
The intent throughout is economic, not filtering. Dropping a flood packet is free for the attacker's next packet; trapping the connection is not. If each malicious connection ties up attacker resources for seconds or minutes, a fixed-size attacking fleet can hold far fewer concurrent connections against you, which is the whole point of the low-and-slow inversion applied in reverse, against the attacker.
Why it matters under attack
Tarpitting can blunt slow-rate and connection-exhaustion attacks, but it is double-edged in a way a test has to quantify. Holding state for attacker connections consumes defender memory too: every trapped socket is a slot on the defending side as well, so a tarpit that traps more connections than it was sized for becomes the very connection-exhaustion failure it was meant to prevent. There is a crossover point where the trap costs the defender more than the attacker, and where that point sits depends on how cheaply each side holds an idle connection.
The second hazard is collateral. An aggressive tarpit that keys on coarse signals can entangle legitimate clients, and the damage concentrates behind shared NAT, where many real subscribers exit through one address: tarpit that address and you stall every genuine user behind it. That is the same false-positive tension every mitigation carries, but it is sharper here because the control's defining action is to make the client wait rather than to send it elsewhere quickly.
What a DDoS test measures
A tarpit test characterizes where the balance breaks: the concurrent trapped-connection count at which the tarpit's own memory footprint becomes the bottleneck, and how that compares to the connection ceiling of the servers it is protecting. If the tarpit falls first, it has moved the failure rather than removed it.
It then measures collateral at the enforced settings, driving legitimate traffic (including clients sharing an address behind carrier NAT) through the control to see how many real sessions it stalls while trapping the attack. The deliverable is the pair of numbers that decide whether an operator dares leave the tarpit engaged during an incident: how much attacker capacity it actually strips, and how many real sessions it stalls at that setting. Whether the control can stay on mid-incident, or has to be pulled at the worst moment, is ultimately a question of exercising it against live traffic without freezing the users it is meant to defend, which is worked through in testing without disrupting production.