All DDoS Definitions
DDoS Testing Definition

IP Fragmentation Attack

Unlike a teardrop attack, which crashes a host with a single deformed fragment, an IP fragmentation attack needs no software bug at all: it exhausts the reassembly path with fragments that simply never complete. It is one of the protocol-abuse classes a thorough DDoS test is built to exercise, and it is the broader surface the crash-style fragment attacks are a special case of.

IP fragmentation attack: datagrams that never finish reassembling Attacker sends IP fragments frag 1 of 3 frag 2 of 3 final piece: never sent partial fragments Reassembly buffer holds fragments until complete datagram A: incomplete datagram B: incomplete datagram C: incomplete buffer fills, memory exhausted legit traffic dropped Origin stalls under load A modest packet rate exhausts kernel reassembly memory: the cost lands on state, not bandwidth A test characterizes how the host, firewall, and inline middlebox handle malformed and incomplete fragments under sustained pressure. BlackNeuron™
IP fragmentation attack: fragments that never complete force the target to hold each partial datagram in its reassembly buffer until memory is exhausted

How an IP fragmentation attack works

Fragmentation is a normal part of IP: when a datagram will not fit the next link, the sender chops it into pieces, each tagged with the byte offset where it belongs and a flag marking whether another piece follows. The receiver cannot act on any of it until the whole datagram is back together, so it holds every fragment it has, keyed by source, destination, protocol, and IP identification, until the last piece arrives or a timer expires.

That holding pen is the target. Send a stream of first and middle fragments and never the final one, and each incomplete datagram sits in the reassembly buffer waiting for a piece that is never coming. On Linux that memory is bounded by ipfrag_high_thresh and each partial set is held until ipfrag_time elapses, so an attacker who keeps the buffer topped up forces the kernel to drop whole reassembly queues, legitimate ones included. As a protocol attack the pressure lands on a finite state resource rather than on bandwidth, which is why a modest packet rate is enough.

There is a second edge that makes fragments useful to an attacker. Only the first fragment of a datagram carries the transport header with its port numbers, so the non-first fragments cannot be classified by a port-based ACL. A stateful firewall must either pass them blind or reassemble on the host's behalf, and reassembling is exactly the expensive work the attack is trying to provoke.

IP fragmentation attack: the reassembly buffer fills Incomplete fragments IP reassembly buffer each partial datagram held until its reassembly timer expires ipfrag_high_thresh whole queue dropped Measured in reassembly memory held, not link utilisation BlackNeuron™
Animated IP fragmentation attack: incomplete fragments each claim a slot in the reassembly buffer and are held until their timer expires, until the buffer is full and the whole queue is dropped

Why it matters under attack

The failure is quiet. A link with ample headroom stays green while the reassembly buffer fills, and the first symptom is legitimate fragmented traffic being dropped, not a slow page or a saturated pipe. Teams instrumented for volume watch nothing move.

Where the reassembly happens decides where it fails. The origin kernel is only one candidate; a firewall, a load balancer, or any middlebox that reassembles on the host's behalf runs its own implementation with its own buffer, and the smallest of those sets the ceiling for the whole path. The device that gives way is often the one in front of the server, not the server itself.

This is deliberately the resource-exhaustion cousin of the crash-style fragment attacks. Teardrop corrupts reassembly arithmetic with overlapping offsets and the ping of death overflows it with an oversized total; a fragmentation flood does neither, it just holds memory. It is the same reassembly code under attack, but starved rather than tricked, so the three live in one family yet demand separate test cases.

What a DDoS test measures

A test characterises how the host, firewall, and any inline middlebox behave as incomplete and malformed fragments arrive faster than the buffer can clear. It measures the reassembly-buffer ceiling, whether fragment-drop policies and reassembly timers hold under sustained pressure, and whether non-first fragments are handled sanely rather than passed blind past a port-based rule.

Because the cost lands on infrastructure state rather than the wire, this belongs in the protocol-resilience portion of a test, not the bandwidth portion. Understanding DDoS Attack Vectors puts it next to the crash-style fragment vectors it is usually confused with.