Subject: Re: Fragmentation-related security issues

From: Philip Homburg <[email-masked]>
Date: Thu, 02 Feb 2012 00:37:26 +0100

In your letter dated Tue, 31 Jan 2012 15:58:55 -0300 you wrote:
>On 01/31/2012 08:12 AM, Philip Homburg wrote:
>> "Such traffic absolutely occurs in the wild. I have three reasonably
>> busy name servers where this is logged as an error from the ipfw code,
>> e.g."
>> 
>> Inconclusive. We don't know why that traffic is there.
>> 
>> So, just remove that requirement from RFC-2460, and the problem is gone.
>
>If you're meaning to remove support for some feature from the standard
>on the basis that it is not used, then the *you* should prove that is
>not being used.

I'm not claiming that it is not used. The Internet is a very big place, proving
a negative is almost impossible.

One issue is, are atomic fragments used for anything other than stateless
IPv6/IPv4 translators? Unless I misunderstood you, you claimed there was such
usage. I can't find the message you were referring to, so I asked you for a
message ID. Instead you gave examples from another area, that seems consistent
with stateless translators.

The second issue is that in my opinion, sending atomic fragments to such
translators is a bad idea and should be deprecated. Assuming there is no other
use for atomic fragments, that implies to me that we should not spend any time
making it work better. Just let it die off.

Why is sending atomic fragments to translators a bad idea? Because the whole
IPv6 Internet has to support it (and will suffer the effects) and the use is
extremely limited.

There is some benefit when:
- The path between the translator and the IPv4 host has an mtu of less
  then 1280,
- and there is a one to one correspondance between IPv4 and IPv6 addresses (so
  using it in a traditional NAT context doesn't work)
- and the data flow from any IPv6 host to the IPv4 host does not exceed
  20 Mbit/s
- and the IPv6 host maintains a strict counter in the lower 16-bit of the
  fragment ID.

If any of those conditions are not met then either atomic fragments are not
needed, or having the translator generate the id in the IPv4 header is just
as good.

>I personally believe it is very dangerous to think about removing
>something without bothering to consider what might break, and without
>bothering whether there's stuff (such as translators) that depend on
>that feature.
>
>Fix the bug, and be done with it.

I'm not saying that any existing support has to be removed. Just let it be.
But fully supporting atomic fragments everywhere will have a lot of impact,
and that is in my opinion not worth the effort. So it best to stop now. And
not create any additional standards or recommendations on how to deal with or
generate atomic fragments.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 01 Feb 2012 22:04:16 -0300

> a negative is almost impossible.

At the very least, one should bother surveying implementations and/or
doing some measurements...

> IPv6/IPv4 translators? 

Weren't one of the pointers I provided about atomic fragments used for
the DNS?

> Unless I misunderstood you, you claimed there was such

See the post by <[email-masked]> in the thread about
"Fragmentation-related security issues".

> use for atomic fragments, 

You know that they say assumptions are the mother of all f* ups?

> that implies to me that we should not spend any time
> making it work better. Just let it die off

Let's agree to disagree.

.

> IPv6 Internet has to support it (and will suffer the effects) and the use is

What are "the effects"??

> and that is in my opinion not worth the effort. 

See the survey I posted. Everybody modulo NetBSD supports them.

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