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

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:ipv6-bounces@ietf.org] 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,

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 <fgont@si6networks.com<mailto:fgont@si6networks.com>> wrote:
Hi, Eric,

On 01/06/2016 12:47 PM, Eric Vyncke (evyncke) wrote:
> 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.

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
> 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.

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

> 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.

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,
--
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com<javascript:;>
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

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