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
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 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.
(Pasi Eronen) (was Discuss) No Objection
(Adrian Farrel) (was Discuss) No Objection
(Russ Housley) No Objection
Comment (2009-11-16)
No email
send info
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 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