Subject: Revision of the IPv6 atomic frag deprecation I-D (Fwd: New Version Notification for draft-gont-6man-deprecate-atomfrag-generation-01.txt)

From: Fernando Gont <[email-masked]>
Date: Wed, 27 Aug 2014 15:01:43 -0300

Folks,

We have published a revision of the aforementioned document:
<http://www.ietf.org/internet-drafts/draft-gont-6man-deprecate-atomfrag-generation-01.txt>

I'll try to summarize the changes incorporated in this version:

* Section 1 and Section 2 have been augmented to better explain the
rationale for the proposed update -- not just interms of the security
vulnerability being discussed, but also in terms of protocol robustness.

* We have relaxed the update to RFC2460, noting that ICMP PTB<1280
should not elicit atom frags (rather than "these packets should be
dropped"), as suggested by Bob Briscoe

* We have clarified the rationale for relying on IPv6 atom frags as part
of the SIIT design decision.

* We have incorporated an Appendix with a small and non-exhaustive
survey which shows that quite a few widely deployed OSes fail to
generate IPv6 atomic fragments in response to ICMPv6 PTB<1280.

* We have clarified why you cannot simply check the IPv6 Source Address
representing IPv4 nodes as a general mitigation to the vulnerability
discussed in this document. -- this is based on the thread with Tatuya
Jinmei.

* We have included (in Section 6) a formal update to RFC6145, as
suggested by Brian Carpenter. If the working group decides to take on
this document, a second-order decision might be whether to update RFC
2460 and RFC6145 in this doc, or just focus on atom frag generation
here, and do a complete RFC6145bis in a separate document. The whole
Section 6 is mostly meant as "this is what one should patch in RFC6145
such that it does not rely on IPv6 atomic fragments". However, we note
that the core of this document is really all Sections other than Section
6, since those are the ones providing the rationale for deprecating the
generation of IPv6 atomic fragments.

Please do let us know if we have missed anything, if there's anything
that needs further clarification, or if you like the I-D as is.

Thanks so much!
Fernando (and co-authors)

-------- Forwarded Message --------
Subject: New Version Notification for
draft-gont-6man-deprecate-atomfrag-generation-01.txt
Date: Wed, 27 Aug 2014 10:43:04 -0700
From: [email-masked]
To: Will(Shucheng) Liu <[email-masked]>, Shucheng LIU (Will)
<[email-masked]>, Tore Anderson <[email-masked]>, Tore
Anderson <[email-masked]>, Fernando Gont
<[email-masked]>, Fernando Gont <[email-masked]>

A new version of I-D, draft-gont-6man-deprecate-atomfrag-generation-01.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.

Name:		draft-gont-6man-deprecate-atomfrag-generation
Revision:	01
Title:		Deprecating the Generation of IPv6 Atomic Fragments
Document date:	2014-08-27
Group:		Individual Submission
Pages:		17
URL:
http://www.ietf.org/internet-drafts/draft-gont-6man-deprecate-atomfrag-generation-01.txt
Status:
https://datatracker.ietf.org/doc/draft-gont-6man-deprecate-atomfrag-generation/
Htmlized:
http://tools.ietf.org/html/draft-gont-6man-deprecate-atomfrag-generation-01
Diff:
http://www.ietf.org/rfcdiff?url2=draft-gont-6man-deprecate-atomfrag-generation-01

Abstract:
   The core IPv6 specification requires that when a host receives an
   ICMPv6 "Packet Too Big" message reporting a "Next-Hop MTU" smaller
   than 1280, the host includes a Fragment Header in all subsequent
   packets sent to that destination, without reducing the assumed Path-
   MTU.  The simplicity with which ICMPv6 "Packet Too Big" messages can
   be forged, coupled with the widespread filtering of IPv6 fragments,
   results in an attack vector that can be leveraged for Denial of
   Service purposes.  This document briefly discusses the aforementioned
   attack vector, and formally updates RFC2460 such that generation of
   IPv6 atomic fragments is deprecated, thus eliminating the
   aforementioned attack vector.  Additionally, it formally updates
   RFC6145 such that the Stateless IP/ICMP Translation Algorithm (SIIT)
   does not rely on the generation of IPv6 atomic fragments, thus
   improving the robustness of the protocol.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Antonios Atlasis <[email-masked]>
Date: Wed, 27 Aug 2014 22:50:34 +0300

Hi,

Regarding the information provided in Appendix A of the document:

I just re-tested Centos 6.5, which uses kernel 2.6.32, concerning the
generation of Atomic Fragments in response to ICMPv6 Packet Too Big
messages that report an MTU smaller than 1280 bytes. Specifically, when
reporting MTU=1200 bytes < 1280 bytes, at least the following two kernels
_generate_ Atomic Fragments:

2.6.32-431.20.3.el6.i686
2.6.32-431.23.3.el6.i686    (latest)

Regards

Antonios

2014-08-27 21:01 GMT+03:00 Fernando Gont <[email-masked]>:

> <
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

-- 
=====================
Antonios Atlasis, PhD, MPhil
GXPN, GREM, GPEN, GWAPT, CCIH, GCIA

---

From: Fernando Gont <[email-masked]>
Date: Wed, 27 Aug 2014 16:59:59 -0300

Hi, Antonios,

On 08/27/2014 04:50 PM, Antonios Atlasis wrote:
> reporting MTU=1200 bytes < 1280 bytes, at least the following two
> kernels _generate_ Atomic Fragments:
> 
> 2.6.32-431.20.3.el6.i686

But these are not the kernel versions included in the table of Apendix
A, are they?

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

---

From: Antonios Atlasis <[email-masked]>
Date: Wed, 27 Aug 2014 23:08:23 +0300

Hi Fernando,

yes, they are, this is why I mentioned it. Appendix A includes Linux kernel
2.6.32, the ones that I mentioned are the latest updates of this Linux
Kernel, at least at Centos (version 6.5), the Red Hat clone. It is referred
in our latest results at
http://www.insinuator.net/2014/08/packet-too-big-messages-and-atomic-fragments/.
Furthermore, Centos 6.5 is one of the two (the other one is FreeBSD 10)
that takes a really long time to recover (meaning to stop sending atomic
fragments).

Best

Antonios

---

From: Fernando Gont <[email-masked]>
Date: Wed, 27 Aug 2014 17:15:29 -0300

On 08/27/2014 05:08 PM, Antonios Atlasis wrote:
> Hi Fernando,
> 
> yes, they are, this is why I mentioned it.

Please check the version numbers. As far as I recall,  the 2.6.32-XXX
represents a lot of revisions.

> Appendix A includes Linux
> kernel 2.6.32, the ones that I mentioned are the latest updates of this
> Linux Kernel,

Then it's not the same. :-)

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Aug 2014 08:38:01 +1200

Fernando,

Wow, what a lot of detailed work! I'll give my top-level views:

1. We need to ask the RFC 6145 authors to comment on the *accuracy*
of the proposed revisions and whether they have any unintended
side effects.

2. Then we need to decide whether the change is or isn't desirable
on balance. (I haven't really made up my mind yet on this, but I've
certainly always found this to be a very messay aspect of the SIIT
model.)

3. Finally, if we go ahead, we would need to decide whether it
would be simpler to publish RFC6145bis rather than spell out
all the diffs in this document.

Regards
   Brian

---

From: Antonios Atlasis <[email-masked]>
Date: Thu, 28 Aug 2014 00:08:36 +0300

Hi,

---

From: Antonios Atlasis <[email-masked]>
Date: Thu, 28 Aug 2014 00:29:28 +0300

Hi Fernando,

by no means I want to start / continue any kind of disagreement, I just
believe that when a document is written today, it would be great if it
could be included as much up-to-date information as possible.  To this end,
if the latest update of the Linux kernel 2.6.32 family generates Atomic
Fragments, especially if this is used by one of the most popular Linux
enterprise systems, it should also be taken into consideration (btw, do you
know which exact version/system of 2.6.32 failed to generate Atomic
Fragments in response to PTB with MTU < 1280?). Similarly for FreeBSD, as
you also write at rfc6946, this behaviour has changed at version 8.2 (and
later, I suppose). So, I would prefer to read about the latest updates of
these families and not about the previous / oldest versions.

The above note may change nothing regarding the main point of deprecation
of Atomic Fragments and it was not intended to be any kind of criticism, it
was just driven by my personal way of thinking of trying to include as much
up-to-date information as possible in my documents. That's all

Regards

Antonios

2014-08-27 23:38 GMT+03:00 Brian E Carpenter <[email-masked]>:

> > A new version of I-D,

---

From: Tore Anderson <[email-masked]>
Date: Thu, 28 Aug 2014 09:40:59 +0200

* Brian E Carpenter

> certainly always found this to be a very messay aspect of the SIIT

Having used SIIT for quite a while, I think that the new approach is
quite acceptable. In my experience, IPv4 paths with MTUs < 1260 are
extremely infrequent anyway, so the problem solved (either by the atomic
fragments approach or the new one we propose) is pretty much only of
academic interest anyway, the way I see it.

> all the diffs in this document.

I'd prefer a RFC6145bis. Reading first one document and then reading
another to mentally "patch" the information in the first one isn't a
good way to convey information...

Tore

---

From: Fernando Gont <[email-masked]>
Date: Thu, 28 Aug 2014 08:29:58 -0300

Hi, Brian,

Thanks so much for your feedback! Please let me offer a clarification
and some comments in-line...

On 08/27/2014 05:38 PM, Brian E Carpenter wrote:
> of the proposed revisions and whether they have any unintended side
> effects.
> 
> 2. Then we need to decide whether the change is or isn't desirable on
> balance. (I haven't really made up my mind yet on this, but I've 

The alternative approach that we have proposed is essentially already
offered n Section 6 (starting right in page 25) of RFC 6145, as a
workaround to deal with scenarios where nodes e.g. fail to generate IPv6
atomic fragments.

i.e., what we're proposing is not a "brand new way of SIIT operation",
but rather making the default something that is already there in RFC6145.

FWIW, Section 6 (Updating RFC6145) of *our* document is rather lengthy,
but just because there are several parts of RFC6145 where atomic
fragments are mentioned.

> 3. Finally, if we go ahead, we would need to decide whether it would
> be simpler to publish RFC6145bis rather than spell out all the diffs
> in this document.

I think it would be better to have our document just deprecate the
generation of IPv6 atomic fragments and RFC6145bis do the RFC6145
updates.. Otherwise, for a guy reading RFC6145, things gets too messy,
since RFC6145 needs to be patched here and there.

Thanks!

Best regards,