How Modern Appliances Detect and Mitigate Carpet-Bombing DDoS Attacks

Most DDoS detection was designed around an assumption that is rarely stated: that an attack has a target, and that the target is a host. Counters are kept per destination address, baselines are learned per destination address, alerts name a destination address, and mitigation is applied to a destination address. Carpet bombing is the attack shape that takes that assumption apart, and it does so without needing any new vector, any new amplifier or any unusual volume.

This article is about the mechanics: what the attack actually does to a detection pipeline, why aggregation level rather than sampling rate decides whether you see it, why the routing primitive most operators reach for first is the worst possible response, and what a proof of concept has to contain before a vendor’s answer to “yes, we handle carpet bombing” means anything.

What carpet bombing actually is

The attacker takes a routed prefix — a /24, a /22, a hosting provider’s allocation — and distributes traffic across the addresses inside it, either across the whole block or across a subset that rotates over time. The vectors are the ordinary ones. Reflection and amplification toward the block, SYN floods against common ports, fragmented traffic, mixed protocols. Nothing about a single packet is unusual, and nothing about the rate delivered to any one address is unusual either. Only the distribution is unusual, and the distribution is the point. The technique is also described as spread-spectrum, because the energy is spread across the address space rather than concentrated.

Two consequences follow from that, and they run in opposite directions.

The first is that the per-host signal disappears. A detector watching each address sees moderate, unremarkable traffic. Nothing crosses a trigger, so nothing alarms, so nothing diverts and nothing mitigates.

The second is that the damage lands entirely on shared resources: the access circuit, the edge router’s forwarding and control plane, the stateful perimeter’s session table, the mitigation device’s own tracking tables, and the event pipeline behind all of them. Those are precisely the resources for which nobody maintains a per-host threshold, because a per-host threshold makes no sense for them.

A worked example, purely to show the arithmetic — the numbers are illustrative and carry no claim about real attacks. A /22 contains 1,024 addresses. If each receives roughly 20 Mbps, no address is doing anything a hosting provider would consider abnormal, and the aggregate arriving at the edge is a little over 20 Gbps. Halve the per-address rate and double the block size and the aggregate is unchanged while the per-host figure becomes even less remarkable. The attacker has a free parameter, and it is the one your detector is watching.

There is a further detail that matters operationally. The attacker does not need to know which addresses inside the block are live. Sweeping the whole prefix is simpler and works just as well, because your router is the one advertising the covering prefix: your upstream hands you traffic for every address in it, including addresses with no host behind them. That traffic crosses your access circuit and reaches your edge before anything decides it has nowhere to go. Dark addresses cost you bandwidth and forwarding capacity exactly as live ones do.

Why per-destination thresholds cannot be tuned out of the problem

The instinctive response is to lower the thresholds. It does not work, and understanding precisely why is what motivates everything that follows.

Threshold detection maintains a counter per destination address and raises an event when the rate exceeds a configured value or a learned baseline. The attacker’s per-destination rate is a free parameter. For any trigger value you choose, traffic can be sent below it and the shortfall recovered by using more addresses. There is no value that both catches this and survives contact with production, because to catch traffic sitting deliberately low you would have to set the trigger below the normal variation of legitimate hosts — below backup windows, content pushes, replication jobs, a busy virtual server, a customer’s own load test. The detector would fire continuously.

On hosting and service-provider blocks there is a second dynamic that makes it worse. Most addresses in such a block are idle or lightly used most of the time, so their learned baselines are very low and statistically noisy. Any traffic at all looks like a large relative deviation. Operators respond exactly as you would expect: they impose an absolute floor below which nothing alarms, to stop the console filling with meaningless events. That floor is a published contract with the attacker. It defines the per-address rate that is guaranteed to be invisible, and the attack lives in the space beneath it.

So the problem is not that the thresholds are set wrong. The detector is measuring a quantity that is not under attack. The quantity under attack is the aggregate.

Aggregation is the structural answer — but at which level

The answer is to keep counters and baselines at every aggregation level at which the traffic can actually hurt you, and to run detection on all of them simultaneously: the host, the /24 or equivalent sub-block, the routed prefix, the customer allocation, and the physical interface or circuit. A carpet bomb that is invisible at the first level is obvious at the third, because at the third level the counter is measuring the same thing the circuit is measuring.

That is straightforward to say and it is where most deployments actually fail, because the aggregation hierarchy is a configuration decision and it is usually made once, early, by someone modelling the network as a list of important services. If the smallest and largest objects a detector knows about are individual virtual servers, the prefix does not exist as a countable thing and no amount of product capability compensates for that.

Two design rules make the hierarchy useful rather than decorative.

Detect at a level at which you can act. If external prefix-length filtering means the smallest unit you can divert outside your own autonomous system is a /24, then detecting beautifully at /32 buys you nothing you can execute. Conversely, if your response instrument is a FlowSpec rule that takes a destination prefix as part of its match, then prefix-level detection maps directly onto prefix-level response and the two stay aligned under pressure.

Follow the tenant boundary, not only the address boundary. In a multi-tenant operator, a /22 may carry two hundred customers. A prefix-level alarm is correct and necessary, but it names all of them at once. The hierarchy has to be able to express both the aggregate that is under pressure and the tenants whose traffic sits inside it, or the alarm is unactionable and the reporting afterwards is unusable.

The detection-signal problem: what your telemetry can and cannot see

For anyone running out-of-path detection, the next question is whether the telemetry feeding the detector is even capable of carrying the signal. There are three distinct effects here and they are frequently conflated.

Export latency. NetFlow and IPFIX accumulate flows in a cache on the router and export a record when the flow ends or when the active flow timeout expires. That timeout, not the sampling rate, sets the floor on how quickly a sustained attack can appear in your collector. Shortening it increases export volume and control-plane load. sFlow has no equivalent wait, because it sends packet samples as it takes them, but what arrives is a packet sample rather than a flow record, and any flow-like view has to be reconstructed at the collector.

Sampling, and why it matters less than people assume — if you aggregate. This is the part worth being precise about. Packet sampling degrades the fidelity of small bins far more than large ones, because the number of samples landing in a bin is proportional to the traffic in it. A bin holding a single destination address in a carpet-bombing scenario collects very few samples, or none, within a useful window, so any per-host estimate built from it is statistically worthless. A bin holding the entire prefix collects samples from every one of those destinations and produces a perfectly serviceable aggregate estimate. The same telemetry feed is simultaneously useless and adequate, and which one it is depends entirely on how you aggregate it. That is the single most useful thing to understand about detecting this attack out of path: the aggregation choice, not the sampling ratio, is what decides whether the attack is visible.

Flow cardinality. Carpet bombing generates an unusually large number of distinct flow keys — many sources, many destinations, and often randomised ports. Flow caches on routers are finite, and so are collector ingest paths. A workload that creates far more concurrent flow keys than the platform normally sees puts pressure on both, and the resulting behaviour under pressure is platform-specific and worth knowing in advance for your own line cards. The uncomfortable implication is that this attack shape degrades the very telemetry you are depending on to detect it, which is another argument for maintaining aggregate counters that do not depend on per-flow accounting surviving intact.

There is one more effect that belongs here. Detectors compute rates over an observation window. If the attacker rotates the active destination subset faster than that window, no per-host counter ever accumulates enough to matter, while the prefix-level counter is entirely unaffected — the traffic simply moves between rows of the same total. A rotating carpet bomb is the cleanest possible demonstration that per-host counting is the wrong instrument.

Destination cardinality as a first-class signal

Aggregate volume is the obvious signal. There is a second one that is more specific to this attack shape and considerably harder to imitate accidentally: the number of distinct destination addresses inside a prefix receiving traffic within a window, and the shape of the distribution of traffic across them.

Normal traffic to a service-provider block is heavily skewed. A minority of addresses carry most of the traffic, the set of active addresses is fairly stable from window to window, and addresses with nothing behind them receive close to nothing. Carpet bombing flattens that distribution and widens it: the active-destination count rises sharply, the skew collapses, and traffic appears at addresses that were previously dark.

Traffic to dark addresses deserves separate attention, because it is the cleanest signal available. There is no legitimate baseline to argue about and no plausible business explanation for a sustained rate toward an address with no service on it. A detector that knows which addresses inside a protected block are actually in use can treat a rise in traffic toward the rest as near-unambiguous, at a fraction of the volume that any rate-based rule would need.

Two questions follow for any product evaluation. Does the system compute distinct-destination counts per prefix per window, and can it alarm on them independently of volume? And can it be told which addresses in a block are in service, so that traffic to the remainder is treated differently?

Why RTBH is the wrong instrument here

Remotely triggered black hole filtering, described in RFC 5635, is the primitive every operator reaches for and the one most universally accepted upstream. It is also close to useless against this attack, and reaching for it reflexively is actively harmful.

The semantics are the problem. Destination-based RTBH discards all traffic to an announced prefix. Against an attack concentrated on one address, the trade is legible and often correct: you sacrifice one host to keep the network and every other customer running. Against carpet bombing there is no single destination to sacrifice, so you are left with two options and both are bad.

Announce many host routes, and you are enumerating a moving target. The set of addresses under attack changes; your announcements chase it; the number of prefixes you can announce is bounded by the limits on the session and by your provider’s policy; and you will be behind the attacker for as long as the attack lasts.

Announce the covering prefix, and you have executed the attacker’s objective with your own routing policy. Every address in the block goes dark, including every tenant who was not being attacked at all. It is a strange position to be in: the response completes the attack.

The source-based variant, also covered in RFC 5635 and implemented with unicast reverse-path forwarding, does not rescue the situation either. Reflection and amplification traffic arrives from legitimate third-party servers you have no business blackholing wholesale, and spoofed sources are not a finite enumerable set.

None of this means RTBH should be removed from the runbook. It remains the correct and often the only instrument for an aggregate that exceeds what your edge can physically ingest, because below that line there is nothing to discriminate with — the circuit is already full. The discipline is to place it correctly: RTBH is a capacity backstop with a declared threshold, agreed in advance and written into the customer-facing service definition, not a carpet-bombing countermeasure. Everything below that threshold should be handled by an instrument that can tell traffic apart.

FlowSpec and granular filtering

BGP FlowSpec, specified in RFC 8955 for IPv4 and RFC 8956 for IPv6, is the routing-layer instrument that actually fits the attack’s structure. The reason is specific: the destination prefix is part of the match tuple, alongside source prefix, protocol, port ranges, packet length, fragment bits and TCP flags. A single rule can therefore express “discard, or rate-limit, this protocol and source-port combination toward this /22” — the prefix is part of the description of the rule rather than something you repeat once per address. The rule count scales with the number of vectors, not with the number of destinations.

The contrast with RTBH is the whole argument. RTBH discards everything to the destination. FlowSpec discards only what matches, so every address in the block remains reachable for every protocol and port the rule does not name. The traffic-rate action matters here too: against a vector that carries some legitimate traffic, a rate limit across the prefix preserves part of it where an outright discard would not.

The cautions are practical rather than conceptual, and they are the same ones that apply to any FlowSpec deployment:

• Hardware filter capacity is finite. How many rules genuinely install in hardware depends on the platform and the line card. Measure it on your own equipment before you set an upper bound, and know what the platform does when the resource is exhausted.
• Rotating vectors multiply rules. The prefix does not multiply rules, but a multi-vector attack that changes protocols and ports does. Impose a hard ceiling on the active rule count and give every rule an automatic expiry, so that an incident cannot leave a permanent residue.
• Inter-AS use is constrained. The validation procedure in RFC 8955 associates a flow specification with the neighbour from which the best unicast route for its destination prefix was received. That is the right constraint for safety and it narrows what you can express in multi-provider environments.
• Most transit providers do not accept customer rules, and those that do accept a narrow subset of matches and actions. Against your upstream, the universally available primitive is still RTBH.

The practical posture is to run FlowSpec inside your own autonomous system first, with a rule ceiling, automatic expiry and two-person approval for production rules, and to treat upstream FlowSpec as a bonus rather than a load-bearing element of the design.

Appliance	Destination-based RTBH	BGP FlowSpec	Diversion to a scrubbing tier	Always-on inline appliance
What the action is keyed on	A destination prefix, usually a host route	An n-tuple that includes the destination prefix	A routed prefix announced from the scrubbing centre	Whatever the device is configured to aggregate on
What happens to legitimate traffic	Discarded along with the attack	Only traffic matching the rule is touched	Carried through the scrubbing path and returned	Inspected in place, no rerouting
Scales with the number of destinations?	No — one announcement per destination, or one for the whole block	Yes — the prefix is part of the match, not a repetition of it	Yes, but you divert the whole covering prefix	Yes, if counters and policies are prefix-scoped
Usable against your upstream provider?	Yes; the one primitive that is universally accepted	Rarely, and usually only a narrow subset	Yes, if the tier is upstream of your circuit	No — it sits below your circuit
Failure mode under carpet bombing	You complete the attacker's objective yourself	Hardware filter capacity and rule sprawl across vectors	Scrubbing and transport sized for one target, not a whole block	Per-destination state or per-host thresholds inside the device

These are layers, not alternatives. The practical order is: inline or diverted mitigation below your edge capacity, FlowSpec for vectors you can express cleanly at the router, and RTBH reserved for the case where the aggregate exceeds what your edge can physically ingest.

What it does to stateful devices

Bandwidth graphs understate this attack, and the reason is that the resources it exhausts are not measured in bits per second.

Stateful devices — firewalls, next-generation firewalls, load balancers, address translators — allocate state per connection. Traffic distributed across thousands of destinations produces a very high rate of distinct flows, and the binding constraints become session-table occupancy and new-connection rate rather than throughput. A perimeter sized correctly for business-peak bandwidth can be nowhere near sized for that flow rate, and the gap does not show up in any capacity plan built on bandwidth.

Three second-order effects compound it.

Per-policy protection profiles never engage. Denial-of-service protection on stateful platforms is typically attached to a policy, a virtual server or a zone. Traffic spread over many destinations maps to many different policies, or to no policy at all and therefore to a default deny. No single profile sees a concentration, so no profile’s trigger is reached, while the shared session table fills underneath all of them.

Traffic that goes nowhere still costs. A packet to a closed port on a live host, or to an address with nothing behind it, still costs a route lookup, a policy evaluation, very often a state entry, and a log line. The cost is paid regardless of whether anything is listening, which is what makes sweeping the whole block an efficient tactic rather than a wasteful one.

Exhaustion is indiscriminate. This is the point that determines how seriously to take the whole class. When a session table fills, the device stops admitting new sessions for everything it protects. The outage is not confined to the addresses under attack; it covers the entire estate behind the device. An attack that never threatened your circuit can still take down services that were never targeted.

The design conclusion is the familiar one — the mitigation layer belongs in front of the stateful layer, and it should be stateless or bounded in what it allocates per flow. But carpet bombing adds a specific question that is easy to forget to ask, and it is about the mitigator rather than the firewall: what does the mitigation device itself allocate per destination address? If it creates a tracking entry, a counter set or a baseline object per destination, then the attack’s destination cardinality is an attack on the mitigator too, and the device inherits the same exhaustion failure mode it was bought to prevent. Ask for the limit as a number, and ask what happens at the limit — eviction, degraded accounting, fail-open or fail-closed. All four are defensible answers. Not knowing is not.

What it does to your log and event volume

Event pipelines are built around the same host-centric assumption as the detectors. Alerts are keyed on the attacked resource, deduplication groups by destination, ticket automation opens one case per affected service, and tenant notification sends one message per affected customer. Carpet bombing turns one incident into thousands of simultaneous instances of all of those.

The volume arrives from two directions at once. The detection layer emits an event per destination object it considers affected. Independently, every device in the path that touches the traffic writes its own record of it.

The consequences are ordinary operational ones, which is exactly why they are damaging: ingest and licensing costs on a per-event or per-gigabyte SIEM tier, retention volume across the whole retention window, an alert queue in which the one useful signal is buried under thousands of near-identical siblings, and — in multi-tenant environments — an automated notification fan-out that reaches every customer in the block at once.

The requirement to write into an evaluation is therefore specific and easy to test: the detector must be able to emit one incident for the prefix, carrying the number of affected destinations and the vector breakdown as attributes, rather than one incident per destination. Ask to see the event stream during a test run, and measure events per minute and bytes shipped to the log pipeline as explicit test outputs. This is a measurable property, and products differ on it considerably.

Diversion, scrubbing and signalling

If your response is diversion to a scrubbing tier rather than filtering in place, carpet bombing changes the sizing arithmetic in three ways.

The unit you divert must cover every destination under attack, which in practice means the covering prefix. You are therefore diverting the block’s entire legitimate traffic as well as the attack, and the scrubbing path has to carry both. Sizing that assumed you would divert a single customer’s addresses does not survive.

Prefix-length filtering bounds how finely you can divert outside your own network. Other operators commonly decline announcements longer than a /24 in IPv4 or a /48 in IPv6. This is established operational practice rather than a standard, but its effect on you is binding: it determines the smallest unit of external diversion, and therefore the granularity at which your address plan needs to have been designed.

Concurrency assumptions break by construction. A carpet bomb across a shared block puts many tenants under attack in the same minute. Capacity models built on “one customer at a time” are not conservative here; they are simply describing a different attack.

The return path deserves the same attention it always does. The diverted prefix now contains the addresses to which clean traffic must be delivered, so the return route has to be isolated from the diversion announcement — through a tunnel, a separate routing instance or policy-based routing on the handback router — and the tunnel endpoints must sit outside the diverted range.

Where mitigation is requested across an organisational boundary, the scope question shows up in the signalling as well. The DOTS architecture in RFC 8811 and the signal channel in RFC 9132 allow a mitigation request to be scoped by target prefix and port range rather than by a single address, which is exactly the expressiveness this attack requires. Signalling that can only name a host cannot describe what is happening.

Product criteria, and what to require in a proof of concept

Everything above collapses into a short list of properties. A product that has them will handle this attack shape; a product that lacks them will not, whatever the datasheet claims.

1. Counters and baselines maintained hierarchically, with the sub-block, the routed prefix and the tenant as first-class objects rather than derived views.
2. Alarming on distinct-destination counts and on traffic to unused addresses, not on volume alone.
3. Mitigation expressible as one policy over a prefix, rather than as many policies over many addresses.
4. Bounded and predictable resource consumption as destination cardinality rises, with a stated limit and a stated behaviour at that limit.
5. Event output aggregated per incident, carrying affected-destination counts as attributes.
6. In shared infrastructure, per-tenant policy and per-tenant reporting on the same hardware, so that a prefix-level incident can still be explained to each customer individually.

Those last two criteria are where multi-tenant operators tend to find the real differences, and they are worth putting to every shortlisted vendor as a demonstration rather than a question. The criteria matter more than the supplier, because a product that cannot express a mitigation over a prefix will generate an unmanageable configuration long before it generates a saved service.

The test itself

A proof of concept that does not do the following has not tested carpet bombing:

• Build the test on your own address plan, using the prefix length you actually operate and route, not a convenient lab /29.
• Fix the per-destination rate below the device’s configured per-host trigger, and have the vendor confirm that trigger’s value in the running configuration before the run starts. Write both numbers into the test record.
• Run the aggregate at two levels: the device’s rated throughput, and your real circuit rate. They test different things.
• Use the smallest packet size the vector allows, and record packets per second alongside bits per second. Small-packet attacks reach processing limits long before they reach bit-rate limits.
• Rotate the destination subset faster than the detector’s observation window. This is the variant that separates products, and it is the one most likely to be omitted from a vendor-run demonstration.
• Include addresses with no service behind them, and confirm that the system counts and reports them.
• Record time to detect from the first attack packet, time to mitigate, and which counter fired at which aggregation level. The last of these is the finding that matters; a product that detected by accident at circuit level has not demonstrated prefix-level detection.
• Count the mitigation objects created. One for the prefix, or one per destination.
• Measure events per minute and bytes emitted to the log pipeline during the run.
• Run legitimate traffic to the same prefix throughout, and measure its completion rate and latency. “Attack blocked” without a false-positive measurement is not a result.
• For out-of-path designs, feed the detector telemetry at your production sampling rate and export timers, not an unsampled lab feed, and compare time-to-detect between the two. The difference is your real detection latency.
• Run the same attack through your stateful perimeter with and without the mitigator in front, and record session-table occupancy on the firewall in both cases. That measurement is usually the most persuasive artefact the exercise produces.
• Exceed the stated destination-tracking limit deliberately and record what the device does.
• Test recovery: withdraw the attack, confirm mitigation is released, then resume it on a different subset of the same block and confirm it re-engages without manual intervention.

Ask for every resulting number in writing, tied to the specific model and software version tested, and reproduce the ones you can in your own lab. The gap between a product that aggregates properly and one that does not is not subtle, and a test built this way makes it visible in an afternoon.

Sources and further reading

The documents below are the primary references for the mechanisms discussed. The only numeric example in this article is explicitly labelled as illustrative arithmetic and should be recomputed with your own address plan and telemetry.

Routing responses. BGP FlowSpec for IPv4 is RFC 8955 and for IPv6 RFC 8956; the validation procedure and the supported match and action sets are defined there, and your platform’s hardware-supported subset should be confirmed separately with the vendor. Remotely triggered black hole filtering, including the source-based variant with unicast reverse-path forwarding, is RFC 5635; the earlier destination-based technique is described in RFC 3882, and the well-known BLACKHOLE community is RFC 7999. For general BGP operational and security practice, RFC 7454 (BCP 194).

Flow telemetry. The IPFIX protocol is RFC 7011 and its information model RFC 7012; NetFlow version 9 is documented informationally in RFC 3954. Packet selection and sampling techniques are covered in RFC 5475, with the PSAMP protocol in RFC 5476. The current version of sFlow is an sFlow.org specification rather than an IETF standard; RFC 3176 documents only an earlier version, informationally.

Signalling mitigation across a boundary. The DOTS architecture is RFC 8811 and the signal channel RFC 9132. The scoping attributes in the signal channel are the relevant part here: they allow a request to name a target prefix and port range rather than a single address.

Source address validation. RFC 2827 (BCP 38) and RFC 3704 (BCP 84) remain the baseline for ingress filtering. They do not mitigate carpet bombing against you, but they are what limits your own network’s ability to source the spoofed traffic that makes reflection vectors work.

Vendor documentation to request. For each shortlisted product, ask in writing for the maximum number of tracked destination objects per system and per protected object, the behaviour when that limit is exceeded, the granularities at which counters and baselines are maintained, the maximum number of hardware-installed filter rules on the specific line cards you operate, and the event-aggregation behaviour during a multi-destination incident. These are the numbers that predict behaviour under this attack, and they are rarely on the datasheet.