I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. Please always CC tsv-dir@xxxxxxxx if you reply to or forward this review.
Summary
-------------
This draft is on the right track but has issues, described in the review, that call for a bigger picture.
In addition to reading the draft, I read over the documents it references, and I also read through the AD Review thread about the 02 version of the draft, on the 6man mailing list.
It is clearly valuable to call the community's attention to the "atomic fragment" in IPv6. This is an IPv6 datagram that is not actually fragmented, but has a Fragmentation Header (with an offset of 0 and the M bit set to 0). It seems the atomic fragment in IPv6 arose to accommodate translation gateways with MTUs of less than 1280 (the IPv6 minimum) on the IPv4 side [1]. The problem is that you can force a sender to generate atomic fragments instead of normal packets from an off-path node, if the sender doesn't filter ICMPv6 much.
I've tried to make a schematic of the problem and solution described by the draft.
A is the IPv6 sender that either does not or cannot filter incoming ICMPv6 very well and that chooses Fragmentation IDs in a predictable way when it must fragment.
E is a blind attacker (or collaborating blind attackers), not on path/in the middle for A.
B is the destination for A's traffic. B initially doesn't distinguish between atomic fragments and normal fragments. However, B has implemented another solution [2], RFC 5722, which requires that IPv6 fragments be dropped silently if they overlap (have the same IDs and carry material from the same offset+fragment length).
ORIGINAL ATTACK
---------------------------
T0 A to B: v6-dgram --->
T1 E to A: ICMPv6 Too Big (MTU<1280)
T2 A to B: switch to v6-atomic-fragment, ID=X, Offset=0
T3 E to B: blind-inserted overlapping v6-fragment, ID=X, Offset=0
T4 B: A's T2 data should have gotten through. But E's T3 fragment forces silent drop.
DRAFT'S SOLUTION
-----------------------------
The draft says that B MUST process atomic fragments "in isolation", not in relation to the fragment queue. Further discussion in next section.
T'0-T'3: same as T0-T3 above.
T'4 B: receive and process A's atomic fragment, with no regard to E's insertion.
RESIDUAL RISK?
-------------------------
In the AD Review thread, Brian Haberman asks the "WG if the solution actually creates an attack vector on receiving hosts." A roll-up of the several-message exchange between Haberman and Fernando Gont, the draft author, can be found in http://www.ietf.org/mail-archive/web/ipv6/current/msg16807.html. From a Transport point of view, I agree that there could be a new attack vector on the receivers.
Consider first that E successfully got a spoofed fragment onto B's fragment queue. What if E turns that fragment into an atomic fragment. Post-mitigation, E's datagram no longer causes A's datagram to be blocked, but does the processing of E's atomic fragment "in isolation" introduce a greater chance than before that E's datagram can pass from B successfully to the ULP?
It depends on what processing an atomic fragment "in isolation" means specifically. The draft says this:
A host that receives an IPv6 packet which includes a Fragment
Header with the "Fragment Offset" equal to 0 and the "M" bit equal
to 0 MUST process such packet in isolation from any other packets/
fragments, even if such packets/fragments contain the same set
{IPv6 Source Address, IPv6 Destination Address, Fragment
Identification}. A received "atomic fragments" should be
"reassembled" from the contents of that sole fragment.
And this: Additionally, if any fragments with the same set {IPV6 Source
Address, IPv6 Destination Address, Fragment Identification} are
present in the fragment reassembly queue when the atomic fragment
is received, such fragments MUST NOT be discarded upon receipt of
the "colliding" IPv6 atomic fragment, since IPv6 atomic fragments
MUST NOT interfere with "normal" fragmented traffic.So now a receiver is forced to process an atomic datagram even if there are overlapping fragments already there on the fragmentation queue.
NEW ATTACK VECTOR
---------------------------------
T"0 A to B: v6-dgram --->
T"1 E to A: ICMPv6 Too Big (MTU<1280)
T"2 A to B: switch to v6-atomic-fragment, ID=X, Offset=0
T"2a B: deliver A's datagram to ULP
T"3 E to B: blind-inserted overlapping v6-atomic-fragment, ID=X, Offset=0
T"3a B: deliver E's overlapping datagram to ULP
T"4: B: TCP attack mitigated by RFC 5722 looks possible again [see Note 3].
Conclusion
---------------
There's an interesting table in the draft showing which sending stacks can be tricked into switching to v6-atomic-fragments and which receiving ones can be tricked into dropping them due to fragment overlap. Another way of looking at this table is that a lot of stacks need to be less predictable and more suspicious of spoofing traffic. The present draft is pragmatic/empirical and is interested in fixing a problem that exists (it can be brought on). But I wonder if it would be better to embed the discussion of atomic fragments and fragment overlap in a larger picture, a collected set of best practices against spoofers (of ICMPv6, of IPv6 fragments or otherwise). In the larger context, I agree that what's in this draft has a part - on its own, not sure it stands.
Notes
---------
[1] (Digression) I'd love to call for a Law of Kludges that says that if you are gatewaying two protocols, the one that is older should always be the one that graciously accepts the kludges; I'm not deeply enough into this all to understand why the gateway's IPv4 side needs the IPv6 side to supply it with a Fragmentation header - why it couldn't create fragments into IPv4 independent of the original IPv6?
[2] To a point problem...
[3] In RFC 5722, the crux of why B has to drop overlapping IPv6 fragments is these paragraphs:
The TCP header has the following values of the flags: S(YN)=1 and A(CK)=1. This may make an inspecting stateful firewall think that it is a response packet for a connection request initiated from the trusted side of the firewall. Hence, it will allow the fragment to pass. It will also allow the following fragments with the same Fragment Identification value in the fragment header to pass through. A malicious node can form a second fragment with a TCP header that changes the flags and sets S(YN)=1 and A(CK)=0. This can change the packet on the receiving end to consider the packet as a connection request instead of a response. By doing this, the malicious node has bypassed the firewall's access control to initiate a connection request to a node protected by a firewall.