headers
RJ Atkinson | 3 Jan 2012 01:21
Picon

Re: Fragmentation-related security issues

Earlier, Fernando Gont wrote, in part:
> ... my question was about whether the "atomic fragments"
> that were found in the wild were the result of translators,
> or of IPv6 networks that "violate" the standard and
> do not support an MTU of >= 1280.

I have been told of real-world IPv6 deployments
where the link MTU is smaller than 1280, 
while the limited link bandwidth makes adding a new 
segmentation protocol layer impractical.  I believe 
these account for some of the 576 byte or 512 byte
advertised Link MTU sizes in IPv6 PMTU "Too Big" 
messages that are seen in the real world.

I also know of real-world IPv6 deployments with
translators.  I expect translators to become 
much more common soon.

As far as I am aware, neither of the above would
produce PMTU "Too Big" messages with an advertised
link MTU very much under 500 bytes.  

IMHO, the 1280 byte number is far too big for a
minimum IPv6 MTU.  I've held the view that much 
above 512 bytes is problematic on RF links for 
MANY years now, as the Minutes from long ago
illustrate (search for "MTU"):

<ftp://ftp.ietf.org/ietf-online-proceedings/94dec/area.and.wg.reports/ipng/ipngwg/ipngwg-minutes-94dec.txt>
(Continue reading)

Permalink | Reply |
headers
Philip Homburg | 3 Jan 2012 10:31

Re: Fragmentation-related security issues

In your letter dated Mon, 2 Jan 2012 19:21:45 -0500 you wrote:
>I have been told of real-world IPv6 deployments
>where the link MTU is smaller than 1280, 
>while the limited link bandwidth makes adding a new 
>segmentation protocol layer impractical.  I believe 
>these account for some of the 576 byte or 512 byte
>advertised Link MTU sizes in IPv6 PMTU "Too Big" 
>messages that are seen in the real world.

So if you run TCP over such a link then you an get extra overhead of more than
60 octets (IPv6 header + TCP header) compared to a link with an MTU of 1280.
For UDP the amount is about the same (IPv6, fragment header, UDP header).

And you are saying that that sort of overhead doesn't warrant finding an unused
bit somewhere to signal an adaptation layer?

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Permalink | Reply |
headers
RJ Atkinson | 3 Jan 2012 13:32
Picon

Re: Fragmentation-related security issues


On 03  Jan 2012, at 04:31 , Philip Homburg wrote:
> In your letter dated Mon, 2 Jan 2012 19:21:45 -0500 you wrote:
>> I have been told of real-world IPv6 deployments
>> where the link MTU is smaller than 1280, 
>> while the limited link bandwidth makes adding a new 
>> segmentation protocol layer impractical.  I believe 
>> these account for some of the 576 byte or 512 byte
>> advertised Link MTU sizes in IPv6 PMTU "Too Big" 
>> messages that are seen in the real world.
> 
> So if you run TCP over such a link then you an get
> extra overhead of more than 60 octets (IPv6 header + TCP header)
> compared to a link with an MTU of 1280.  For UDP
> the amount is about the same (IPv6, fragment header, UDP header).
> 
> And you are saying that that sort of overhead
> doesn't warrant finding an unused bit somewhere
> to signal an adaptation layer?

Of course an adaptation layer has various costs 
beyond a single bit, but please also consider the 
case where there are no unused bits at hand.

I'm saying the folks responsible for such links 
tell me they have looked into it in detail, tell me
they looked at the whole problem including all
of the system impacts and costs, and tell me that 
they concluded that it was MUCH better to continue 
to use IPv6 without adaptation layer overhead.
(Continue reading)

Permalink | Reply |
headers
Philip Homburg | 3 Jan 2012 23:57

Re: Fragmentation-related security issues

In your letter dated Tue, 3 Jan 2012 07:32:17 -0500 you wrote:
>Of course an adaptation layer has various costs 
>beyond a single bit, but please also consider the 
>case where there are no unused bits at hand.

Well, Van Jacobson made his header compression work with SLIP. And everybody
was happy.

>The choice of minimum IPv6 Link MTU is necessarily
>somewhat arbitrary.  Different numbers are optimal
>for different deployments.  It is merely sad that
>the IETF chose such a large number.
>
>The other approach I've heard about being taken
>for working over small MTU links is simply to 
>perform (one-way) IPv6->IPv4 protocol translation, 
>since IPv4 works natively on links that small.  
>It seems sad that the IETF decision is pushing 
>people towards a protocol translation approach.

What I see in IPv4 PMTU and also IPv6 PMTU is:
- it just doesn't work reliably.
- for IPv4 MSS clamping is widespread to make TCP work. and UDP just gets 
  fragmented.
- For IPv6, given that the host has to do the fragmentation, a big minimum
  MTU is required. Otherwise, too much stuff will end up being fragmented at
  576.

My guess is, that anybody who is running a links at less than 1280 is just
going to get a lot of trouble. That applies both to the links you mentioned
(Continue reading)

Permalink | Reply |
headers
RJ Atkinson | 4 Jan 2012 12:36
Picon

Re: Fragmentation-related security issues


On 03  Jan 2012, at 17:57 , Philip Homburg wrote:
> - For IPv6, given that the host has to do the fragmentation,
>   a big minimum MTU is required. Otherwise, too much stuff
>   will end up being fragmented at 576.

There is no evidence for the claim above.  When the minimum 
Link MTU for IPv6 *was* set to 576, that did not happen.

Instead, most traffic was Ethernet MTU without fragmentation,
and the next most common packet size was (Ethernet MTU -
overhead for DSL encapsulation/tunnelling).  Packets at
576 were seen -- but very very infrequently -- so they
were NOT a particular burden on the end systems.

> My guess is, that anybody who is running a links at less
> than 1280 is just going to get a lot of trouble. That applies
> both to the links you mentioned and any IPv6-to-IPv4 translators.

Clearly it is more complex to run an IPv6 link below 1280 today
than it was when IPv6 specifications supported a 576 byte MTU.
Folks with such links tell me that it mostly works today.

IPv6-IPv4 translators aren't going away.  There are lots
of other reasons they get deployed -- including transition
and interoperability.

> Most IPv4 links are bigger than 1280. So, those translators will seem to work
> in most cases. IPv4 links smaller than 1280 will just see failures that
> are quite hard to debug.
(Continue reading)

Permalink | Reply |
headers
Philip Homburg | 4 Jan 2012 13:17

Re: Fragmentation-related security issues

In your letter dated Wed, 4 Jan 2012 06:36:25 -0500 you wrote:
>
>On 03  Jan 2012, at 17:57 , Philip Homburg wrote:
>> - For IPv6, given that the host has to do the fragmentation,
>>   a big minimum MTU is required. Otherwise, too much stuff
>>   will end up being fragmented at 576.
>
>There is no evidence for the claim above.  When the minimum 
>Link MTU for IPv6 *was* set to 576, that did not happen.

RFC-2460 is from 1998. You are talking about the IPv6 network before 1998?
And that resembles todays IPv6 internet in what way?

>Instead, most traffic was Ethernet MTU without fragmentation,
>and the next most common packet size was (Ethernet MTU -
>overhead for DSL encapsulation/tunnelling).  Packets at
>576 were seen -- but very very infrequently -- so they
>were NOT a particular burden on the end systems.

Except that DNS(SEC) packets will be fragmented at the mimimum MTU
(see for example the discussion in
http://tools.ietf.org/html/draft-andrews-dnsext-udp-fragmentation-00)

Setting the minimum MTU to 576 has to potential to cause of damage to DNSSEC.

>> My guess is, that anybody who is running a links at less
>> than 1280 is just going to get a lot of trouble. That applies
>> both to the links you mentioned and any IPv6-to-IPv4 translators.
>
>Clearly it is more complex to run an IPv6 link below 1280 today
(Continue reading)

Permalink | Reply |
headers
RJ Atkinson | 4 Jan 2012 14:46
Picon

Re: Fragmentation-related security issues


On 04  Jan 2012, at 07:17 , Philip Homburg wrote:
> RFC-2460 is from 1998. You are talking about the IPv6 network
> before 1998?  And that resembles todays IPv6 internet in what way?

The network layer is largely the same.  Routing 
is largely the same, except that table sizes
always seem to increase.  Certainly transport
protocols are largely the same.  We now have SCTP,
although it seems not yet widely deployed.

I very much hope DNSsec will become much more 
widely deployed.  I have spent a fair amount of
energy over the past ~15 years helping to ensure 
that [other folks'] DNSsec-related R&D would be 
funded. 

The bulk of the Internet continues to use IPv4 today, 
and probably will for the next decade.  The IPv4 
specifications and widely deployed IPv4 
implementations both support a 576 byte Link MTU.

So DNSsec will need to work over 576 byte links 
just to be deployable in the bulk of the deployed
Internet.  That might be awkward, or sub-optimal, 
but it is not a recent development.

> When I set the link MTU of my WAN link to 576, 
> VoIP stops working (over IPv4).
(Continue reading)

Permalink | Reply |
headers
Philip Homburg | 4 Jan 2012 16:24

Re: Fragmentation-related security issues

In your letter dated Wed, 4 Jan 2012 08:46:31 -0500 you wrote:
>On 04  Jan 2012, at 07:17 , Philip Homburg wrote:
>> RFC-2460 is from 1998. You are talking about the IPv6 network
>> before 1998?  And that resembles todays IPv6 internet in what way?
>
>The network layer is largely the same.  Routing 
>is largely the same, except that table sizes
>always seem to increase.  Certainly transport
>protocols are largely the same.  We now have SCTP,
>although it seems not yet widely deployed.

Yes, but PMTU failures are not a protocol issue. Is it is an operational issue.
So when the IPv6 network is just a bunch of techies who are connected by
tunnels, you expect PMTU to sort of work. 

By the time the internet is big is enough that some routers just send ICMPs
with link local source and nobody notices, then PMTU starts to break down.

>The bulk of the Internet continues to use IPv4 today, 
>and probably will for the next decade.  The IPv4 
>specifications and widely deployed IPv4 
>implementations both support a 576 byte Link MTU.
>
>So DNSsec will need to work over 576 byte links 
>just to be deployable in the bulk of the deployed
>Internet.  That might be awkward, or sub-optimal, 
>but it is not a recent development.

I'm sure you know about the small difference between IPv4 and IPv6 when it
comes to fragmentation. For IPv4, if a DNS server need to send a, say, 1000
(Continue reading)

Permalink | Reply |
headers
RJ Atkinson | 4 Jan 2012 19:47
Picon

Re: Fragmentation-related security issues


On 04  Jan 2012, at 10:24 , Philip Homburg wrote:
> Yes, but PMTU failures are not a protocol issue.
> Is it is an operational issue.  So when the IPv6
> network is just a bunch of techies who are connected by
> tunnels, you expect PMTU to sort of work. 

I didn't expect it to work, given the history of PMTU
in the deployed Internet.  When it does work, PMTU is 
wonderful.  It has not been reliable for IPv4 either.

> By the time the internet is big is enough that some
> routers just send ICMPs with link local source and
> nobody notices, then PMTU starts to break down.

We have long standing experience with PMTU.  It hasn't
been completely reliable for IPv4.  It is no surprise 
that it is not completely reliable for IPv6 either.

> I'm sure you know about the small difference between IPv4 and IPv6
> when it comes to fragmentation. For IPv4, if a DNS server need
> to send a, say, 1000 octet reply then it can just send it.
> If necessary, routers on the way will fragment the reply.

Actually, IPv4 routers generally won't fragment the reply
for too-big IPv4 packets -- not even if the DF bit allows
them to do so.  Most deployed IPv4 transit routers 
disabled all router fragmentation of IPv4 packets 
years ago.
(Continue reading)

Permalink | Reply |
headers
Templin, Fred L | 4 Jan 2012 22:53
Picon
Favicon

RE: Fragmentation-related security issues


> -----Original Message-----
> From: ipv6-bounces <at> ietf.org [mailto:ipv6-bounces <at> ietf.org] On 
> Behalf Of RJ Atkinson
> Sent: Wednesday, January 04, 2012 10:47 AM
> To: ipv6 <at> ietf.org
> Subject: Re: Fragmentation-related security issues 
> 
> 
> On 04  Jan 2012, at 10:24 , Philip Homburg wrote:
> > Yes, but PMTU failures are not a protocol issue.
> > Is it is an operational issue.  So when the IPv6
> > network is just a bunch of techies who are connected by
> > tunnels, you expect PMTU to sort of work. 
> 
> I didn't expect it to work, given the history of PMTU
> in the deployed Internet.  When it does work, PMTU is 
> wonderful.  It has not been reliable for IPv4 either.
> 
> > By the time the internet is big is enough that some
> > routers just send ICMPs with link local source and
> > nobody notices, then PMTU starts to break down.
> 
> We have long standing experience with PMTU.  It hasn't
> been completely reliable for IPv4.  It is no surprise 
> that it is not completely reliable for IPv6 either.
> 
> > I'm sure you know about the small difference between IPv4 and IPv6
> > when it comes to fragmentation. For IPv4, if a DNS server need
> > to send a, say, 1000 octet reply then it can just send it.
(Continue reading)

Permalink | Reply |
headers
RJ Atkinson | 4 Jan 2012 23:44
Picon

Re: Fragmentation-related security issues


On 04  Jan 2012, at 16:53 , Templin, Fred L wrote:
> "Most deployed IPv4 transit routers disabled all router
> fragmentation of IPv4 packets years ago." Are you sure
> about that? Because, I have had at least one person from
> a major router vendor tell me that router fragmentation
> is well supported in their products.

I have no doubt their product possesses the capability.
That is subtly different from folks responsible for
configuring routers disabling that capability in 
particular routers of a particular deployment.

I was referring to the latter, not the former.
My apologies for being unclear.

Yours,

Ran

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Permalink | Reply |
headers
Templin, Fred L | 5 Jan 2012 00:11
Picon
Favicon

RE: Fragmentation-related security issues

Hi Ran, 

> -----Original Message-----
> From: ipv6-bounces <at> ietf.org [mailto:ipv6-bounces <at> ietf.org] On 
> Behalf Of RJ Atkinson
> Sent: Wednesday, January 04, 2012 2:44 PM
> To: ipv6 <at> ietf.org
> Subject: Re: Fragmentation-related security issues 
> 
> 
> On 04  Jan 2012, at 16:53 , Templin, Fred L wrote:
> > "Most deployed IPv4 transit routers disabled all router
> > fragmentation of IPv4 packets years ago." Are you sure
> > about that? Because, I have had at least one person from
> > a major router vendor tell me that router fragmentation
> > is well supported in their products.
> 
> I have no doubt their product possesses the capability.
> That is subtly different from folks responsible for
> configuring routers disabling that capability in 
> particular routers of a particular deployment.

This can only be done at the peril of black-holing
DF=0 packets that are too large. Meaning, either the
responsible folks have a high degree of certainty that
their core links will pass the packets w/o loss due to
an MTU restriction, or they just don't care that large
packets are silently lost. So, it has to be the former
since folks that just don't care don't stay in business.
(Continue reading)

Permalink | Reply |
headers
Shane Amante | 5 Jan 2012 00:59

Re: Fragmentation-related security issues

Fred, Ran,

On Jan 4, 2012, at 4:11 PM, Templin, Fred L wrote:
> Hi Ran, 
> 
>> -----Original Message-----
>> From: ipv6-bounces <at> ietf.org [mailto:ipv6-bounces <at> ietf.org] On 
>> Behalf Of RJ Atkinson
>> Sent: Wednesday, January 04, 2012 2:44 PM
>> To: ipv6 <at> ietf.org
>> Subject: Re: Fragmentation-related security issues 
>> 
>> 
>> On 04  Jan 2012, at 16:53 , Templin, Fred L wrote:
>>> "Most deployed IPv4 transit routers disabled all router
>>> fragmentation of IPv4 packets years ago." Are you sure
>>> about that? Because, I have had at least one person from
>>> a major router vendor tell me that router fragmentation
>>> is well supported in their products.
>> 
>> I have no doubt their product possesses the capability.
>> That is subtly different from folks responsible for
>> configuring routers disabling that capability in 
>> particular routers of a particular deployment.
> 
> This can only be done at the peril of black-holing
> DF=0 packets that are too large. Meaning, either the
> responsible folks have a high degree of certainty that
> their core links will pass the packets w/o loss due to
> an MTU restriction, or they just don't care that large
(Continue reading)

Permalink | Reply |

Gmane