RE: I-D Action: draft-ietf-6man-ipv6-atomic-fragments-01.txt

Hello Fernando,

A couple of quick comments:
- section 2: I would love to have data to back the point of 'Many implementations fail to perform validation checks on the received ICMPv6 error messages' (such as adding a reference to your appendix)
- section 3: it would be nice to add some text about the case where a packet is duplicated by the network (could occur in rare circumstances) and one copy is fragmented (not an atomic fragment) and the other copy is not (atomic fragment) because of different path
- section 3: not sure what is meant by 'FH should (no uppercase?) be removed by the receiving host', on the contrary, I would prefer to keep the FH in the packet (some apps may need it) but immediately deliver the full packet to the upper layer
- section 3: it would be nice if some explanations were given why a host receiving such an atomic fragment should not discard the matching real fragments... I tend to believe that upper layer (TCP notably) will reject the second one if the sequence number match

May I also suggest to integrate this I-D into the more generic draft-gont-6man-predictable-fragment-id ? It will make the task of implementers easier if both I-D are merged.

Hope it helps

Regards

-éric

> -----Original Message-----
> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of
> internet-drafts@ietf.org
> Sent: vendredi 10 août 2012 12:39
> To: i-d-announce@ietf.org
> Cc: ipv6@ietf.org
> Subject: I-D Action: draft-ietf-6man-ipv6-atomic-fragments-01.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>  This draft is a work item of the IPv6 Maintenance Working Group of the
> IETF.
> 
> 	Title           : Processing of IPv6 "atomic" fragments
> 	Author(s)       : Fernando Gont
> 	Filename        : draft-ietf-6man-ipv6-atomic-fragments-01.txt
> 	Pages           : 13
> 	Date            : 2012-08-10
> 
> Abstract:
>    The IPv6 specification allows packets to contain a Fragment Header
>    without the packet being actually fragmented into multiple pieces.
>    Such packets typically result from hosts that have received an ICMPv6
>    "Packet Too Big" error message that advertises a "Next-Hop MTU"
>    smaller than 1280 bytes, and are currently processed by some
>    implementations as "fragmented traffic".  Thus, by forging ICMPv6
>    "Packet Too Big" error messages an attacker can cause hosts to employ
>    "atomic fragments", and then launch any fragmentation-based attacks
>    against such traffic.  This document discusses the generation of the
>    aforementioned "atomic fragments", the corresponding security
>    implications, and formally updates RFC 2460 and RFC 5722 such that
>    fragmentation-based attack vectors against traffic employing "atomic
>    fragments" are completely eliminated.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-atomic-fragments
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-6man-ipv6-atomic-fragments-01
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-ipv6-atomic-fragments-01
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------