Subject: Re: 6MAN WG Last Call - draft-ietf-6man-deprecate-atomfrag-generation

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 4 Jan 2016 17:04:20 +0000

Bob, thanks for the extended WGLC.

I do not see a real value in this proposal (sorry Fernando & Tore):
1) the attack vector can also be used with a packet-too-big MTU=1400, it
will force real fragments to be sent. So, deprecating atomic fragment has
little value or am I missing something?
2) the core issue is that transit providers drop 'normal' fragments (as
opposed to the evil RFC 7112), this is the real problem that need to be
solved anyway because normal fragments will still happen

Else, indeed the NAT64 function could become stateful for those packets at
the risk of becoming the target of a DoS themselves ;-)

Sorry to start the year with a negative comment

Happy New Year anyway :-)

-éric

On 15/12/15 09:57, "ipv6 on behalf of Bob Hinden" <[email-masked]
on behalf of [email-masked]> wrote:

>This message restarts a two week 6MAN Working Group Last Call on
>advancing:
>
>   Title           : Deprecation of the Generation of IPv6 Atomic
>Fragments
>   Authors         : Fernando Gont
>                     Will(Shucheng) Liu
>                     Tore Anderson
>   Filename        : draft-ietf-6man-deprecate-atomfrag-generation-04.txt
>   Pages           : 9
>   Date            : 2015-11-26
>
>   
>https://tools.ietf.org/html/draft-ietf-6man-deprecate-atomfrag-generation-
>04
>
>as an Informational Document.  Substantive comments and statements of
>support for publishing this document should be directed to the mailing
>list.  Editorial suggestions can be sent to the authors.  This last call
>will end on 12 January 2016.  This is a four week last call to account
>for the holidays in December.
>
>Best regards,
>Ole & Bob
>
>

---

From: Bob Hinden <[email-masked]>
Date: Mon, 4 Jan 2016 11:08:26 -0800

Hi Eric,

> On Jan 4, 2016, at 9:04 AM, Eric Vyncke (evyncke) <[email-masked]> wrote:
> 

Given the holidays it was appropriate.

> little value or am I missing something?

My understand the attack is forcing “atomic” fragments to be sent.  Before this change (now removed in rfc1981bis and rfc2460bis) this could be triggered by sending a packet too big with an MTU of less than 1280.

The case you mention would cause two fragments to be sent (assuming the MTU of the packet was >1400), not an atomic fragement.  The text removed was specific about MTUs < 1280.

Does that help?

Bob

---

From: Fernando Gont <[email-masked]>
Date: Tue, 5 Jan 2016 23:09:32 -0300

> little value or am I missing something?

This is the bit you seem to be missing: In the case you describe, such
packet will not trigger fragmentation, but rather a reduction of the
assumed Path-MTU. -- i.e., even in the case a host is employing Path-MTU
Discovery, an ICMPv6 PTB < 1280 would trigger fragmentation. i.e., you
could trigger the use of fragmentation for traffic that would otherwise
not employ fragmentation. (step #2 would be to perform a frag-based DoS
attack -- although with the widespread filtering of fragments, at times
just triggering fragmentation would do the trick (kernel.org was an
example of this)).

> solved anyway because normal fragments will still happen

Not really. The core of the issue is that you shouldn't employ
fragmentation unless you really need it (stateful operation for an
otherwise stateless protocol, etc., etc.).

The widespread filtering of fragments simply means that if an attacker
is able to trigger fragmentation, in many cases he will not need to
perform any frag-based attack, because the network will, unfortunately,
already filter the packets.

Another core issue is that it is a bad idea to allow a random node to
trigger the use of fragmentation for traffic that otherwise wouldn't
employ it (e.g., TCP doing Path-MTU Discovery).

> Sorry to start the year with a negative comment

Hopefully the above clarifies the background ;-)

Thanks!

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

---

From: Fernando Gont <[email-masked]>
Date: Wed, 6 Jan 2016 01:46:30 -0300

On 01/04/2016 04:08 PM, Bob Hinden wrote:
>> I do not see a real value in this proposal (sorry Fernando &
>> Tore): 1) the attack vector can also be used with a packet-too-big
>> MTU=1400, it will force real fragments to be sent. So, deprecating
>> atomic fragment has little value or am I missing something?
> 
> My understand the attack is forcing “atomic” fragments to be sent.
> Before this change (now removed in rfc1981bis and rfc2460bis) this
> could be triggered by sending a packet too big with an MTU of less
> than 1280.
> 
> The case you mention would cause two fragments to be sent (assuming
> the MTU of the packet was >1400), not an atomic fragement.  The text
> removed was specific about MTUs < 1280.

Eric's case will not really trigger fragmentation of any sort for the
typical TCP+PMTUD case -- it will just cause the  assumed Path-MTU to be
decreased... but without triggering any sort of fragmentation.

The cornercase we're deprecating in rfc2460bis was the only vector an
attacker had to trigger fragmentation in any arbitrary flow.

Thanks,

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 6 Jan 2016 15:47:25 +0000

Fernand (and Bob),

First thanks for your replies.
 (
About PTB > 1280: I have to read RFC2460bis, but, the 'old' RFC 2460
states that when the path MTU for one destination is smaller than the
physical MTU, then either fragmentation (bad) or application (preferred)
must adapt. To be honest, I do not have any data backing how
hosts/applications react in that case. If hosts commonly do fragmentation
because app is ignorant of the MTU, then the attack is also possible on
non atomic fragment. Again, I should read RFC2460 bis regarding the pMTUd
part.

Then, we agree on the fact that fragmentation should really be discouraged
for security and performance reasons :-) And we are also in 'violent'
agreement on the fact that this is really not secure to allow any node to
reduce the MTU between two other parties... OTOH not an easy problem to
fix.

Regards

-éric

---

From: Fernando Gont <[email-masked]>
Date: Thu, 7 Jan 2016 10:35:38 -0300

Hi, Eric,

On 01/06/2016 12:47 PM, Eric Vyncke (evyncke) wrote:
> must adapt. 

That can't be possible.  If it was, Path-MTU Discovery would be impossible:

You *always* send packets smaller than the physical MTU. Then PMTU
operates between min(IP_MIN_MTU) and min (Physical_MTU, Path-MTU).
(where IP_MIN_MTU is 68 for IPv4 and 1280 for IPv6).

When you employ a protocol that can segment data (TCP, SCTP, etc) you
never fall back to fragmentation (that's the whole point of doing
Path-MTU Discovery). You just keep segmenting the app data at the
transport layer at appropriate chunk sizes.

In IPv4, you never reduce past 68 bytes. In IPv6, you never reduce past
1280 bytes. However, RFC2460 supported a corner case where if you were
to receive an ICMPv6 PTB < 1280, you'd not reduce the size of your data
chunk, but just start sending atomic fragments.

draft-ietf-6man-deprecate-atomfrag-generation discusses why this is not
a good idea. But the short version of the answer is that you don't want
to employ fragmentation unless you really have to. Hence, generating
atomic fragments doesn't make much sense.

> To be honest, I do not have any data backing how
> non atomic fragment.

When an app employs TCP+PMTUD or the like, they would never employ
fragmentation, modulo this corner case.

> reduce the MTU between two other parties... OTOH not an easy problem to

This case is actually quite worse, because you're not simply reducing
the MTU between two nodes, but also triggering fragmentation. IN IPv6,
since the minimum MTU is quite large (1280 bytes), an attacker that
reduces the MTU between two node just causes a performance penalty (kind
of small if the real PMTU was e.g. 1500 bytes). BUt an attacker that can
trigger the use of fragmentation opens the door to a number of
fragmentation-based attacks... and, because of the widespread filtering
of IPv6 fragments, at times just triggering fragmentation already
results in a DoS scenario.

Thanks!

Cheers,

---

From: Qiong <[email-masked]>
Date: Mon, 11 Jan 2016 10:29:34 +0800

Dear All,

I support publication of this document as an RFC.

A few small comments:

In abstract you seem to imply that the vulnerability relies partly on
"widespread filtering of packets with extension headers". Actually, atomic
fragments open the door to all fragmentation-based attacks.

Similarly, in Section 1 you wrote "there are scenarios in which the
generation of IPv6 atomic fragments can introduce an attack vector that can
be exploited for denial of service purposes", but the attack vectors are
introduced in all scenarios.

Appendix A contains valuable information. IMHO, it should be stressed
earlier in the document that many of the most popular implementations do
not generate atomic fragments, something like "this document aligns the
specifications with practice".

On Tue, Dec 15, 2015 at 4:57 PM, Bob Hinden <[email-masked]> wrote:

> This message restarts a two week 6MAN Working Group Last Call on advancing:
>
>    Title           : Deprecation of the Generation of IPv6 Atomic Fragments
>    Authors         : Fernando Gont
>                      Will(Shucheng) Liu
>                      Tore Anderson
> https://tools.ietf.org/html/draft-ietf-6man-deprecate-atomfrag-generation-04
>
> will end on 12 January 2016.  This is a four week last call to account for
> the holidays in December.
>
> Best regards,
> Ole & Bob
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>

-- 
==============================================
Qiong Sun
China Telecom Beijing Research Institude

Open source code:
lightweight 4over6: *http://sourceforge.net/projects/laft6/
<http://sourceforge.net/projects/laft6/>*
PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/
<http://sourceforge.net/projects/pcpportsetdemo/> *
===============================================

---

From: Xing Li <[email-masked]>
Date: Mon, 11 Jan 2016 11:28:12 +0800

I support publication of this document. xing

---

From: Congxiao Bao <[email-masked]>
Date: Mon, 11 Jan 2016 23:10:48 +0800

I support the publication of this document. 

Congxiao Bao

---

From: Tina Tsou <[email-masked]>
Date: Tue, 12 Jan 2016 15:27:08 +0800

Dear all,

I support publication of this document.

Suggestion: Please note earlier in this document that many popular OS
do not support the functionality being deprecated. That is,
the aforementioned functionality was never widely supported.

Thank you,
Tina

On Thursday, January 7, 2016, Fernando Gont <[email-masked]> wrote:

> e-mail: [email-masked] <javascript:;>
> [email-masked] <javascript:;>

---

From: Alberto Leiva <[email-masked]>
Date: Tue, 12 Jan 2016 11:29:04 -0600

Looks like I'm doing this disturbingly late. I'm an idiot; sorry.

Fernando asked for a summary paragraph of the atomic fragment + Linux
API issue. I understand if you guys don't want it; I think it's not
that meaningful as an argument compared to the other stuff already
included, and I wish I weren't potentially stalling publication of the
draft. But FWIW, here it is. (I would sandwich it between the two
"Finally, " blocks in section 4 since the relationship between DF and
Fragment Header has already been explained by then):

There are also drawbacks to the atomic fragment approach
implementation-wise: Even when the IPv6 endpoint answers atomic
fragments correctly, packet-handling API might tend to obscure
fragmentation-related information for simplifying purposes. If a
translator does not have reliable access to the fragment header, it
cannot safely derive the corresponding desired DF value. Assuming
fragment assembly is active in the forwarding pipeline (for
firewalling or other potential reasons), Netfilter (starting from
Linux version 3.13) is an example of a framework that hinders access
to the information RFC 6145 uses to infer Path MTU information.

More reading: https://github.com/NICMx/Jool/wiki/nf_defrag_ipv4-and-nf_defrag_ipv6#implementation-gotchas
That analysis is from more than a year ago; it doesn't cover newer kernels.

If you want to include this, then maybe I should check whether this
quirk is also present in really new kernels.

-----------------------

Also Nitpick:

There are two paragraphs in section 4 that start with "Finally, ".
Isn't that misleading?

-----------------------

I support this document with a passion.

Alberto

On Tue, Jan 12, 2016 at 1:27 AM, Tina Tsou <[email-masked]> wrote:
> Suggestion: Please note earlier in this document that many popular OS do not
> support the functionality being deprecated. That is, the aforementioned
> functionality was never widely supported.
>
>
> Thank you,
> Tina
>

---

From: 神明達哉 <[email-masked]>
Date: Tue, 12 Jan 2016 10:43:46 -0800

On Tue, Dec 15, 2015 at 12:57 AM, Bob Hinden <[email-masked]> wrote:
> as an Informational Document.  Substantive comments and statements
> of support for publishing this document should be directed to the
> mailing list.  Editorial suggestions can be sent to the authors.

I wouldn't be opposed to publishing this document.

I have a few comments on the 04 version however, which may better be
addressed before the publication:

- The title seems to be misleading to me.  On starting to re-read the
  latest version almost forgetting past discussions, I first wondered
  why this is supposed to be "Informational" if it "deprecates" a
  standard feature.  I then found it actually does not insist on
  deprecating it by updating RFC2460, merely saying the authors
  the believed atomic fragment is a bad idea.  The title confused me,
  and I guess it will confuse other future readers.  So I suggest
  renaming it something like "Issues with the Generation of IPv6
  Atomic Fragments" or if some stronger word is preferred, "The
  Generation of IPv6 Atomic Fragments is Considered Harmful".

- This arguments in Section 4 seem to be a bit weak to me:

   o  There exists a fair share of evidence of ICMPv6 Packet Too Big
      messages being dropped on the public Internet (for instance, that
      is one of the reasons for which PLPMTUD [RFC4821] was produced).
      [...]

  This being the case, using atomic fragments for attacks would also
  be less appealing, so we might argue we don't have to worry about it
  too much.  A possible counter argument to this might be that we
  don't want to allow any possibility of attacks while for legitimate
  cases we rather want it to always work.  I might buy it, but the
  seemingly arbitrary use of a particular point for the suggested
  conclusion rather makes the whole tone of the document look unfair
  IMO.  It may be only me, in which case I won't argue this should be
  necessarily addressed, but if some others have the same impression
  providing more neutral and/or discussion might help.

- Appendix A: it's a bit surprising to me that some BSD variants are
  listed here:

   o  FreeBSD 8.0
   o  NetBSD 5.1

  The generation of atomic fragments was supported in quite an early
  version of the KAME IPv6 stack, from which many of BSD variants were
  derived.  One repository log suggests it had been supported since
  around 2002:
  https://github.com/kame/kame/commit/eaaefeddf7c2878fe03f649b2da4d8535427aeb0

  And, while I don't have an environment to readily check the actual
  behavior right now, the latest version of both FreeBSD and NetBSD
  still seems to have essentially the same code.  In fact, according
  to RFC6946 later versions of FreeBSD can generate atomic fragments:

   +---------------------+---------------------+-----------------------+
   |   Operating System  |   Generates atomic  |    Implements this    |
   |                     |      fragments      |     specification     |
   +---------------------+---------------------+-----------------------+
   |     FreeBSD 8.0     |          No         |           No          |
   +---------------------+---------------------+-----------------------+
   |     FreeBSD 8.2     |         Yes         |           No          |
   +---------------------+---------------------+-----------------------+
   |     FreeBSD 9.0     |         Yes         |           No          |
   +---------------------+---------------------+-----------------------+

  So the result for 8.0 rather seems to be an intermittent regression.
  Like the previous point, I would find it unfair to only refer to an
  exceptional case that would support the conclusion of the authors.
  Perhaps (hopefully) that was not the intent of the authors, but if
  it's written more carefully so it won't look like picking specific
  evidences for a particular conclusion, I would accept it more
  comfortably.

--
JINMEI, Tatuya

---

From: Fernando Gont <[email-masked]>
Date: Thu, 14 Jan 2016 20:47:41 -0300

Hi, Jinmei,

On 01/12/2016 03:43 PM, 神明達哉 wrote:
>   the believed atomic fragment is a bad idea.  

FWIW, this version documents the issues associated with atomic
fragments, and why such support is removed from RFC2460bis.

> The title confused me,

Any of the two above sound fine to me. I'll stick with "Issues..."
unless folks argue in favor of the second option you suggested.

>       is one of the reasons for which PLPMTUD [RFC4821] was produced)., if anythin
>       [...]
> 
>   too much. 

Two comments on this one:

1) This is not the key or sole argument, but, if anything, just one of
the reasons for removing such support.

2) When you have functionality that cannot be relied upon, it cannot be
employed for legitimate purposes (it is not reliable), but is a
potential security lingering.

>   A possible counter argument to this might be that we
>   cases we rather want it to always work.

That's exactly the point.

>   I might buy it, but the

I will go through the whole document with a fresh look and try to
improve it in this respect.

>   to RFC6946 later versions of FreeBSD can generate atomic fragments:

FWIW, this was never meant to be unfair, but was rather included asn
example of an OS that fails to generate them. FWIW, I used FreeBSD 8.0 a
lot for testing, courses, etc.... so the test on FreeBSD 8.0 was purely
coincidential....

Do you think we should include, e.g., a later version of FreeBSD to show
that later versions do support it?

>   evidences for a particular conclusion, I would accept it more

As noted, that wasn't intentional. That sid, I think that, in this sort
of cases, showing sample platforms where functionality doesn't work is
of more value than showing platforms where the functionality does work
-- because in order to rely on it, it is important that it works in most
cases. Otherwise, you cannot rely on functionality that only works on a
subset of systems/pĺatforms (particularly when, as noted RFC6145
itself, there are options to make the consumer protocols of these atomic
fragments reliable).

Thanks!

Best regards,

---

From: 神明達哉 <[email-masked]>
Date: Fri, 15 Jan 2016 11:09:18 -0800

At Thu, 14 Jan 2016 20:47:41 -0300,

> fragments, and why such support is removed from RFC2460bis.

Ah, okay.  I now vaguely recall such discussions...in that case, it
would make more sense to me that this document explains it more
explicitly, referring to rfc2460bis.  Then we probably don't have to
adjust the document title.

Any of the rest of the comments are rather subjective matters.  After
all, I'm not opposed to the conclusion per se, and the "unfair" (to
me) facts are still facts anyway.  So if it's only me who wish it to
be more neutral/fair, I wouldn't insist on any changes.

--
JINMEI, Tatuya

---

From: Bob Hinden <[email-masked]>
Date: Fri, 15 Jan 2016 16:10:13 -0800

Jinmei,

> On Jan 15, 2016, at 11:09 AM, 神明達哉 <[email-masked]> wrote:
> 

I liked your idea of changing the title for the reasons you stated.  Someone who hasn’t read the discussions, will be confused.

Bob

---

From: Fernando Gont <[email-masked]>
Date: Sat, 16 Jan 2016 04:00:23 -0300

Hi, Jinmei,

> adjust the document title.

Will do.

> be more neutral/fair, I wouldn't insist on any changes.

Okay. We'll try to tweak the text a bit anyway.

Thanks so much!

Best regards,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 16 Jan 2016 05:10:38 -0300

Hi, Bob,

> I liked your idea of changing the title for the reasons you stated.  Someone who hasn’t read the discussions, will be confused.

Sounds reasonable. Which of the two options suggested by Jinmei should
we apply?

Thanks!

Best regards,

---

From: Bob Hinden <[email-masked]>
Date: Sat, 16 Jan 2016 10:00:07 -0800

Fernando,

> On Jan 16, 2016, at 12:10 AM, Fernando Gont <[email-masked]> wrote:
> 
> Hi, Bob,
> 

I could go either way, a slight preference for the second (that is, harmful).

Thanks,
Bob

Bob

---

From: "Liushucheng (Will)" <[email-masked]>
Date: Wed, 20 Jan 2016 07:27:33 +0000

Hi Tina,

Thanks for your comments.

Yes, a number of folks have noted this on the list and off-list. We will put a bit more stress on it in the draft.

Regards,
Will (Shucheng LIU)

From: ipv6 [mailto:[email-masked]] On Behalf Of Tina Tsou
Sent: Tuesday, January 12, 2016 3:27 PM
To: Fernando Gont
Cc: IPv6 List; Bob Hinden
Subject: Re: 6MAN WG Last Call - draft-ietf-6man-deprecate-atomfrag-generation

Dear all,

Suggestion: Please note earlier in this document that many popular OS do not support the functionality being deprecated. That is, the aforementioned functionality was never widely supported.

Thank you,
Tina

On Thursday, January 7, 2016, Fernando Gont <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Eric,

Thanks!

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

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

---

From: "Liushucheng (Will)" <[email-masked]>
Date: Wed, 20 Jan 2016 08:43:00 +0000

Hi Qiong,

Thanks for your comments. Please see my response below inline starts with [Will].

Regards,
Will (Shucheng LIU)

From: ipv6 [mailto:[email-masked]] On Behalf Of Qiong
Sent: Monday, January 11, 2016 10:30 AM
To: Bob Hinden
Cc: IPv6 List
Subject: Re: 6MAN WG Last Call - draft-ietf-6man-deprecate-atomfrag-generation

Dear All,

A few small comments:

In abstract you seem to imply that the vulnerability relies partly on "widespread filtering of packets with extension headers". Actually, atomic fragments open the door to all fragmentation-based attacks.
 [Will] How about changing the Abstract to this?
   "RFC2460 requires that when a host receives an ICMPv6 "Packet Too Big"
   message reporting an MTU smaller than 1280 bytes, 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 means that an
   attacker can leverage this functionality to trigger the use of
   fragmentation, and subsequently perform any fragmentation-based
   attack. This document discusses why the aforementioned functionality
   is undesirable, documenting the motivation for removing this
   functionality from [rfc2460bis].”

Similarly, in Section 1 you wrote "there are scenarios in which the generation of IPv6 atomic fragments can introduce an attack vector that can be exploited for denial of service purposes", but the attack vectors are introduced in all scenarios.
 [Will] We will update the draft to reflect this.

Appendix A contains valuable information. IMHO, it should be stressed earlier in the document that many of the most popular implementations do not generate atomic fragments, something like "this document aligns the specifications with practice".
[Will] Will do.

Cheers,
Will (Shucheng LIU)

On Tue, Dec 15, 2015 at 4:57 PM, Bob Hinden <[email-masked]<mailto:[email-masked]>> wrote:
This message restarts a two week 6MAN Working Group Last Call on advancing:

as an Informational Document.  Substantive comments and statements of support for publishing this document should be directed to the mailing list.  Editorial suggestions can be sent to the authors.  This last call will end on 12 January 2016.  This is a four week last call to account for the holidays in December.

Best regards,
Ole & Bob

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

Open source code:
lightweight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
===============================================