IP Fragmentation Attacks

IP fragmentation exists so that a packet too large for a link can cross it in pieces, to be reassembled at the destination. Reassembly requires the receiver to hold what it has until the rest arrives.

That obligation is the attack. A receiver cannot know whether the missing pieces are late or were never sent, so it must wait — and waiting means memory.

At a glance

Appliance	Variant	What it does	What it costs the receiver
Incomplete fragments	Sends first fragments, never the rest	Reassembly buffer held until a timer expires
Overlapping offsets	Fragments whose ranges conflict	Ambiguity a parser must resolve, historically unsafely
Tiny fragments	Splits a header across fragments	Inspection cannot match on fields it cannot see
Out-of-order floods	Arrives with first fragments last	Buffers held longer, worst-case reassembly behaviour

The third row is the one that matters beyond availability: it is an evasion technique as well as an exhaustion one.

What it exhausts

Reassembly buffers. Finite, per-host or per-device, and held for the duration of a timer that is typically measured in seconds. An attacker sending first fragments at modest rate can occupy the buffer continuously.

Parser effort. Overlapping and out-of-order fragments force the worst case in reassembly code: sorting, comparing and resolving conflicts rather than appending.

Inspection capability, which is the second-order effect. A device that inspects fragments independently loses the ability to match on transport fields, so an attacker uses fragmentation to carry traffic past a filter. A device that reassembles first keeps the capability and spends memory for it, which returns to the first item on this list.

Bandwidth is not the resource. Fragmentation attacks succeed at rates that look unremarkable on any bit-rate graph.

How it differs from similar attacks

A SYN flood exhausts connection state and is answered by refusing to allocate it until a client proves it exists. There is no equivalent proof available here: fragments carry no handshake, so the receiver cannot distinguish an attacker’s first fragment from a legitimate one until the timer expires.

The historic named attacks — teardrop, ping of death — were crashes caused by specific parser defects and are fixed. What remains is the structural cost, which cannot be patched away because it follows from the specification.

Observable telemetry

• Reassembly failures and timeouts rising, which is the diagnostic counter and is exported by most stacks.
• Fragment rate rising against a flat bit rate.
• A high proportion of first fragments to subsequent fragments, which normal traffic does not produce.
• Memory pressure on devices that reassemble, with no change in session counts.
• On Linux, the fragmentation counters in the network stack rather than anything on an interface graph — the tuning surface is covered in network stack tuning.

Common false positives

Tunnelled traffic. VPNs and encapsulation reduce the effective MTU, so genuine fragmentation appears in estates that use them heavily.

Large DNS responses over UDP, particularly with DNSSEC, which is one of the few remaining places where fragmentation is routine rather than accidental.

A path MTU change. A routing change can produce a burst of legitimate fragments from traffic that previously fitted.

All three argue for measuring your own fragment rate before applying any rule that discards fragments.

Mitigation by layer

Measure first, then consider dropping. Many estates fragment almost nothing, and for them discarding fragments at the edge is cheap and safe. RFC 8900 supports the direction; your own measurement decides whether it applies to you.

Rate-limit fragments where they cannot be dropped, per source and in aggregate.

Discard malformed fragments by signature: overlapping offsets, impossible lengths, first-fragment-too-small. These have no legitimate counterpart, so the rule carries no false-positive risk.

Reduce the reassembly timeout carefully. It frees buffers sooner and breaks legitimate traffic on slow paths, which makes it a measured change rather than an emergency one.

Confirm PMTU still works after any change, because the failure mode is a hang rather than a refusal and will be attributed to the application.

Operational pitfalls

Dropping fragments without measuring. The failure appears days later as an intermittent problem with one protocol nobody associated with the change.

Tuning reassembly memory upward as the only response. It raises the ceiling the attacker must reach and does not change the economics, since their cost per held buffer remains one small packet.

Assuming inspection sees fragmented traffic. Confirm whether your devices reassemble before inspecting, because the answer determines whether fragmentation is an evasion path through your estate.

Safe validation

Send first fragments without their remainder at increasing rate, and watch reassembly timeout counters and memory rather than interface graphs. Record the rate at which reassembly begins failing — that is the number, and it is usually far below anything on the device’s datasheet.

Then repeat with a fragmented but complete flow to confirm your rules did not break legitimate fragmentation, and with a fragmented packet whose transport header spans a boundary to establish whether your inspection still matches on it.

Isolation and authorisation requirements are in the test lab guide and authorised testing.