Skip to main content

Handling of Overlapping IPv6 Fragments
RFC 5722

Yes

(Jari Arkko)
(Ron Bonica)

No Objection

(Adrian Farrel)
(Alexey Melnikov)
(Cullen Jennings)
(Dan Romascanu)
(Lisa Dusseault)
(Magnus Westerlund)
(Pasi Eronen)
(Ralph Droms)
(Ross Callon)
(Tim Polk)

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

Lars Eggert (was Discuss) No Objection

Comment (2009-11-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.

(Jari Arkko; former steering group member) Yes

Yes ()

                            

(Ron Bonica; former steering group member) Yes

Yes ()

                            

(Adrian Farrel; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Alexey Melnikov; former steering group member) No Objection

No Objection ()

                            

(Cullen Jennings; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Dan Romascanu; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Lisa Dusseault; former steering group member) No Objection

No Objection ()

                            

(Magnus Westerlund; former steering group member) No Objection

No Objection ()

                            

(Pasi Eronen; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Ralph Droms; former steering group member) No Objection

No Objection ()

                            

(Ross Callon; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) No Objection

No Objection (2009-11-16)
  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

(Tim Polk; former steering group member) No Objection

No Objection ()