Subject: Last Call: <draft-ietf-6man-ipv6-atomic-fragments-03.txt> (Processing of IPv6 "atomic" fragments) to Proposed Standard

From: The IESG <[email-masked]>
Date: Wed, 02 Jan 2013 09:03:08 -0800

The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document:
- 'Processing of IPv6 "atomic" fragments'
  <draft-ietf-6man-ipv6-atomic-fragments-03.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2013-01-16. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   The IPv6 specification allows packets to contain a Fragment Header
   without the packet being actually fragmented into multiple pieces (we
   refer to these packets as "atomic fragments").  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 file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-atomic-fragments/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-atomic-fragments/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: Ray Hunter <[email-masked]>
Date: Sat, 05 Jan 2013 11:24:01 +0100

I have read this draft and support it, as it provides a valuable
security update to IPv6.

Nits:

s/A received "atomic fragments" should be "reassembled" from the
contents of that sole fragment./
Each received "atomic fragment" should be individually "reassembled"
from the contents of that sole fragment./

/Many implementations fail to perform validation checks on the received
ICMPv6 error messages, as recommended in Section 5.2 of [RFC4443] and
[RFC5927]./

Although RFC4443 is a standard track document, none of the language in
Section 5.2 contains RFC2119 keywords.
RFC5927 is informational.

You may consider this a separate but related issue to atomic fragments,
but does validation checking of ICMPv6 messages need to be addressed
further in your current ID? I think your current ID stands alone whether
these validation checks are performed or not.

Are we then really justified in chastising implementors who ignore these
recommendations by somehow implying they've 'failed'?
Suggested alternative s/Many implementations fail to/Many
implementations do not/

regards,
RayH

---

From: Fernando Gont <[email-masked]>
Date: Sat, 05 Jan 2013 19:55:25 -0300

Hi, Ray,

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

> I have read this draft and support it, as it provides a valuable

Thanks!

> from the contents of that sole fragment./

Will apply this change to the next rev.

> further in your current ID?

What I've tried to note with the above comment is how trivial it is to
trigger the use of IPv6 atomic fragments.

> I think your current ID stands alone whether these validation checks are performed or not.

Agreed. But what I've tried to stress is that it is trivial to make any
connection employ atomic fragments -- hence it's not that the only
target of atomic-fragment attacks are those connections already employed
atomic fragments or fragmentation: it's trivial to trigger the use of
such fragments, and then perform a fragmentation-based attack...

> Suggested alternative s/Many implementations fail to/Many

I'm fine with your proposed text. Should the resulting text then be:

"Many implementations do not perform validation checks on the received
ICMPv6 error messages as recommended in Section 5.2 of [RFC4443] and
[RFC5927]"

?

Or can this be read as "they do not perform these validation checks, as
RFC4443 and RFC5927 recommend *not* to do so"? (English as second
language here)

Thanks!

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

---

From: Ray Hunter <[email-masked]>
Date: Sun, 06 Jan 2013 08:39:21 +0100

inline.
> Fernando Gont <mailto:[email-masked]>
> 5 January 2013 23:55
> Hi, Ray,
>
Ack.
> trigger the use of IPv6 atomic fragments.
Agreed it's trivial.

Do you consider the existence of atomic fragments to be harmful per se?

Or just the fact that they can adversely affect re-assembly at a host,
and thus can be used as an attack vector on the destination host?

Given the potential adverse effects on middleware boxes such as
firewalls, I'm thinking you consider them harmful per se.

> such fragments, and then perform a fragmentation-based attack...
Understood.

But if we consider atomic fragments to be harmful per se, what concrete
advice can we give implementors in a SHOULD clause in this ID on how to
process received ICMPv6 Packet Too Big messages in order to make
triggering atomic fragments less trivial?

If we haven't got any advice on how to stop them being triggered, we
can't really moan that it's trivial to trigger them. PMTUD is currently
pretty fundamental for correct operation of IPv6. Re-reading RFC1981,
it's tough to see what more anyone can sensibly do in a lightweight
implementation.

> ICMPv6 error messages as recommended in Section 5.2 of [RFC4443] and
Yes, the version above.
> Ray Hunter <mailto:[email-masked]>
> 5 January 2013 11:24
> ------------------------------------------------------------------------

---

From: Fernando Gont <[email-masked]>
Date: Wed, 09 Jan 2013 04:04:24 -0300

Hi, Ray,

> Do you consider the existence of atomic fragments to be harmful per se?

No, I don't (as long as v6 implementations implement this spec). Atomic
fragments, when processed as specified in
draft-ietf-6man-ipv6-atomic-fragments-03.txt, behave exactly as
unfragmented traffic (modulo the need to remove the Frag header, of course).

> and thus can be used as an attack vector on the destination host?

Exactly. The problem is that some implementations try to reassemble the
atomic fragments with other existing fragments -- i.e., the flaw is in
the reassembly process, rather than in the atomic fragments themselves.

> firewalls, I'm thinking you consider them harmful per se.

Of all the fragmentation cases, the atomic fragment case is the last I
would worry about. (the worst being
draft-ietf-6man-oversized-header-chain). That said, v6 fragmentation as
a whole is probably going to have a very hard time, unless we were to
enforce very tight constraints (e.g. "the whole header chain should be
present in the first, say, 512 bytes") -- but at the time this wg did
not even buy the requirement of the header chain to be in the first 1280
bytes (that's how we gor to the current requirement of "the complete
header chain must be present in the first fragment).

> But if we consider atomic fragments to be harmful per se, 

Atomic fragments are not harmful per-se, since they can be processes as
unfragmented traffic. *Real* fragmented traffic could be deemed as
harmful, though. (or as "unlikely to survive the Internet", if you
prefer ;-) ).

> what concrete

What should be done is validate ICMPv6 PTB according to:
1) the embedded payload, and,
2) progress on the connection

(actually, you're probably good enough even doing just the later).

The idea behind "2)" is simple: If you get an ICMPv6 PTB, it's because
your packets are being dropped (as a consequence of using a packet size
that is too large). So if the ICMPv6 PTB refers to e.g. a TCP
connection, you could just queue the received ICMPv6 PTB, and only
honour it when/if theres a TCP timeout at the TCP layer.

FWIW:

1) I implemented this on OpenBSD years ago, and the patch was ported to
NetBSD -- so both OSes have been employing this for years.

2) This approach is documented in RFC5927.

Now, if you wonder how things are the way they are specs-wise, my take is:

1) RFC5927 went informational because it was done in TCP in the 2004-
timeframe. (was plagged by neverending nitpicking non-sensiscal
discussions which were out of touch with running code).

2) RFC4443 somehow assumed that RFC1122 had to apply to ICMPv6 in the
same way it applied to ICMP(v4) -- hence the validation of ICMPv6 PTB
was not included as mandatory (fair enough... they either had to downref
RFC5927, or incorporate half of that RFC into RFC4443)

So, with that state of affairs with ICMPv6 PTB validation, sloppy
processing of atomic-fragments (which
draft-ietf-6man-ipv6-atomic-fragments-03.txt fixes), and sloppy Frag ID
generators in many iplementations (and we at the ietf/a wg not doing
something about it, yet), we have v6 implementations that...mm.. suck
big time :-) in this area.

> it's tough to see what more anyone can sensibly do in a lightweight

See Section 4 and Section 7 of RFC 5927. One might argue that this wg
might want to produce some version of RFC 5927 for ICMPv6, which doesn't
focus on any specific upper-layer protocol (i.e., doesn't focus on TCP
attacks).

Thoughts?

Thanks!

Best regards,