Subject: Re: Relax draft-gont-6man-deprecate-atomfrag-generation-00

From: Fernando Gont <[email-masked]>
Date: Wed, 20 Aug 2014 11:26:51 -0300

Hi, Bob,

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

On 08/20/2014 10:56 AM, Bob Briscoe wrote:
> 
> [I've cc'd ipv6, but I'm not subscribed, so pls include me specifically
> in any response.]
> 
> S.4
> Agree The current 2460 rule creates a vulnerability, but don't agree
> with [sender] "MUST discard ICMPv6 Packet Too Big" as the remedy. I
> would prefer "MUST NOT include a Fragment header in subsequent packets",
> which is the minimum needed to address the actual attack.

Clarification on our side (since what we conveyed might be different
from what we meant): What we meant is that if a host receives an ICMPv6
< 1280, it MUST NOT start sending atomic fragments.

So I will apply your suggested change -- thanks!

> Reasoning: there is no danger in the sender being aware that its packets
> are being fragmented. 2460 says the sender "is not required to reduce
> the size of subsequent packets", but this only means it doesn't have to;
> it doesn't mean it MUST NOT. In many cases the sender will be able to
> help the v6/v4 gateway improve performance by using a smaller segment
> size (e.g. if using TCP), rather than merely sending atomic fragments.

The question here is this:
The semantics of an ICMPv6 PTB is "Your packet was discarded, and this
is the size you should use for further packets". So (at least in an
IPv6-only world), an ICMPv6 PTB<1280 does not really signal that the
packet is being fragmented (since IPv6 routers do not fragment packets).

While I agree that, at least in theory, one could receive ICMPv6
PTB<1280, do nothing at the network layer, but still report the received
message to the transport layer, I'd probably say that acting on such
message kind of eliminates the concept of "IPv6 minimum MTU" -- i.e.,
"if all IPv6 networks support an MTU>=1280 bytes, why am I receiving
this ICMPv6 PTB that claims an MTU smaller than 1280?".

Thoughts?

> One nit noticed:
> S.3:
> s/When server server B/When server B/

Yep. Fixed.

Thanks!

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

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 20 Aug 2014 14:56:32 +0100

Fernando, Will,

[I've cc'd ipv6, but I'm not subscribed, so pls include me 
specifically in any response.]

S.4
Agree The current 2460 rule creates a vulnerability, but don't agree 
with [sender] "MUST discard ICMPv6 Packet Too Big" as the remedy. I 
would prefer "MUST NOT include a Fragment header in subsequent 
packets", which is the minimum needed to address the actual attack.

Reasoning: there is no danger in the sender being aware that its 
packets are being fragmented. 2460 says the sender "is not required 
to reduce the size of subsequent packets", but this only means it 
doesn't have to; it doesn't mean it MUST NOT. In many cases the 
sender will be able to help the v6/v4 gateway improve performance by 
using a smaller segment size (e.g. if using TCP), rather than merely 
sending atomic fragments.

Otherwise, with your proposed wording, the next thing we will see is 
(more) filtering of ICMPv6 Packet Too Big error messages, because it 
will be perceived that they are ignored anyway. Then perfectly 
harmless optimisations will become impossible.

One nit noticed:
S.3:

Bob

________________________________________________________________
Bob Briscoe,                                                  BT

---

From: Fernando Gont <[email-masked]>
Date: Wed, 20 Aug 2014 11:50:23 -0300

> which is the minimum needed to address the actual attack.

BTW, how about replacing the existing:

 "IPv6 nodes MUST discard ICMPv6 Packet Too Big error messages that
 report a Next-Hop MTU smaller than 1280 bytes (the minimum IPv6
 MTU)."

with

"An IPv6 node that receives an ICMPv6 Packet Too Big error message that
reports a Next-Hop MTU smaller than 1280 bytes (the minimum IPv6 MTU)
MUST NOT include a Fragment header in subsequent packets sent to the
corresponding destination. That is, IPv6 nodes MUST NOT generate IPv6
atomic fragments."

?

Thanks!

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

---

From: Fernando Gont <[email-masked]>
Date: Wed, 20 Aug 2014 16:34:00 -0300

On 08/20/2014 03:51 PM, Bob Briscoe wrote:
> The idea that IPv6 can declare that the min MTU will be 1280 stems from
> the idea that every link technology will have to implement an
> encapsulation of v6, so implementers should be able to ensure this new
> min MTU will always be honoured. However, that thinking overlooks the
> fact that IPv4 can also act as a 'link technology' for IPv6.

My understanding is that, when you employ IPv4 as a "link technology"
for IPv6, you need to offer IPv6 an MTU of at least 1280 bytes (e.g., by
relying on IPv4 fragmentation).

Note: I'm not arguing whether that's a good idea or not, but rather that
it's "doable".

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Aug 2014 08:47:39 +1200

> relying on IPv4 fragmentation).

That is an explicit requirement for v6-in-v4 tunnels in RFC 4213.
(See text and pseudo-code in section 3.2.2.) There is no get-out-of-jail
card for the 1280 MTU.

    Brian

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 20 Aug 2014 19:51:09 +0100

Fernando,

>this ICMPv6 PTB that claims an MTU smaller than 1280?".

The idea that IPv6 can declare that the min MTU will be 1280 stems 
from the idea that every link technology will have to implement an 
encapsulation of v6, so implementers should be able to ensure this 
new min MTU will always be honoured. However, that thinking overlooks 
the fact that IPv4 can also act as a 'link technology' for IPv6. And 
IPv4 doesn't enforce IPv6's min MTU for the link technologies over 
which it has already been implemented.

The designers of IPv6 might have wanted to pretend that v6 could make 
a clean break from IPv4 where MTU is concerned, but the IETF's prime 
objective is to ensure interworking (esp. between the two Internet 
protocols), which has to involve some compromises on the purity of v6.

Bob

---

From: Antonios Atlasis <[email-masked]>
Date: Thu, 21 Aug 2014 17:27:15 +0300

Hi,

please, allow me a comment from my side:

- If Atomic Fragments are/can be more or less useless (as I derived from
some parts of the proposed RFC and from some of the Fernando's comments),
then, no matter if there are security implications or not, please deprecate
them. That simple.

- However, if I did not understand correctly and, by any chance, you
believe that they serve some purpose, I believe that a) we should examine
carefully the scale of these security implications, b) we should check if
there are / can be some other mitigation techniques. For instance,
regarding TCP traffic at least, both end-hosts and (stateful) firewalls
keep track of the their connections. So, it can be easy for them to check
whether the incoming ICMPv6 Packet Too Big messages come as a response to a
corresponding outgoing TCP packet or not (since PTB messages contain at
least the header that triggered them).

Just some thoughts

Best

Antonios

2014-08-20 23:47 GMT+03:00 Brian E Carpenter <[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: Philip Homburg <[email-masked]>
Date: Thu, 21 Aug 2014 11:13:02 +0200

>which it has already been implemented.

IPv6 over IPv4 works fine if you use IPv4 fragmentation.

The problem starts when the tunnel endpoint is not an IPv4 host but some
kind of stateless IPv6 to IPv4 translator. Then you need an IPv4 MTU of 1260.

Not a real problem, just limit stateless IPv6 to IPv4 translators to
situations where you know that the IPv4 path MTU is big enough.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 21 Aug 2014 11:59:52 -0300

Hi, Antonios,

Thanks so much for your feedback! -- Comments in-line...

On 08/21/2014 11:27 AM, Antonios Atlasis wrote:
> some parts of the proposed RFC and from some of the Fernando's
> comments), then, no matter if there are security implications or not,
> please deprecate them. That simple.

Truth is that, besides the security implications, there are
interoperability problems. Please see the message with subject "Atomic
fragments (interoperability issues)" I've just posted to this list.

> believe that they serve some purpose, 

Well, they are certainly used for "something" (essentially signaling
between the IPv6 node and the translator whether the DF bit should be
set or not).

>I believe that a) we should examine carefully the scale of these security implications,

The scale is simple: It's trivial to trigger their use. And since IPv6
fragments are widely dropped, that can be exploited for DoS.

Let me give one concrete example:
Google filters IPv6 fragments. Now, if I now you're mailserver IPv6
address and the IPv6 addresses to which gmail.com will map to, I can
essentially prevent mail being delivered from your mailserver, to gmail.

Now let's replace "your mailserver" with, say, Yahoo.. and if they
happen to honor ICMPv6 PTB<1280, they are subject to the same sort of
attack.

Try the "recipe" I provided in one of my earlier emails about this topic
(employing the icmp6 tool), and see it for yourself.

> b) we should
> check if there are / can be some other mitigation techniques. For
> instance, regarding TCP traffic at least, both end-hosts and (stateful)
> firewalls keep track of the their connections. 

All the IPv6 implementations I recall checking do not enforce any kind
of validation on the embedded IPv6 packet.

And, in a sense, there's a reason for that: because of extension header
(yes) you are not guaranteed to get the upper-layer header of the
original apcket (the one that triggered the error) in the ICMPv6 payload.

Thanks!

Cheers,

---

From: Antonios Atlasis <[email-masked]>
Date: Thu, 21 Aug 2014 18:19:40 +0300

Hi Fernando,

I appreciate your response. Going directly to my final point:

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

> ...

> ...
> original apcket (the one that triggered the error) in the ICMPv6 payload.

So, since they are used for sthg, as you said, why not focusing on
mitigation? You get the upper layer because you get the PTB messages
(that's the upper layer) - unless of course you filter them deliberately
(in which case, the filtering devices still gets it, in order to filter it)
and the header of the protocol that triggered the legitimate PRB messages
is the payload of this upper layer. So, you do not have to get yet another
upper layer.

A final rhetorical question to all: Should the "design" (or at least, the
update) of a protocol be driven from what is currently enforced, to
whatever extend, OR should it aim at optimizing features like
functionality, interoperability, etc. AND security, of course, and finally,
proper implementation has to follow?

I have posted some similar, more extended thoughts about this subjecy, as a
"Personal Comment" at this blogpost, for those who may be interested:
http://www.insinuator.net/2014/08/atomic-fragments-vs-fragmentation-in-the-ipv6-real-world/

Best

Antonios

---

From: Fernando Gont <[email-masked]>
Date: Thu, 21 Aug 2014 12:41:46 -0300

On 08/21/2014 12:19 PM, Antonios Atlasis wrote:
> mitigation?

Well, the mitigation is not to use them, since they are not really
necessary, and they tend to break SIIT in many environments.

(*Everything* can be used for "something".. the question is whether that
makes sense or not)

> You get the upper layer because you get the PTB messages
> (that's the upper layer)

Nope. When you get an ICMPv6, you get a piece of the packet that
originated the error message. In IPv4, you're guaranteed to get the full
IPv4 header, plus the first 8 bytes of the payload (which means you have
e.g. src IP, dst IP, src port, dst port, and TCP seq).

IN v6 that cannot be guaranteed, because of the same reason that, not
that long ago you were not even guaranteed to have the upper layer
header in the first fragment of a packet -- the uper-layer protocol can
be "padded" by extension headers.

Hence, you could just get "IPv6 header + a bunch of extension headers",
and no transport protocol header).

> A final rhetorical question to all: Should the "design" (or at least,
> the update) of a protocol be driven from what is currently enforced, to
> functionality, interoperability, etc. AND security, of course, and
> finally, proper implementation has to follow?

Not sure I've understood your question. But I'd say "a balance of both".

> I have posted some similar, more extended thoughts about this subjecy,
> as a "Personal Comment" at this blogpost, for those who may be
> interested:

Short answer:
A 15% failure rate is still horrible. -- Ask any company that e.g. makes
money out of visits whether they would deploy something with such a
failure rate.

Finally, one thing is IPv6 atomic fragments being accepted, and another
is atomic fragments being generated. Both things contribute their share
of failure to the use of IPv6 atomic fragments.

Thanks!

Cheers,

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 26 Aug 2014 19:39:56 +0100

Fernando,

Your wording is fine by me.

And thx for your and Brian's subsequent emails about what the specs 
say about v6-v4 translators, and Philip's about the practicality.

Cheers

Bob