How it works
A distributed source set sends far more traffic than the destination, or some device on the path toward it, can process. The payload is usually irrelevant; the cost is carried in bandwidth, packets per second, or the CPU spent validating malformed traffic.
Why Layer 3 floods still work
Layer 3 attacks are the least sophisticated category in this wiki and remain among the most effective. They do not need a vulnerability, a valid session, or any understanding of the application. They need only to put more traffic onto a path than that path can carry.
That distinction matters because it determines where the attack can be stopped. Once a 10 Gbps circuit is carrying 40 Gbps of attack traffic, every packet that matters has already been discarded by a router upstream of the destination. No firewall rule, rate limit, or application change at the destination can recover traffic that never arrived. This is the single most important operational fact about volumetric attacks, and the one most often learned during an incident rather than before it.
The practical consequence is that defence against this category is largely a procurement and architecture decision made in advance: transit capacity, anycast footprint, and a scrubbing arrangement with an upstream provider. The runbook matters, but it mostly describes who to call.
ICMP floods
The oldest form sends ICMP echo requests, or any other ICMP type, at a rate the target path cannot absorb. Because ICMP is connectionless and requires no handshake, an attacker can emit it continuously with no cooperation from the destination, and can trivially forge the source address.
ICMP is genuinely useful and should not be blocked wholesale. Path MTU discovery depends on ICMP fragmentation-needed messages, and blocking them produces connections that complete a handshake and then silently stall on larger payloads — a failure mode that is very hard to diagnose. The correct posture is to permit the ICMP types your network actually needs and rate-limit the rest, rather than dropping the protocol entirely.
Fragmentation floods
IP fragmentation splits a packet too large for a link into pieces that the destination reassembles. Reassembly is stateful: the receiver must hold fragments in memory until the set is complete or a timer expires. That state is the resource being attacked.
An attacker sends large volumes of fragments that never complete — overlapping, out of order, or missing their final piece. The receiver allocates buffers for each incomplete set and holds them until timeout. The bandwidth required is modest compared with a straight flood, because the cost is memory and CPU rather than bits on the wire.
Overlapping fragments carry a second risk beyond exhaustion. Different operating systems historically resolved overlaps differently, which allowed an attacker to construct a fragment set that a firewall and the host behind it would reassemble into two different packets — one benign, one not. Modern stacks discard overlapping fragments outright, and network equipment should be configured to do the same at the boundary rather than passing them through for the host to adjudicate.
Encapsulation protocol floods: GRE and ESP
Not all IP traffic is TCP or UDP. GRE carries tunnelled traffic, and ESP carries the encrypted payload of an IPsec VPN. Both are ordinary IP protocols with their own protocol numbers, and both are frequently overlooked when access control lists are written.
This inattention is the point. Filtering policy is often specified in terms of TCP and UDP ports, and traffic that is neither may pass with far less scrutiny — or reach a tunnel-termination device that must attempt cryptographic validation before it can decide the traffic is worthless. That validation is expensive, which makes a modest packet rate disproportionately costly.
If your network terminates tunnels, the peers are known in advance. Allow GRE and ESP from those peers and drop the protocols elsewhere. If your network does not use them, filter them upstream, where the traffic is still cheap to discard.
Carpet bombing: spreading the load
Carpet bombing is a targeting strategy rather than a distinct protocol technique, and it exists specifically to defeat how most detection is configured. Rather than concentrating traffic on one address, the attacker spreads it across every address in a prefix.
Detection thresholds are usually set per host, because that is the unit an application team recognises. Traffic divided across a /22 may leave every individual host comfortably below its alarm threshold while the aggregate saturates the transit circuit all of those hosts share. The network is failing and no per-host alarm has fired.
The countermeasure is to baseline and alarm on aggregates — per prefix, per circuit, per upstream — in addition to per host. This also changes mitigation: scrubbing must be requested for the prefix, because diverting a single address accomplishes nothing when the load is distributed across hundreds.
Detection: what to instrument
Flow telemetry from border routers is the primary source. It shows the traffic your circuits are carrying, including the portion that will be dropped before reaching any server, which host-level metrics by definition cannot see.
Useful signals, roughly in order of how quickly they distinguish an attack from a traffic spike:
- Packets per second and bits per second per circuit, baselined by day of week and hour
- The ratio between the two — a collapsing average packet size usually indicates a packet-rate attack rather than genuine demand
- Protocol distribution, so an unexpected rise in ICMP, GRE, ESP or fragments is visible without a specific rule
- Fragment counts and reassembly failures, which rarely move for benign reasons
- Aggregate volume per destination prefix, to catch carpet bombing
- Source AS diversity — a legitimate traffic surge usually resembles your normal geographic mix, while an attack often does not
Mitigation: matching the control to the layer
Controls are only useful where the traffic still exists. Ordered from furthest upstream to closest in:
- Transit provider or scrubbing service — the only place a circuit-saturating flood can genuinely be resolved. Arrange this before you need it and confirm the activation path with a named contact.
- Anycast distribution — spreads a single logical destination across many sites so a flood is divided rather than concentrated, and a regional attack degrades only that region.
- Border filtering — drop unused IP protocols, malformed and overlapping fragments, and ICMP types your network has no use for, as early as possible.
- Capacity headroom — provisioning close to peak leaves nothing to absorb a surge. Headroom is not waste; it is the margin that keeps a moderate attack from becoming an outage.
- Host and application controls — largely irrelevant to this category. Traffic that reaches the host has already survived the parts of the path that matter.
Response priorities
The first task during a volumetric incident is to establish whether the bottleneck is upstream or local. If the circuit is saturated, engage the upstream provider immediately; everything else is secondary. If local equipment is failing while the circuit still has capacity, the attack is exhausting a resource rather than bandwidth, and the specific resource — fragment queues, tunnel termination, packet processing — determines the fix.
Record the attack characteristics as you go: protocol mix, packet sizes, source distribution, start time, and whether the pattern is steady or bursty. This detail is what an upstream provider needs to filter precisely rather than bluntly, and it is far harder to reconstruct afterwards.
Resist the temptation to change routing under pressure unless the change is already tested. Withdrawing and re-announcing prefixes during an incident is a common source of self-inflicted outage, and repeated route changes are exactly what a bursty attack is designed to provoke.
Common mistakes
Blocking ICMP entirely. This breaks path MTU discovery and produces intermittent failures that are far more disruptive than the attack being defended against.
Alarming only on individual hosts. Carpet bombing is specifically designed to stay under those thresholds, and aggregate visibility is the only thing that catches it.
Treating scrubbing as something to arrange during an incident. Contracts, contacts and activation procedures need to exist beforehand; discovering the process while a circuit is saturated costs hours you do not have.
Assuming a firewall helps. A firewall placed behind a saturated circuit is downstream of the problem, and a stateful firewall in that position frequently becomes the first thing to fail.
Also known as
What defenders may observe
- Circuit utilisation or packet rate rises sharply while application demand does not
- Loss and latency appear upstream of your own equipment
- Traffic arrives from many networks at once, often with implausible source addresses
- Fragment reassembly failures or unusual IP protocol numbers spike
Prevention and mitigation
- Buy or contract mitigation capacity upstream — a saturated circuit cannot be fixed at its far end
- Permit only operationally required ICMP types and IP protocols at the edge
- Drop malformed and overlapping fragments, and enforce reassembly limits
- Baseline and alarm on network prefixes, not just individual hosts
- Use anycast and capacity headroom to spread and absorb load
Initial response priorities
- Engage the upstream provider or scrubbing service.
- Preserve flow, edge and routing telemetry.
- Apply narrowly scoped filtering and validate legitimate reachability.
Use your approved incident-response plan and adapt decisions to your environment. This is educational guidance, not a substitute for live incident leadership.