Processing of IPv6 "Atomic" Fragments
draft-ietf-6man-ipv6-atomic-fragments-04

My DISCUSS is solved by the RFC editor note. Thank you.

1) I tend to agree with Stephen's suggestion wrt the abstract.

2) s4: I think it would be clearer if you said:

  Section 4.5 of [RFC2460] and Section 4 of [RFC5722] are updated to include
  the following new checks:

This draft is just adding new checks right ;)


From Simon's secdir review (https://www.ietf.org/mail-archive/web/secdir/current/msg03710.html):

3) Section 2:
      Offset set to 0 and the M bit set to 0.
                                ^^^
RFC 2460 uses the term "M flag", not "M bit".

4) s3, 2nd bullet: is it's the "Destination's Cache" or is just the queue?

5) s4: For consistency: r/{IPV6/{IPv6

6) s4: This is actually more of a question about the new rule text.  I'm having trouble understanding what should happen in the following situation:

 * A host has a fragment with fragment identification X in its cache,
   with fragment offset 42 and M=1 indicating there are other
   outstanding fragments.

 * A host has received an atomic fragment (i.e, fragment offset 0 and
   M=0) with the same fragment identification X.

 * A host never receives any more fragments with the fragment
   identification X.

RFC 2460 says:

      If insufficient fragments are received to complete reassembly of a
      packet within 60 seconds of the reception of the first-arriving
      fragment of that packet, reassembly of that packet must be
      abandoned and all the fragments that have been received for that
      packet must be discarded.  If the first fragment (i.e., the one
      with a Fragment Offset of zero) has been received, an ICMP Time
      Exceeded -- Fragment Reassembly Time Exceeded message should be
      sent to the source of that fragment.

Now given the following updated text in section 4:

      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}.

The atomic fragment should be dealt with in isolation, so it is reassembled immediately.  Now, after 60 seconds, what should the host do?  Should it send an ICMP Time Exceeded or not?  It has already completed assembly but it is also waiting for more fragments.

- The abstract tries, but fails, to explain how some attacks
are enabled via atomic fragments. I mean the "Thus..."
sentence, which cannot be understood by itself and is not a
good thing to have in an abstract

- Section 4 here is not clear as to what changes in 2460 and
5722.

- Section 6 says "this document describes..." but it doesn't;
you have to read 5722 or other references to actually
understand the threat.

- In the light of the above I would suggest rewording the
abstract to something more like this:

The IPv6 specification allows packets to contain a Fragment
Header without the packet actually being fragmented into
multiple pieces (we refer to such packets as "atomic
fragments"). Atomic fragments are typically sent by hosts that
have received an ICMPv6 "Packet Too Big" error message that
advertises a "Next-Hop MTU" smaller than 1280 bytes.  Atomic
fragments are processed by some implementations as "fragmented
traffic" whereas they ought properly be processed
independently of all other fragments since handling these as
non-atomic fragments can allow for expoitation of unrelated
vulnerabilities related to improper fragment handling.  This
document formally updates RFC 2460 and RFC 5722 such that
Atomic fragments are handled independently, thus avoiding
pitfalls related to fragment handling that can be set up via
"Packet Too Big" messages.