Forged TCP resets were first documented as a practical weapon in 2004, when Paul Watson's "Slipping in the Window" showed that a spoofed reset only had to land somewhere inside the receiver's window, not on one exact sequence number, to kill a live session. An RST flood is the volume version of that idea, a Layer 4 attack vector a thorough DDoS test is built to exercise: a high rate of TCP segments with the RST flag set, usually spoofed across many source addresses and ports. It still matters because the reset is the one TCP flag whose whole purpose is to destroy state, so every stack and every inline device has to decide, packet by packet, whether to believe it.
How an RST flood works
As a protocol attack, it is sized by how many segments per second a stateful box can inspect, and the width of the link hardly enters into it. What makes the reset different from its flag-flood siblings is that it can do harm in two separate ways.
The first is plain lookup cost. Almost every forged reset matches nothing, so a firewall or load balancer searches its connection table, misses, and discards the packet. Nothing is stored and nothing is sent back. The flood wins only by making the device do that search faster than it can.
The second is teardown. A reset that does match a real connection, with the right addresses, ports and an acceptable sequence number, closes it, and a stateful device that sees it valid retires its own entry along with the host's. Watson's 2004 work turned that from theory into a threat: long-lived sessions on well-known ports, with BGP between routers the headline example, were guessable in a practical number of packets. The response was a long tightening of the rules. BGP operators leaned on TCP MD5 signatures, and RFC 5961 (2010) changed what a stack accepts: a reset is honoured only if its sequence number is exactly the next one expected. One that merely lands in the window gets a challenge ACK instead, which the real peer can answer and a blind attacker cannot.
Why it matters under attack
The near-silence is the first distinctive property. A stack never answers a reset with a reset. A forged one that matches no connection, or misses the window, is discarded silently, and even one that lands in a live window draws only a rate-limited challenge ACK. So an RST flood produces almost none of the outbound reflex traffic that a SYN-ACK flood or a FIN flood does when it reaches the origin. The cost stays mostly on the inbound side, in lookups.
The challenge ACK is the second, and it cuts both ways. In 2016 researchers showed (CVE-2016-5696) that Linux's single, global limit on challenge ACKs, then 100 per second, leaked enough through a side channel to let an off-path attacker infer whether a connection existed and then find its sequence numbers. Defences against blind resets had become a way to aim them. The kernel fix randomised and loosened that limit, but the lesson for testing is that the protective mechanism has a rate of its own, and a flood can push against it.
Forged resets are not only an attacker's tool. In 2007 Comcast was found injecting resets into its customers' BitTorrent connections to throttle them, and the FCC ruled against the practice in 2008. That case is the cleanest real-world demonstration that a third party with the right vantage point can close sessions it does not own.
Dropping early helps, but only so far. A reset that matches no entry in a stateful firewall is invalid by definition, and dropping invalid-state packets early in the ruleset keeps them out of everything that follows. The lookup itself has still happened, though, so on a box that is short of CPU the only real saving comes from discarding the bulk of the flood statelessly, upstream of the device holding the connection table.
What a DDoS test measures
A test first characterizes the random-reset rate each stateful device rejects before CPU saturates and legitimate sessions start to stall, and records that figure separately for each box in the path, since one tier almost always gives out well before the others.
It then checks the teardown side on a test connection the tester owns, never on production sessions: does the origin stack apply the exact-sequence rule, does a load balancer that terminates TCP apply it on its own stack, and does an inline device delete its entry for a reset its host would have refused? The long-lived connections are the ones worth listing for that check, because they are the ones a blind attacker can find: BGP peerings, database replication links, WebSocket fleets. Understanding DDoS Attack Vectors puts this next to the flag floods it is usually confused with.