What DDoS Mitigation Is, and What It Cannot Do

A distributed denial-of-service attack does not break anything. It asks for service — a great deal of it, from a great many places, all at once — and the failure that follows is the service doing exactly what it was built to do until it runs out of something. Bandwidth, packets per second, connection-table entries, worker threads, database connections, or the budget of a person who has to decide what to turn off.

That is why the defence is called mitigation rather than prevention. You cannot stop the requests from being sent. You can decide, quickly and at scale, which of them to answer.

The definition, and the three words that carry it

DDoS mitigation is the practice of keeping a service reachable while it is deliberately flooded, by detecting abnormal traffic, classifying what kind of attack it is, and enforcing a response close enough to the source that legitimate requests still get through.

Each of those three words is load-bearing, and each fails in its own way.

Detection is a question about time. Every second between the first attack packet and the first mitigated packet is a second of degraded service, so a defence that identifies an attack perfectly but slowly has produced an outage with excellent forensics. This is why time-to-mitigate is a first-class metric rather than a footnote.

Classification is a question about accuracy. Deciding that traffic is abnormal is not the same as deciding what to do about it, and the gap between those two decisions is where false positives live. A flood of TCP SYNs from spoofed sources and a genuine traffic spike from a marketing campaign both look like a step change in connection rate; treating the second as the first is a self-inflicted outage.

Enforcement is a question about proportion. The blunt answers — drop everything to this destination, blackhole the prefix — always work and always cost you the thing you were defending. The precise answers cost state, cost processing, and can be evaded. Most real mitigation is a ladder between those two, climbed as the evidence gets stronger.

What mitigation actually does, stage by stage

The lifecycle is worth walking once, because most disagreements about products turn out to be disagreements about which stage is being discussed.

Attack begins. Something starts sending you traffic you did not ask to serve. It may be a botnet, a set of reflectors amplifying small requests into large responses, or a modest number of hosts sending requests that are individually cheap to make and expensive to answer.

Detection. A defence notices, using whatever it can see: flow records exported by routers RFC 7011, packet counters, connection-establishment rates, or application signals like request rate per URL. What it can see determines what it can notice, which is why a defence that only reads flow records is structurally late to an application-layer attack.

Classification. The defence decides what kind of attack this is and, critically, against which destination. Carpet-bombing campaigns exist precisely because a per-destination threshold never trips when the volume is spread across a whole prefix. Classification that aggregates only at host level cannot see them.

Enforcement. Something is done: packets dropped, rates limited, handshakes proxied, clients challenged, or the traffic diverted to somewhere with more capacity. Which action is available depends entirely on where the enforcement point sits.

Clean traffic. Legitimate requests reach the service. This stage gets far less attention than it deserves, and it is where hybrid designs most often go wrong: getting scrubbed traffic back to the origin involves tunnels, asymmetric routing and MTU questions that have nothing to do with how good the scrubbing was.

Recovery. Mitigation is withdrawn, the incident is reviewed, and the evidence is retained. Skipping this stage is free on the day and expensive later, because the reporting duty that arrives after a significant incident is a data duty — you cannot capture the telemetry retroactively.

Three attack families, three different defences

The taxonomy that matters operationally is not the OSI layer but the resource being consumed.

Volumetric attacks aim at bandwidth. Reflection and amplification are the usual mechanism: the attacker sends small requests with a forged source address to servers that answer with much larger responses, and the responses arrive at the victim. The defining property is that the traffic is large before it is anything else, so the defence must sit somewhere with more capacity than the attack — which almost never means your own rack.

Protocol and state-exhaustion attacks aim at the tables. A SYN flood consumes half-open connection slots; an ACK flood makes a stateful device look up sessions that do not exist; fragmentation attacks consume reassembly buffers. These do not need to be large. A few hundred megabits of well-chosen packets can exhaust a firewall that advertises tens of gigabits of throughput, because the constraint is state rather than bandwidth. This is the family that most often surprises people who sized their defence in Gbps.

Application-layer attacks aim at work. Requests are individually valid, complete a handshake, and ask the service to do something expensive: a search, a report, a login attempt, a cache-missing query. They are small, they are hard to distinguish from real users without knowing your application, and they are the reason “how many gigabits can it handle” is an incomplete question.

A real campaign usually mixes at least two of these, often deliberately — the volumetric component saturates attention while the application-layer component does the damage.

Each family has its own page: SYN flood for the state-exhaustion case, reflection and amplification for the volumetric one, and HTTP flood for the application layer. Terms used without definition anywhere on this site are in the glossary.

Layer 3, Layer 4 and Layer 7 are three different problems

At Layer 3 and Layer 4 a defence can judge traffic without understanding it. Is this source plausible? Does this packet belong to a session that exists? Is this rate consistent with the last four weeks? Judgements of that kind can be made statelessly, at very high packet rates, and by a device that knows nothing about the application behind it.

At Layer 7 that is no longer true. Deciding whether a request is abusive requires knowing what this service normally receives, which endpoints are expensive, and what a real user session looks like. It requires terminating the connection, which costs state, and often decrypting it, which costs processing and raises questions about where the private keys and the plaintext are allowed to be.

The practical consequence is that competence at one layer says almost nothing about competence at the other, and that the two are frequently delivered by different components. A design that assumes a single box is equally strong at both should verify it rather than infer it.

Where the inspection sits: inline and out-of-path

Inline means the device is in the traffic path and every packet passes through it. It can act on the first bad packet with no diversion delay, and it sees both directions of a session, which is what makes protocol-state and application-layer decisions possible. The cost is that it is now part of your availability: its failure modes, its bypass behaviour and its maintenance windows are your failure modes, bypass behaviour and maintenance windows.

Out-of-path means the device receives copies of traffic or flow records, decides, and then causes traffic to be diverted to it — by a BGP announcement, a FlowSpec rule RFC 8955, or a signalling protocol such as DOTS RFC 8811. Nothing is in the path in steady state, which removes a class of risk entirely. What it costs is time at the beginning of every incident, because diversion is a routing change and routing changes converge on their own schedule.

Neither is a better answer in general. The choice follows from how short your attacks are and how much steady-state risk you are willing to hold.

Where the capacity sits: on-premises, cloud and hybrid

An on-premises tier sits at your own edge, ahead of the servers. It sees your traffic in full, decides locally, holds its own telemetry, and answers protocol-state and application-layer attacks immediately because there is nothing to divert. It cannot answer volume larger than the circuit that feeds it, and no configuration changes that.

A cloud scrubbing tier sits in a provider’s network with far more capacity than yours. It answers volume, which is the part you structurally cannot answer, and it answers it at a scale that would be absurd to build. What it does not naturally hold is the history of your particular application, and what it does not naturally give you is telemetry on your own schedule.

A hybrid design uses both, and the interesting question is not whether to have both but who owns which decision, and what happens when one of the two is unavailable. A hybrid bought as a single bundle from a single supplier is operationally simpler and concentrates exactly the dependency the design was meant to spread; a hybrid assembled from two suppliers spreads the dependency and costs an integration you now own. Both are defensible. Neither is free.

The full comparison of cloud, on-premises and hybrid works through the trade in detail, and the multi-vendor question takes the concentration argument further than there is room for here.

Detection telemetry: what a defence is actually reading

Every detection decision is made from one of four kinds of evidence, and the kind determines the class of attack that can be seen.

Flow records — IPFIX, NetFlow, sFlow RFC 7011 — summarise conversations after the fact: source, destination, ports, byte and packet counts. They are cheap, they scale to carrier networks, and they are sampled, which means they are excellent at volume and structurally blind to anything small.

Packet-level counters capture rates and sizes as traffic passes. They are what makes packet-rate attacks visible at all, and they are the reason packet size matters so much in testing: a device that handles 100 Gbps of 1518-byte frames may collapse under a fraction of that in 64-byte packets, because the constraint is packets per second rather than bits.

Connection state — half-open counts, session-table occupancy, handshake completion rates — is what makes state-exhaustion attacks visible before the table is full rather than after.

Application signals — requests per second per endpoint, response codes, latency distributions, cache hit rates — are the only evidence that distinguishes an expensive legitimate request from an expensive malicious one. They exist only where something terminates the connection.

A defence sees the attacks its telemetry can describe. This is worth stating plainly because it explains, without any reference to product quality, why a flow-based detector is late to a slow application-layer attack: not because it is badly built, but because the evidence it reads does not contain the event.

False positives, goodput, and the number nobody quotes

The metric that matters during an attack is goodput: the legitimate traffic that still reaches the service while mitigation is active. It is not the same as throughput, and it is the number most likely to be missing from a datasheet.

The reason it is missing is that it is a property of the deployment rather than the device. Goodput depends on how well the baseline describes your traffic, how much of your legitimate traffic resembles the attack, and how aggressively you have tuned. A defence that drops everything achieves perfect mitigation and zero goodput, which is a distinction that only matters to the business rather than to the graph.

This makes false-positive testing an obligation rather than an optional extra in any acceptance plan. Replay real traffic alongside the attack. Measure what fraction of the real traffic survives. Repeat it at your genuine business peak, because a threshold that is comfortable at 3am is a different threshold at the busiest hour of the quarter.

Capacity is not efficacy

Two products can both claim a large number and mean entirely different things by it, so it is worth separating the claims that get conflated.

Capacity is how much traffic a device can process before it becomes the bottleneck, usually stated as bits per second and, if the vendor is being helpful, also as packets per second at a stated packet size. It is a ceiling, and it is normally the ceiling of the largest model in a family rather than the one you will be quoted.

Efficacy is how correctly it decides, which is a different axis entirely and much harder to state. It shows up as detection time, false-positive rate under realistic traffic, coverage across attack classes, and behaviour on vectors it has not seen before.

A device with enormous capacity and weak classification will forward an attack very quickly. A device with excellent classification and insufficient capacity will make correct decisions until it is overrun. Both failures are common, and only one of them is visible on a specification sheet — which is the entire argument for a proof of concept that measures the other.

Clean traffic has to get back

In a diversion design, traffic is pulled away from its normal path, cleaned, and then has to be delivered to the origin. That return path is a design decision with consequences that regularly surprise people who treated it as plumbing.

It is normally a tunnel — GRE, or a dedicated circuit, or a cloud interconnect — and a tunnel reduces the usable MTU, which means path MTU discovery and TCP MSS clamping become part of your availability. It also makes routing asymmetric: traffic arrives through the scrubbing provider and leaves directly, which breaks anything in the path that expects to see both directions of a session. Stateful devices sitting between the tunnel endpoint and the servers are the usual casualty.

None of this is an argument against diversion. It is an argument for testing the return path under load before an incident rather than during one, and for asking the question in the procurement stage where it still changes the design.

Protection is not one control

The single most useful correction to make early is that DDoS protection is not a product category you buy once. It is a set of controls at different places in the path, each answering what the others cannot.

Ingress filtering at network borders RFC 2827 RFC 3704 limits the spoofed sources that make reflection attacks possible. It protects other people from your network rather than your network from other people, which is why it is a shared obligation rather than a competitive feature, and why adoption remains uneven.

Blunt upstream instruments — remotely triggered black hole filtering RFC 5635, FlowSpec rules — stop saturation from reaching you at the cost of dropping some or all traffic to a destination. They are the tools of last resort, and having them rehearsed matters more than having them documented.

Dedicated mitigation, wherever it sits, does the work of separating good from bad.

Host and platform tuning raises the floor underneath all of it: kernel and network-stack limits, web-server timeouts, application-server connector settings. This is the layer covered in the hardening section, and its honest role is to decide whether a moderate flood is an incident or a graph. It never absorbs saturation.

Operational readiness — who decides, on what evidence, at what hour, with what escalation path — is the control most likely to be missing and least likely to be budgeted. NIST’s incident-handling guidance NIST SP 800 61R3 is the usual external reference for structuring it, and the CSF NIST CSF 2 is a workable frame for organising the evidence.

What DDoS mitigation does not solve

Being precise about the limits is more useful than being reassuring about the capabilities.

It does not undo saturation. When the volume arriving at your transit circuit exceeds what the circuit can carry, packets are already being discarded upstream of everything you control. This is the one constraint that no amount of local capability changes, and it is why upstream capacity is part of the design rather than an alternative to it.

It does not fix an application that falls over under load. If a single request can consume a database connection for eight seconds, an attacker needs remarkably little traffic. Rate limiting buys time; it does not repair the underlying economics.

It does not stop targeted exploitation. Availability defence and vulnerability defence are different disciplines that happen to share a perimeter. A DDoS appliance will not notice an authentication bypass.

It does not produce compliance. Regulatory regimes place duties on the entity — manage the risk, notify within a clock, assess your suppliers — and those duties cannot be transferred to a supplier or discharged by a purchase. What a well-chosen architecture does is make the answers short and evidenced. The regulation section works through what specific regimes actually require.

It does not remove the need to decide. Every mitigation posture is a standing decision about what to sacrifice under pressure. Making that decision in advance, in writing, is the part no product performs for you.

Choosing a shape

Appliance	Where inspection happens	What it answers well	What it cannot answer	Who it suits
Upstream or carrier filtering	In your transit provider's network	Volume that would saturate your circuit	Application-layer requests that look legitimate	Anyone whose circuit is smaller than a plausible attack
Cloud scrubbing	In a provider's scrubbing centres	Large volumetric and protocol floods	Anything requiring your own traffic history to judge	Services that can tolerate a diversion delay or run always-on
On-premises appliance	At your own edge, before the servers	Protocol-state and application-layer attacks, immediately	Volume larger than the circuit feeding it	Estates that hold their own evidence and need L7 depth
Host and platform tuning	On the servers themselves	Raising the floor under moderate load	Anything that arrives as saturation	Everyone, as a baseline rather than a defence

These are layers, not alternatives. Almost every workable design combines at least two, and the question is which one owns each decision rather than which one wins.

The order to work through it in is unglamorous and reliable: establish what has to stay available and what latency it tolerates; measure your normal peak in both bits and packets; find the smallest circuit in the path, because that is your ceiling; decide what evidence you must be able to produce and how quickly; and only then look at products. A shortlist built that way is short. A shortlist built from datasheets is long and does not converge.

Related standards and primary sources

The standards below are the primary references behind this page. None of them mandates a product, and a vendor claim that a standard requires a particular architecture should be checked against the text.