When protocol features become attack surfaces

Threat modelling that only asks what is broken will miss this entire class of attack. A protocol specification is a list of promises: ask for this and I will do that. An attacker reads the same document as a price list, looking for the request that is cheapest to send and most expensive to serve. Nothing has to malfunction for that gap to be profitable.

Take the feature at the centre of this module. Stream cancellationexists for the client's benefit and it is good engineering. A browser changes its mind constantly. The reader scrolls past the images further down the page, navigates away before the article finishes loading, drags a video player's scrub bar to a different position. Before HTTP/2, saying "stop, I no longer want that" meant tearing down the whole connection, which threw away the handshake, the encryption state and the congestion state along with the unwanted response. Cancellation lets a client abandon one request and keep everything else, which saves the network real work.

It only works because of the other feature underneath it. Stream multiplexing carries many independent requests inside one connection, each with its own identifier and its own ordering. A server protects itself there by capping how many streams a client may have open at once, which is a sensible limit and, as the next section shows, the wrong thing to count.

Before going further it is worth checking what the word for this category of attack actually commits you to, because most people carry an assumption inside it that the definition does not support. A distributed denial of service is defined by where the traffic comes from, not by how much of it there is.

The glossary of the United States National Institute of Standards and Technology defines it as a denial of service technique carried out from numerous hosts. Read what that definition leaves out. It says nothing about bandwidth, nothing about packet sizes and nothing about volume at all. The word distributed refers to the number of sources, because a great many sources is what makes attack traffic hard to separate from customers. A technique that exhausts a server's ability to start work, sent from many hosts, qualifies even if the bandwidth involved would not trouble a home broadband line. Section 27.4 turns that observation into a way of reading published attack figures.

Abused features are not all the same, and the quadrant below separates them on the two properties that decide what you can do about them. Across: was the behaviour a convenience somebody left switched on, or is it core to how the protocol works? Down: does the abuse scale to a flood, or is its reach bounded?

The left column holds the leftovers. An amplification attack sends small queries carrying a forged source address to servers whose answers are much larger, so the answers arrive at the victim rather than at the sender. Open DNS resolvers were the classic reflector, and the NTP monlist command, which returns a list of recent clients when asked, was another. Both are fixable by configuration because neither is load bearing: close the resolver to strangers, disable the diagnostic command, filter traffic that carries a source address it could not legitimately have. Nobody loses a capability they were using.

The right column is the uncomfortable one. Cancellation cannot be removed from HTTP without making every browser worse. Early data sent before a handshake completes, which the TLS module covered as 0-RTT, can be captured and replayed so the server acts on the same request twice, and it still cannot be removed without giving back the round trip it was introduced to save. For features in this column the question is never whether to keep them. It is what accounting you apply so that a peer who uses them a thousand times a second is treated differently from a peer who uses them the way a browser does.

That is the threat-modelling move this module is asking for. For every behaviour you perform on request, write down two figures: what it costs the requester to ask, and what it costs you to comply. Where those two diverge sharply, you have found an attack surface, and you have found it without waiting for a CVE to tell you. Rapid Reset is the case that proves the method, so the next section takes it apart frame by frame.

The loop is three steps long and the figure above the fold draws it. The client sends a HEADERS frame, which opens a stream and carries a request. The server does what a server does with a request: it allocates state for the stream, parses the headers, works out which route or handler applies, very likely starts an authentication check and a call to a backend or a database. Before any of that can produce a response, the client sends RST_STREAM and cancels the stream. Then it opens the next one. No new connection, no new handshake, no new certificate validation. The same established connection carries the loop for as long as it is allowed to.

The asymmetry is the attack. Sending HEADERS and RST_STREAM costs the client two small frames on a connection it has already paid for. Serving them costs the server most of a real request: the state, the parsing, the routing, the backend call that has already been dispatched and whose result will now be thrown away. The response bytes are the only part of the work the server is spared, and the response bytes were never the expensive part.

Now add the detail that turns an inefficiency into a record-breaking flood. A cancelled stream is closed, and a closed stream does not count against the limit on how many streams may be open at once. The protection the server thought it had was counting concurrency, and concurrency is exactly what the attacker never accrues. An operator watching that metric sees a connection with almost nothing open on it while the machine behind it saturates. This is why the mitigated peaks were measured in requests rather than in bits: 398 million requests per second at Google, 201 million at Cloudflare and 155 million at AWS were floods of work, not floods of traffic.

The fix follows directly and it is worth stating precisely, because it is the evidence for this module's argument. Vendors did not change the protocol. They changed what they counted. Track cancellations per connection, treat a connection whose reset rate is far above what a browser produces as abusive, and close it or charge it. Some implementations also cap the total streams a single connection may open across its lifetime, which bounds the loop even when each individual cancellation looks legitimate. The feature survived. The free ride ended.

A flood of that size arriving as requests rather than bits also explains where it was stopped. The three organisations that disclosed it are the three that could see it at scale, and that is not a coincidence about their engineering budgets. It is a fact about where the traffic physically arrived.

Start with the structural defence. Anycast announces the same address from many separate locations and lets ordinary routing deliver each client to one of them. A client does nothing special and knows nothing about it: it sends to one address, and the routing system decides which instance answers. For a content delivery network this is how one address can be served close to users everywhere, from dozens or hundreds of separate points of presence.

Anycast mitigation is what that same arrangement does to a flood. Attack traffic is sent from many sources in many places, so routing splits it the same way it splits legitimate traffic, and each share is absorbed near where it entered the network instead of arriving whole at one site. The flood divides itself. There is one hard-won operational warning attached: withdrawing an anycast route while under attack does not shed the load, it moves it to the next instance, and operators tend to learn this during the incident rather than before it.

Capacity alone would not have stopped Rapid Reset, and this is the part worth slowing down for. Splitting a flood works when the scarce resource is bandwidth. It helps far less when the scarce resource is the ability to start and abandon requests, because dividing 398 million requests per second across many sites still leaves every site doing work it will throw away. What the edge contributed was not only capacity. It was protocol awareness: proxies that terminate HTTP/3 and HTTP/2 themselves, parse the frames, hold per-connection counters and can therefore see a cancellation rate no browser would produce. A pure bandwidth defence, in front of a proxy that only counted open streams, would have passed the attack through intact.

That gives the ownership map, and it is worth naming each layer with the thing only it can do. The transit provider or scrubbing service owns volume and spoofing: it can drop traffic carrying source addresses it could not legitimately have, which is the control that decides whether amplification is possible at all, and notice that it is usually somebody else's network that has to apply it on your behalf. The content network or edge owns distribution and protocol-aware limits. The reverse proxy or load balancer at the origin owns per-connection accounting for anything that reaches it directly. The application server owns concurrency, queue depth and timeouts. The application itself owns how expensive an individual request is allowed to be, which is the only layer that can make a flood cheap to serve rather than merely cheap to reject.

None of that removed the origin's job. Defence in depth is not a slogan here, it is the practical consequence of the traffic that never passes the edge. Origin servers whose addresses are reachable directly can be hit around the content network entirely. Internal service-to-service traffic frequently speaks the same multiplexed protocols with no edge in front of it at all. Interfaces that partners reach by agreement often bypass the public path by design. Operators who concluded that their provider had handled it, and who therefore did not update the software terminating those connections, kept the exposure in every place their provider could not see.

Notice how much of this section depended on knowing that the headline figure was a rate of requests. Had it been a rate of bits, the ownership map would have started and very nearly ended at the transit provider. Reading the unit correctly is not pedantry, it is what selects the defence.

Three units appear in attack reporting and they are not interchangeable, because each one names a different resource running out.

Requests per second measures application work. It is exhausted at the server: the handlers, the connection pools, the database behind them. Bits per second measures link capacity. It is exhausted in the pipe, and it is the figure that matters when a circuit fills and traffic is discarded before any server sees it. Packets per second measures per-packet processing. It is exhausted in the hardware that has to make a forwarding or filtering decision for every packet regardless of how small that packet is, which is why a flood of tiny packets can overwhelm equipment that would have carried the same bits comfortably in fewer, larger ones.

The three come apart in both directions. Rapid Reset produced enormous request rates on modest bandwidth, because two small frames trigger a whole request. A large amplification flood is the mirror image: it can fill a circuit with very few distinct requests, and reporting it in requests per second would make it sound trivial. A figure without its unit is unreadable, and a figure whose unit you did not check is worse, because you will act on it.

Measurement literacy is the habit this course has been building since the foundations stage, and it applies to attack figures exactly as it applies to adoption figures. Four questions turn a headline into something you can use.

What is the unit, and therefore which resource was exhausted? Whose vantage point produced it, given that a defender can only report the traffic that arrived at their own network and a different defender would have seen a different share of the same campaign? Over what window, since a peak sustained for two seconds and a rate held for an hour are different engineering problems wearing the same number? And was the figure mitigated or delivered, which is the distinction that decides what the number is evidence of at all?

That last question deserves its own sentence. A mitigated peak is a defender's telemetry: it records what their systems saw and absorbed. It is a real measurement of what arrived, and it is not a measurement of what the attacker was capable of, which is unknown and probably larger. The figures in this module are stated as mitigated peaks for that reason, and quoting them as the size of the botnet or the limit of the technique would be a claim nobody has the evidence to make.

Applied to an alert on your own estate, the same discipline stops the first expensive mistake. Before anyone is asked to add capacity, establish which unit the alert is actually reporting, because the answer decides which of the layers in section 27.3 you are going to call. Establishing that takes evidence, and different layers of the stack hold very different amounts of it.

The drill is one question asked three times: what can this layer prove, and what can it not? Write both halves down. The habit the applied stage built, that transport evidence narrows the candidates without concluding, is the whole point here, and under incident pressure it is the first discipline people drop.

Start at layer 3, the network layer, where flow logs are usually the cheapest evidence still available. They prove distribution and volume: how many distinct source addresses, arriving at what rate, towards which of your addresses, over what period. That is enough to distinguish one noisy client from a genuinely distributed event, and it is often the only record that survives long enough to reconstruct what happened last Tuesday. What layer 3 cannot prove is whether those addresses are real, because a source address can be forged, or which of the requests behind them were expensive to serve.

Layer 4, the transport layer, answers the first of those two questions. A completed TCP handshake is evidence that a source address could receive the reply, which spoofed traffic cannot do, so the split between connections that completed a handshake and packets that never did separates a reflected flood from a flood sent by real hosts. It also shows whether the traffic is TCP or UDP, and how many connections each source held open. What layer 4 cannot prove is what was asked for. A connection that completes a handshake and stays open looks identical whether it is carrying one video stream or a cancellation loop.

Only layer 7, the application layer, could have identified Rapid Reset, and it is worth being blunt about why. The signature is the ratio between streams opened and streams cancelled on a single connection, and the only component that can see it is one that parses the frames: the proxy, the load balancer or the server itself. No amount of flow data and no connection table would have produced that number. Layer 7 also holds what was requested, what it cost and what status was returned, at the price of being the most expensive evidence to keep and the layer QUICencryption has moved furthest out of a passive observer's reach.

One trap sits inside that last layer and it catches experienced teams. Many access logs are written when a response completes. A request that is cancelled before it produces a response may therefore never appear in the log at all, which is how an origin can run at full processor load while its request log looks unremarkable. Before an incident, find out which event your own logging is keyed to. During an incident, treat a quiet access log next to a saturated server as a finding rather than as reassurance.

Run the drill on a concrete alert and the shape becomes obvious. Processor load at the origin is at its ceiling, the circuit is nowhere near full, and the access log is calm. Layer 3 shows many sources but cannot say whether they are real. Layer 4 shows completed handshakes, which rules out the reflected floods in the left column of the quadrant and points at real hosts. Layer 7 shows a cancellation rate per connection that no browser would produce, which is the observation that separates the remaining candidates. Each layer narrowed the field. The last one concluded, and it could only conclude because the first two had already removed the alternatives.