Handling of Overlapping IPv6 Fragments
RFC 5722

Note: This ballot was opened for revision 03 and is now closed.

(Jari Arkko) Yes

(Ron Bonica) Yes

(Ross Callon) No Objection

(Ralph Droms) No Objection

(Lisa Dusseault) No Objection

Lars Eggert (was Discuss) No Objection

Comment (2009-11-03)
No email
send info
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

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

(Pasi Eronen) (was Discuss) No Objection

(Adrian Farrel) (was Discuss) No Objection

(Russ Housley) No Objection

Comment (2009-11-16)
No email
send info
  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

 - 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

(Cullen Jennings) (was Discuss) No Objection

(Alexey Melnikov) No Objection

(Tim Polk) No Objection

(Dan Romascanu) (was Discuss) No Objection

(Magnus Westerlund) No Objection