Introduction
Carpet bombing attacks have proliferated in 2026 and are a concern for networks of all sizes. This leads many to consider them a zero-day DDoS, but that is not strictly true. Underlying this new attack is conventional methodology: carpet bombs consist of the same spoofed volumetric floods that RioRey systems already detect and mitigate–but distributed across a prefix rather than concentrated on a single host.
Thus, what seems new about carpet bombing is not the attack methodology itself, but what you see happening. Or rather, what you don't see, which masks the attack. The carpet bomb flood, divided across 256 addresses, is built to stay under every per-host view you have, so the challenge it presents for DDoS defense is one of visibility and reporting, not of detection or mitigation. For a RioRey deployment that distinction is the whole story: our filtering already runs per destination IP - and, where a single address hosts several applications, per application on that address - regardless of how many hosts are involved. What needs adjusting is the prefix-level view of a mitigation that is already taking place. That is also why the problem is tractable. A reporting gap is a far smaller thing to close than a missing attack class.
How carpet bombing works
In a conventional DDoS, the entity under attack is a specific host. All attack traffic focuses on overwhelming that host. Carpet bombing differs because the attacker's flood is distributed across many destination addresses within a target prefix, rather than concentrated on a single victim IP. A /24 gives an attacker 256 targets, while larger prefixes give more.
The traffic itself is unremarkable. A SYN flood spread across 256 addresses is a SYN flood. What changes is that no single destination crosses the threshold at a volume that would normally make it obvious, while the aggregate still arrives at the same place because routing condenses–and only at that point is the problem recognized.. All traffic destined for a prefix eventually converges on a common upstream link, a common router, or a common firewall. The individual hosts may never notice anything wrong at all, but the router in front of them may fail, or the link may saturate under the total sum of attack traffic it is carrying. Carpet bombing is a network congestion attack rather than a host resource attack.
Why dispersed victim addressing defeats conventional defenses
The difficulty posed by carpet bombing is not just the visibility itself, it is the mitigation action that comes after detection. DDoS defense systems relying on rate limiting alone are likely to be ineffective with carpet bombing.
Rate limiting is a common tool, but it is generally a per-host construction. Some flow-based detection systems do support prefix thresholds alongside host thresholds, so the aggregate arriving at a /24 is observable in principle. But a prefix threshold is not the host threshold multiplied by the number of hosts. The addresses behind a prefix run different applications with different traffic patterns, and their baselines move independently. A /24prefix with a video service, a mail server and a set of low-traffic customers has no single aggregate figure that is both tight enough to catch a flood divided 256 ways and loose enough to survive a normal peak on any one of them. The further those applications diverge, the harder it becomes to use thresholds to defend against carpet bombing.
Thresholds have a second limitation for mitigating carpet bombing. A crossed prefix threshold tells you the /24 is in trouble without telling you which traffic inside it to drop. This is a structural failure rather than a tuning failure, and the distinction matters because it tells you that lowering thresholds will not fix it. Tighter limits convert a detection gap into a false-positive problem, since the traffic level to each host is independent and variable.
Even the "nuclear option" of blackholing faces the same challenge. Null routing a single address under attack is a routine last-resort option. Null routing a /24 to stop an attack is more than a step further, and not easily done without significant client pushback.
Stateful inspection does not solve this either. A device that tracks sessions is bounded by its ultimate capacity to track, and every flow it actively interferes with adds latency. Distributing an attack across a prefix multiplies the number of things to track, precisely the resource a stateful device is already spending, and turns them into a likely congestion point.
What it looks like to our methodology-based attack identification system
Looking at the RioRey DDoS Taxonomy reveals no attack class labeled specifically as carpet bombing, and this is by design.
The RioRey Taxonomy classifies attacks by method, and by method we mean what the traffic does to the protocol, and which resource it exhausts. A SYN flood is AT1 whether it lands on one address or 256, and whether that address hosts one application or shares its traffic with several. The generation technique, the botnet, the tool name, the address distribution and the number of applications behind an address are all variables. The method is not.
In the field, carpet bombing shows up almost entirely as spoofed volumetric floods. AT1, AT2, AT3 and AT9 on TCP, AT17 on UDP. ICMP is rare. These are classes RIOS already mitigates, and the mitigation logic does not need to be told the attack is distributed.
RIOS detects attack traffic by its behavior and flow characteristics, not by destination thresholds. For TCP attacks it does not matter whether one IP or a whole prefix is under attack, nor whether a targeted address carries a single service or several; what matters is the traffic behavior of each flow, and that does not change with the number of hosts or applications involved. The flood to one application is resolved and filtered without disturbing legitimate traffic to a service co-hosted on the same address. For UDP and ICMP attacks RIOS does use user-configurable thresholds to identify traffic that needs further examination, but these thresholds are primarily a mechanism of focus, not of mitigation. UDP and ICMP attack mitigation uses traffic behavior, flow distribution, entropy and payload analysis to identify and filter attacks, and these methods are independent of the number of hosts or prefixes under attack.
Why the size of the pipe(s) changes what detection can see
How much of an attack a filtering device can observe contributes to how quickly it resolves the attack. Carpet bombing is designed to reduce that per-detection or per-filtering-instance visibility to a fraction.
A 10G link with one appliance in front of it has exactly one filtering instance. That appliance sees every packet destined for the protected prefix, so a carpet bombing spread across a /24 arrives whole. All 256 destinations, all of their traffic, one device. This is close to the easiest case, because the dilution the attacker engineered is undone by the topology.
A scrubbing center or off-ramp mitigation is the opposite because traffic arrives across multiple ingress points and is distributed across multiple filtering devices. If five devices each absorb a fifth of the same attack, each is reasoning from a fifth of the evidence for each destination address. Conclusions take longer or are never reached. The attack was already diffuse, and the scrubbing center deployment diffuses it again.
The consequence is that concentration becomes a useful defensive move. Where you can route an attacked prefix through fewer filtering points, you should. Withdrawing a prefix announcement from some upstreams in order to condense traffic onto a single device is an unglamorous operation that materially improves what that device can resolve. Most operators reach for this lever during an event; however, it works considerably better if planned ahead.
What this means for how you deploy
In a RioRey deployment, detection and mitigation are automatic and run per destination IP — and per application where an address hosts several — regardless of configuration. Nothing below changes that; the flood is already being filtered. What follows are operator-side decisions about visibility, topology and escalation, and each addresses the gap this piece opened with: not whether carpet bombing is mitigated, but whether you can see the mitigation happening at the level the attack is organized.
Ensure something in your monitoring sums the prefix.
The prefix-level view is the piece worth setting up in advance. If your monitoring is organized per host, or per small group of addresses, a carpet bombing is unremarkable everywhere you look because each address shows a modest bump in traffic and none of them looks like an incident. You need at least one view that aggregates across the prefix, and you need it in place before you go looking, since an attack designed to stay under per-host attention is precisely the attack you will not think to search for once it starts.
Keep filtering condensed where topology allows.
This is a routing decision, and it matters for a narrower reason than it first appears. Per-flow classification does not degrade when destinations are spread across devices: a device that sees a whole flow classifies it correctly whether it is handling one destination or a thousand. What condensing buys you is different, and it is two things.
The first is congestion. Carpet bombing is an aggregate attack, and the aggregate has to land somewhere with the headroom to carry it. Scattered across several links and filtering points, each point drops its own slice cleanly while the sum can still saturate a shared upstream. Pulling the prefix onto fewer devices puts the drop where there is capacity for the whole volume. The second applies to UDP and ICMP, where detection reasons from flow distribution, entropy and payload across a destination's traffic: a device working from a fuller sample resolves faster than one reasoning from a fraction of it.
Withdrawing a prefix from some of your upstream announcements is ordinary BGP work. The difficulty is doing it under pressure, on a prefix you have not thought about, while an interface is filling. RioRey recommends deciding in advance which prefixes you would concentrate on, onto which device, whether that device has the headroom for the full volume, and who is authorized to make the announcement change. Written down beforehand, this is a five-minute response. Improvised, it is an hour spent finding out who owns the router. For RioRey users the same logic governs where to filter in the first place: an attack arriving whole at one appliance is the easiest case you will get, and that is worth weighing against the instinct to distribute filtering evenly across your edge.
Trigger on dominance, not volume.
Absolute thresholds are hard to set on a prefix, for the reasons above. A relative test is easier to reason about: when an interface passes a level of concern, ask which segment of traffic is disproportionately responsible for the load, rather than which segment is largest in absolute terms. That distinction is what keeps a legitimate high-volume customer from being treated as the problem.
RioRey implements this through the Director. For carpet bombing, the most useful mode is Director's interface workflow: it monitors an interface, and once the interface passes a level of concern, it buckets the traffic by /24 and identifies the segment accounting for a defined share of the total: ten percent, or whatever suits your network. This is deliberately zone-agnostic. A high-volume client serving video is large but not dominant, so Director does not trigger. A /24 absorbing a flood is dominant, so it does.
Where we are
RioRey users handling this today have two levers. Off-ramp and scrubbing-center operators can concentrate traffic onto fewer filtering points, and use Director or other netflow tool to automate the response once an interface begins to saturate. RIOS provides automatic detection and filtering regardless of the number of hosts under attack; what it does not yet do is aggregate that information into a single view of the entire prefix under attack.
Our engineering directive moving forward is making the reporting of standard mitigation more sensitive to the conditions carpet bombing creates..
Our work in this respect does not revolve around a new attack class, a new detection module, or a signature update. An AT1 Syn Flood flood spread across a prefix is still an AT1. Our identification of the underlying methodology was already correct, rather it is our sensitivity and manner of reporting that needs adjusting.
Carpet_Bombing_Brief_V1.3