Transport Directorate review of
https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-atomic-fragments

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@ietf.org 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.