[secdir] Review of draft-ietf-6man-ipv6-atomic-fragments-03

[Simon Josefsson <[e-mail]>]

I've reviewed draft-ietf-6man-ipv6-atomic-fragments-03.txt and believe
the document is "Ready with nits".  From a security perspective, one
could desire more discussion in the document but I do not believe
significant attention is required.

Document summary: The document is about special kind of IPv6 fragment;
a fragment that claim to be offset 0 of the payload and also to be the
last fragment.  The document says that those fragments can be
reassembled without waiting for any other fragment.  The document is
another tweak for the IPv6 fragmentation rules.

/Simon

Caveat: I'm not an IPv6 expert so the issues below may just be due to my
misunderstanding of how things work.  A sufficient response to some of
the issues below may just be that I got it all wrong, although if that
is the case, some explanation for my education would be appreciated.

MINOR ISSUES:

1) The document does a good job describing how attackers can trigger
atomic fragments, which makes it possible to apply fragmention-based
attacks to normal traffic.  But there is no details about
fragmentation-based attacks, neither what is gained nor how they are
mounted.  It refers to informational documents
[I-D.gont-6man-predictable-fragment-id] and [CPNI-IPv6] for the
attacks, which I have not reviewed.  Thus the abstract's claim that
"the document discuss [...] the corresponding security implications"
seems erradic since the discussion does not happen in this document.
The Security Considerations does not describe any complete attack
either.

It is possible, perhaps likely, that fragmentation-based attacks are
well-known to anyone working with IPv6 that they do not need to be
explained in this document.  As an out-sider, though, I was left with
the feeling that the attack this document attempts to protect against
is not actually described.  If a short description of one complete
attack could be added, that would have helped me.

2) 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.

3) As a consequence of the previous point, I'm left uncertain about how
the updated rule interacts with the requirements in RFC 5722 about
overlapping fragments.  If overlapping payloads should cause packets to
be dropped, this is no longer the case if atomic fragments are "let
through" the fragmentation logic.

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

5)
   o  Upon receipt of one of the aforementioned ICMPv6 "Packet Too Big"
      error messages, the Destinations Cache is usually updated to
                          ^^^^^^^^^^^^^^^^^^
      reflect that any subsequent packets to such destination should
      include a Fragment Header.  This means that a single ICMPv6

Where is "Destinations Cache" defined?  The phrase does not have any
specific meaning to me, and I cannot find it in any of the normative
references.  The use of upper case suggests to me that some well
defined meaning is intended.  Without understanding that term, I don't
follow the rest of the paragraph.

6)
      Additionally, if any fragments with the same set {IPV6 Source
                                                          ^
Typo, 'v'.