Subject: I-D Action: draft-ietf-6man-deprecate-atomfrag-generation-01.txt

From: [email-masked]
Date: Mon, 27 Apr 2015 17:55:29 -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           : Deprecating the Generation of IPv6 Atomic Fragments
        Authors         : Fernando Gont
                          Will(Shucheng) Liu
                          Tore Anderson
	Filename        : draft-ietf-6man-deprecate-atomfrag-generation-01.txt
	Pages           : 17
	Date            : 2015-04-27

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.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-deprecate-atomfrag-generation/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-6man-deprecate-atomfrag-generation-01

A diff from the previous version is available at:
https:https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-deprecate-atomfrag-generation-01

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Fernando Gont <[email-masked]>
Date: Mon, 27 Apr 2015 22:01:16 -0300

Folks,

We've rev'ed the aforementioned I-D with minor clarifications requested
by implementers:
<https://tools.ietf.org/html/draft-ietf-6man-deprecate-atomfrag-generation-01>

We think the current version of the I-D is ready for WGLC.

Thoughts?

Thanks!

Best regards,
Fernando

On 04/27/2015 09:55 PM, [email-masked] wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

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

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 28 Apr 2015 02:11:49 +0000

> On Apr 27, 2015, at 6:01 PM, Fernando Gont <[email-masked]> wrote:
> 

The ID contains three essential parts: why the recommendations, a relatively minor change to RFC 2460, and some deep surgery on RFC 6145. Let me as a question on that last, if you would.

Have those proposed changes been vetted with the implementors you mentioned?

If this is the consensus of the working group, I personally would be in favor of churning 6145 rather than making future implementors read two documents in parallel. I would want to do that in 6man.

---

From: Tore Anderson <[email-masked]>
Date: Tue, 28 Apr 2015 07:18:03 +0200

Hi Fred,

* "Fred Baker (fred)" <[email-masked]>

> The ID contains three essential parts: why the recommendations, a
> relatively minor change to RFC 2460, and some deep surgery on RFC
> 6145. Let me as a question on that last, if you would.
> 

I believe so. Quoting from <http://jool.mx/usr-flags-atomic.html>:

«Let it be known that we fully condone the deprecation of atomic
fragments»

I'm adding the implementors in question to the CC list, so they may
elaborate on their position if they so desire.

Tore

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 28 Apr 2015 05:57:46 +0000

BTW, if we rev 6145 for this, we should include your favorite rev, and there is an erratum to sort out. I’d like to do it all in one swell foop in one working group. I’ll take advice on where; the obvious place (behave) doesn’t exist any more.

---

From: Tore Anderson <[email-masked]>
Date: Tue, 28 Apr 2015 08:41:54 +0200

> BTW, if we rev 6145 for this, we should include your favorite rev,
> and there is an erratum to sort out. I’d like to do it all in one
> swell foop in one working group. I’ll take advice on where; the
> obvious place (behave) doesn’t exist any more.

I'll gladly roll draft-anderson-v6ops-siit-eam into a 6145bis.

Being somewhat of an IETF newbie, I don't have any strong opinions on
the venue and will follow where you lead... That said, I was faced with
the same question when determining where to submit the siit-eam stuff,
and here is my thoughts on the matter:

- When I spoke to Ole about the SIIT-DC/EAM stuff a while back I was
  told that 6man was not appropriate.

- A 6145bis is bordering on being out of scope for v6ops' charter. I
  guess it depends on whether or not you understand «specifying any
  protocols or transition mechanisms» to also mean «updating already
  specified protocols or transition mechanisms». That said, there is
  precedent for doing 6145 updates in v6ops though; cf. RFC 6791 (and
  also the soon-to-be-uploaded draft-ietf-v6ops-siit-eam). Furthermore,
  when considering that the updates is largely caused by operational
  experience, v6ops does sound like an OK fit.

- Sunset4 may be appropriate, as facilitating the disablement of IPv4
  in (parts of) the network is perhaps the most important use case for
  SIIT. However there's no fitting work item listed in the sunset4
  charter as far as I can see.

If there are other potential candidates, I'm not familiar with them.

Tore

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 28 Apr 2015 06:46:13 +0000

> On Apr 27, 2015, at 11:41 PM, Tore Anderson <[email-masked]> wrote:
> 

We can talk with Marc and Wes about that. Yes, it may be appropriate.

---

From: Alberto Leiva <[email-masked]>
Date: Tue, 28 Apr 2015 12:07:51 -0500

> I'm adding the implementors in question to the CC list, so they may elaborate on their position if they so desire.

There is one minor thing I did not mention in that documentation. It
does seem minor, but I'll include it here for completeness sake.

I feel there's some degree of carelessness toward atomic fragments in
Linux's network stack. They are a minor paragraph in RFC 2460, easy to
overlook, and the idea can collapse in the hands of a careless or
recklessly optimizing coder.

One example of such scenarios is pictured in the documentation linked
by Tore: In the output pipeline, Linux's fragmentation code *assumes*
there's no fragment header (if I'm not missing something), so if the
packet is an atomic fragment, the code will generate packets with
consecutive fragment headers, where only one is supposed to be legal.

Another example is the incoming pipeline: Netfilter's fragment
reassembly module goes through pains to pretend incoming fragments are
actually a single/full packet, which involves some layer-3 header
corruption. If you're interested, look up "This is one of the reasons
why I've learned to hate atomic fragments so much" here:
https://github.com/NICMx/NAT64/wiki/nf_defrag_ipv4-and-nf_defrag_ipv6#implementation-gotchas.
This corruption can sometimes be reverted, sometimes it cannot. Any
module can call skb_linearize() and ruin everything
(https://github.com/NICMx/NAT64/wiki/nf_defrag_ipv4-and-nf_defrag_ipv6#nf_defrag_ipv6---kernels-313).

In general, the skb_linearize() function is discouraged, which is why
I personally do not consider this input quirk a strong argument
against atomic fragments. However, I feel it does show that
*defragmenting IPv6 routers* can exist in the wild (though they are
very unlikely), and this can easily break RFC 6145's assumptions
regarding the DF flag and the redundant fragment header (among other,
even more important things).

I just can't help but wonder why is that RFC 6145 chooses to store
state in fields that were originally not intended for that purpose.
Saying "Okay, this fragment header probably means the IPv4 node wasn't
using Path MTU discovery several packets ago" is trusting the IPv6
network (including all routers in-between) behaves in a peculiar way.
It sounds to me like awkward design.

Well, I could be missing something more important since RFC 6145
doesn't always explain its rationale. Anyway, that's my two cents.

I'd like to apologize to Fernando. A fairly long time ago we discussed
this and he asked for some suggested text for the draft, and I didn't
answer. I can still do it if it's relevant.

Alberto

---

From: Ole Troan <[email-masked]>
Date: Tue, 28 Apr 2015 20:17:12 +0200

> If this is the consensus of the working group, I personally would be in favor of churning 6145 rather than making future implementors read two documents in parallel. I would want to do that in 6man.

yes,  I also agree with you that it would be better to reissue RFC6145. I think there are better homes for that than 6man, but if no-one else volunteers, then let’s have a discussion with our ADs.

cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 29 Apr 2015 10:48:15 +1200

> We can talk with Marc and Wes about that. Yes, it may be appropriate.

There's always the intarea WG if nobody else will take it.
I agree that the work should be done.

   Brian

---

From: "Liushucheng (Will)" <[email-masked]>
Date: Wed, 29 Apr 2015 10:12:45 +0000

Hi Ole,

It seems to us that we agree that the best way is to have this document deprecate the generation of atomic fragments, and have the RFC6145 updates in a separate document (RFC6145bis).

Should we update our document accordingly, and resubmit, and then make progress? Thanks.

Cheers,
Will

> -----Original Message-----
> From: Ole Troan [mailto:[email-masked]]
> Sent: Wednesday, April 29, 2015 2:17 AM
> To: Fred Baker (fred)
> Cc: Fernando Gont; 6man WG; [email-masked];
> [email-masked]
> Subject: Re: Moving forward
> draft-ietf-6man-deprecate-atomfrag-generation-01 (Re: I-D Action:
> draft-ietf-6man-deprecate-atomfrag-generation-01.txt)
> 
> >> We've rev'ed the aforementioned I-D with minor clarifications
> >> requested by implementers:
> > The ID contains three essential parts: why the recommendations, a relatively
> minor change to RFC 2460, and some deep surgery on RFC 6145. Let me as a
> question on that last, if you would.
> >
> > If this is the consensus of the working group, I personally would be in favor of
> churning 6145 rather than making future implementors read two documents in
> parallel. I would want to do that in 6man.
> 
> yes,  I also agree with you that it would be better to reissue RFC6145. I think
> there are better homes for that than 6man, but if no-one else volunteers, then
> let’s have a discussion with our ADs.
> 
> cheers,
> Ole

---

From: Ole Troan <[email-masked]>
Date: Wed, 29 Apr 2015 13:09:54 +0200

Will,

> Should we update our document accordingly, and resubmit, and then make progress? Thanks.

I’d suggest you keep the draft as is for the moment, until the relevant text is moved over to 6145bis, and that has found a new home.

another question on this proposed change. as we’re looking at making RFC2460 Internet Standard.
can this change; e.g with an updated host not including the FH and a legacy translator lead to incompatibility problems?

cheers,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Thu, 30 Apr 2015 16:12:26 -0300

Hi, Fred,

> Have those proposed changes been vetted with the implementors you

Yes.

> If this is the consensus of the working group, I personally would be
> in favor of churning 6145 rather than making future implementors read
> two documents in parallel. I would want to do that in 6man.

I agree with you.

So... should a revision of RFC6145 be done here? Or, if not, what's the
procedure to find a home for it?

Thanks!

Best regards,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 30 Apr 2015 16:29:05 -0300

Hi, Ole,

On 04/29/2015 08:09 AM, Ole Troan wrote:
> 
>> It seems to us that we agree that the best way is to have this
>> document deprecate the generation of atomic fragments, and have the
>> RFC6145 updates in a separate document (RFC6145bis).
>> 
> I’d suggest you keep the draft as is for the moment, until the
> relevant text is moved over to 6145bis, and that has found a new
> home.

What's the "procedure" to find a home for RFC6145bis?

If there's consensus to do the RFC6145 update as a separate document,
I'd probably rev without the RFC6145 text and progress the document.

For instance, having the document progressed wuld be useful for the
RFC6145 update itself.

Thanks!

Cheers,

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 30 Apr 2015 20:24:18 +0000

> On Apr 30, 2015, at 12:29 PM, Fernando Gont <[email-masked]> wrote:
> 

I think it’s a gimongously arduous process like “ask the AD”.

My suggestion:

I’ll start out by asking Heather for her preferred XML source for the draft. It would be nice to have the right input. From that, I can create something under a name like draft-baker-rfc6145-bis-*.txt, and insert changes from the erratum, your draft, and Tore Anderson’s draft. We can then discuss it, wherever the right place turns out to be, including intarea. Where I’m going to push back is people wanting to make random changes; it’s one thing to have proven changes incorporated, and quite another to have armchair pundits comment.

The document is largely based on (e.g. a repeat of) SIIT, which has implementations, and there are multiple implementations of 6145. I’ll want each of those implementers to agree to the update.