Processing of IPv6 "Atomic" Fragments
updates
Extracted elements (14)
Processing IPv6 atomic fragments as regular fragmented packets (as done by many implementations) is the root cause of the attack vector: it allows malicious injected fragments to collide with legitimate atomic-fragment traffic in the reassembly queue. Processing atomic fragments in isolation completely eliminates this vector.
RFC 2460 Section 5 requires that when a host receives an ICMPv6 Packet Too Big message with a Next-Hop MTU smaller than 1280, it must include a Fragment Header in all subsequent packets to that destination rather than reducing packet size below the IPv6 minimum MTU. This enables IPv6-to-IPv4 translating routers to obtain a suitable Fragment Identification value for resulting IPv4 fragments.
RFC 5722 already forbade overlapping fragments (requiring silent discard of all fragments in a colliding set), but this rule paradoxically worsened the atomic-fragment attack: an attacker could forge a colliding fragment to cause an RFC 5722-compliant implementation to silently discard legitimate atomic fragments. Isolating atomic fragment processing supersedes this interaction.
As of October 2012, most popular operating systems (FreeBSD 8.2+, Linux 3.0, OpenBSD-current, Solaris 11, Windows XP/Vista/7) generate atomic fragments in response to ICMPv6 PTB with MTU < 1280, but only Linux 3.0, NetBSD-current, OpenBSD-current, and Solaris 11 implement the isolated-processing specification from this document. FreeBSD and Windows implementations remain vulnerable.
A host that receives an IPv6 packet with a Fragment Header where Fragment Offset equals 0 and M flag equals 0 MUST process that packet in isolation from any other packets or fragments, even if those packets share the same {IPv6 Source Address, IPv6 Destination Address, Fragment Identification} tuple.
If fragments with the same {IPv6 Source Address, IPv6 Destination Address, Fragment Identification} are present in the reassembly queue when an atomic fragment arrives, those fragments MUST NOT be discarded. IPv6 atomic fragments MUST NOT interfere with normal fragmented traffic.
An atomic fragment is reassembled solely from its own contents. The Unfragmentable Part consists of all headers up to but not including the Fragment Header. The Next Header field of the last unfragmentable header is taken from the Fragment Header's Next Header field.
Fragment reassembly matching uses the tuple {IPv6 Source Address, IPv6 Destination Address, Fragment Identification}. Under the updated rules, atomic fragments (Fragment Offset=0, M=0) must never be matched against or interfere with entries in the reassembly queue sharing this tuple.
IPv6 atomic fragments are IPv6 packets that contain a Fragment Header with the Fragment Offset set to 0 and the M flag set to 0. They are not actually fragmented into multiple pieces but carry Fragment Header metadata used by IPv6/IPv4 translators.
A single forged ICMPv6 Packet Too Big error message updates the Destination Cache to prepend a Fragment Header on all subsequent packets to that destination, potentially affecting multiple concurrent communication instances such as TCP connections to the same IPv6 address.
An attacker can forge ICMPv6 Packet Too Big messages advertising a Next-Hop MTU smaller than 1280 to remotely trigger atomic fragment generation in target hosts. The attacker can then forge fragments with matching {IPv6 Source Address, IPv6 Destination Address, Fragment Identification} tuples that get incorrectly reassembled with the atomic fragment, causing packet drops or enabling firewall bypass.
Many implementations fail to perform the validation checks on received ICMPv6 error messages recommended in RFC 4443 Section 5.2. For connectionless transport protocols encapsulated in IPv6, such validation may be virtually impossible, making the forged-PTB attack vector particularly difficult to mitigate at the ICMPv6 layer.
Some IPv6 implementations employ predictable Fragment Identification values, which significantly improves an attacker's chances of successfully crafting colliding fragments in a fragmentation-based attack against atomic fragment traffic.
The Payload Length of a reassembled atomic fragment packet is computed by subtracting 8 (the length of the Fragment Header) from the Payload Length of the received atomic fragment. The Fragment Header itself is removed from the reassembled result.