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

From: [email-masked]
Date: Fri, 10 Aug 2012 03:39:16 -0700

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/

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 14 Aug 2012 14:14:13 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: vendredi 10 août 2012 12:39
> To: [email-masked]
> Cc: [email-masked]
> Subject: I-D Action: draft-ietf-6man-ipv6-atomic-fragments-01.txt
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Fernando Gont <[email-masked]>
Date: Tue, 14 Aug 2012 22:45:03 -0300

Hi, Eric,

Thanks so much for your feedback! -- Please find my comments in-line...

On 08/14/2012 11:14 AM, Eric Vyncke (evyncke) wrote:
> 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) 

What data, specifically, would you expect? -- A list of vulnerable
implementations or the like?

You may want to try the icmp6 tool in the IPv6 toolkit
<http://www.si6networks.com/tools> to fire e.g. ICMPv6 PTB, and see that
they are honored without e.g. checking the embedded TCP sequence number.

- 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 

There's no fragmentation in routers, and hence this is not possible --
for instance, this is part of the rationale for RFC 5722.

- section 3: not sure what is meant by 'FH
> should (no uppercase?) be removed by the receiving host',

This is the same as "performing fragmentation using only the atomic
fragment"... the Next-Header field in the IPv6 fixed header should be
changed to the value of the Next-Header in the FH, BTW.

> 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 -

Do such stacks keep the FH for normal fragmented traffic? -- If so, how
are each of the values (FOffset, etc.) selected?

(Bottom-line: if this doesn't happen for normal fragmented traffic, I
don't think we should make atomic fragments a special case).

> 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...

Well, we don't really take a stance regarding what to do with the
matching fragments.

Performance-wise you may want to avoid searching through the queued
fragments.

Thoughts?

> I tend to believe that upper layer (TCP
> notably) will reject the second one if the sequence number match

Not sure what you mean...

> 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.

I personally believe that both I-Ds are orthogonal. And also,
procedurally-wise, at this point in time (past WGLC) we'll be better off
progressing this one small document than trying to merge it with
draft-gont-6man-predictable-fragment-id (which is not yet a wg item).

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492