Handling of Overlapping IPv6 Fragments
draft-ietf-6man-overlap-fragment-03

INTRODUCTION, paragraph 2:
>                  Handling of overlapping IPv6 fragments

  Imprecise title. This ID isn't about handling such fragments, it's
  about forbidding them.


Section 4.5, paragraph 0:
>    This document explores the issues
>    that can be caused by overlapping fragments.

  Last sentence should add the "and updates 2460..." bit from the
  abstract.


Section 3., paragraph 11:
>    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.

  Stateful firewalls are called stateful because they track the
  transport protocol connection state. So a stateful firewall would
  *only* pass this packet *if* it was actually in response to a prior
  SYN in the opposiute direction. So I don't quite see how this attack
  is feasible.


Section 4., paragraph 1:
>    IPv6 nodes transmitting datagrams that need to be fragmented MUST NOT
>    create overlapping fragments.  When reassembling an IPv6 datagram, if
>    one or more its constituent fragments is determined to be an
>    overlapping fragment, the entire datagram (and any constituent
>    fragments, including those not yet received), MUST be silently
>    discarded.

  I agree that it must be discarded, but whether this is done silently
  is clearly a management decision of the local stack.


Section 5., paragraph 1:
>    This document discusses an attack that can be used to bypass IPv6
>    firewalls using overlapping fragments.  It recommends disallowing
>    overlapping fragments in order to prevent this attack.

  Imprecise language: It doesn't just "recommend" it, it makes it a
  requirement.

  The Gen-ART Review by Francis Dupont on 29-Oct-2009 included a few
  editorial suggestions:

  - page 1: allows -> does not disallow??

  - page 2: Acknowledgements -> Acknowledgments

  - page 3: the term 'check' is not enough because it is for protection,
    something like 'security check' should be better (but a bit too
    strong).

 - page 5: it is possible to get bad overlapping fragments from an error
   too (i.e., it is not always an attack, of course the action should be
   to drop the whole packet anyway).

 - page 6: received), MUST -> received) MUST?

 - page 6: Acknowledgements -> Acknowledgments