John Heffner | 3 Apr 22:12 2006
Picon

Seeking comments on draft-heffner-frag-harmful-00

We're moving this doc through the AD-sponsored informational track. 
Though it's not a working group item, we'd like to solicit feedback 
(from both tsvwg and int-area).  Please note that the purpose of this 
document is only to describe a known problem, not a solution.

Abstract:
    IPv4 fragmentation is not sufficiently robust for general use in
    today's Internet.  The 16-bit IP identification field is not large
    enough to prevent frequent incorrectly assembled IP fragments, and
    the TCP and UDP checksums are insufficient to prevent the resulting
    corrupted datagrams from being delivered to higher protocol layers.
    This note describes some easily reproduced experiments demonstrating
    the problem, and discusses some of the operational implications of
    these observations.

Currently available at:
http://www.ietf.org/internet-drafts/draft-heffner-frag-harmful-00.txt

Thanks,
   -John

Rick Jones | 3 Apr 22:36 2006
Picon

Re: Seeking comments on draft-heffner-frag-harmful-00

John Heffner wrote:
> We're moving this doc through the AD-sponsored informational track. 
> Though it's not a working group item, we'd like to solicit feedback 
> (from both tsvwg and int-area).  Please note that the purpose of this 
> document is only to describe a known problem, not a solution.
> 
> Abstract:
>    IPv4 fragmentation is not sufficiently robust for general use in
>    today's Internet.  The 16-bit IP identification field is not large
>    enough to prevent frequent incorrectly assembled IP fragments, and
>    the TCP and UDP checksums are insufficient to prevent the resulting
>    corrupted datagrams from being delivered to higher protocol layers.
>    This note describes some easily reproduced experiments demonstrating
>    the problem, and discusses some of the operational implications of
>    these observations.
> 
> Currently available at:
> http://www.ietf.org/internet-drafts/draft-heffner-frag-harmful-00.txt

Ah, Frankengrams :) Fun things.  I remember we had "issues" wrt back in 
'91 or so even on 10 Mbit/s Ethernet.

> The case of particular concern occurs when the first fragment of a
> datagram is lost in the network.  The remaining fragments will be
> stored in the fragment reassembly buffer.  When the sender wraps the
> ID field, the first fragment of the new datagram will be mis-
> associated with the rest of the old datagram.  Assuming the fragments
> are delivered in order, the rest of the new datagram will be now be
> incomplete (since it is missing the first fragment), so they will be
> saved in the fragment reassembly buffer, forming a cycle that repeats
(Continue reading)

John Heffner | 4 Apr 00:09 2006
Picon

Re: Seeking comments on draft-heffner-frag-harmful-00

Rick Jones wrote:
>> The case of particular concern occurs when the first fragment of a
>> datagram is lost in the network.  The remaining fragments will be
>> stored in the fragment reassembly buffer.  When the sender wraps the
>> ID field, the first fragment of the new datagram will be mis-
>> associated with the rest of the old datagram.  Assuming the fragments
>> are delivered in order, the rest of the new datagram will be now be
>> incomplete (since it is missing the first fragment), so they will be
>> saved in the fragment reassembly buffer, forming a cycle that repeats
>> every 65536 datagrams.  It is possible to have a number of
>> simultaneous cycles, bounded by the size of the fragment reassembly
>> buffer.
> 
> Does it really matter if it is the first fragment?  I would think that 
> cycling is possible so long as (any of) the lost fragments are simply 
> not the last fragment when one assumes the fragments are flowing in-order.

It could matter.  If it's a middle fragment, you'll receive some 
duplicate earlier ones before the datagram can be completed.  If the OS 
has a consistency check here (that the data is the same), it could toss 
the whole thing when it fails.  I'm not aware of any implementation that 
does this, but if you're just talking about the first fragment, it's 
more clear that it's a problem.

> Also, to ass-u-me that fragments flow through the network in-order is 
> probably not a good thing?  Load-balanced link aggregates may send 
> fragments of one datagram across more than one link in the aggregate, 
> and I know of at least one NIC, albeit old and likely unused today, that 
> would send the first fragment last as part of accumulating an offloaded 
> Checksum (HP-PB FDDI NIC).
(Continue reading)

Rick Jones | 4 Apr 00:24 2006
Picon

Re: Seeking comments on draft-heffner-frag-harmful-00

>> Does it really matter if it is the first fragment?  I would think that 
>> cycling is possible so long as (any of) the lost fragments are simply 
>> not the last fragment when one assumes the fragments are flowing 
>> in-order.
> 
> 
> It could matter.  If it's a middle fragment, you'll receive some 
> duplicate earlier ones before the datagram can be completed.  If the OS 
> has a consistency check here (that the data is the same), it could toss 
> the whole thing when it fails.  I'm not aware of any implementation that 
> does this, but if you're just talking about the first fragment, it's 
> more clear that it's a problem.

Given the overhead such a consistency check would add, I doubt it would 
ever be implemented?  And the conssitency check rather depends on the 
transmission order remaining the same right?

>> Also, to ass-u-me that fragments flow through the network in-order is 
>> probably not a good thing?  Load-balanced link aggregates may send 
>> fragments of one datagram across more than one link in the aggregate, 
>> and I know of at least one NIC, albeit old and likely unused today, 
>> that would send the first fragment last as part of accumulating an 
>> offloaded Checksum (HP-PB FDDI NIC).
> 
> 
> However, data is often delivered in order, so it serves as a good 
> example. :)  Assuming in-order delivery is partially for the sake of 
> clarity.  Any order (reverse, first-packet-last) that's always repeated 
> has the same property.  A randomized delivery order is not as bad as the 
> worst case.
(Continue reading)

John Heffner | 4 Apr 00:44 2006
Picon

Re: Seeking comments on draft-heffner-frag-harmful-00

Rick Jones wrote:
> But it is still bad, and I worry (fear, uncertainty and doubt, oh my) 
> that someone reading the draft will say "oh, good, my  stack does things 
> in a different order so it must not be so bad"
> 
> Maybe just some "while we use in-order as an example the problem is 
> still present and bad with other packet orderings" text.

Will try to make this a little more clear.  Thanks for the input.

>>> A while back, over in the "netdev" mailing list, the we were 
>>> discussing ways to minimize the risk of frankengrams springing to 
>>> life based on ass-u-me-ing :) that if one saw N or more datagrams 
>>> beyond the one(s) being reassembled, the likelihood of those 
>>> datagrams successfully reassembling was epsilon. While the specifics 
>>> of that may be more "linux-centric" than an RFC should be, I suspect 
>>> the discussion might provide a starting point for a useful, 
>>> additional section in the RFC discussing ways transport stacks might 
>>> minimize the likelihood of Frankengrams.
>>
>>
>> It would be a good place to start for a *future* draft on the subject. 
>> We decided it is out of scope for this one.
> 
> Maybe it is drifting a bit, but isn't it rather like announcing a 
> vulnerabilty without announcing how to mitigate it?

I'd say it's more like when a bridge is out, first putting up a warning 
sign, then worrying about how to fix it. ;)

(Continue reading)

Rick Jones | 4 Apr 01:11 2006
Picon

Re: Seeking comments on draft-heffner-frag-harmful-00

>> Maybe it is drifting a bit, but isn't it rather like announcing a 
>> vulnerabilty without announcing how to mitigate it?
> 
> 
> I'd say it's more like when a bridge is out, first putting up a warning 
> sign, then worrying about how to fix it. ;)

Well, most poeple already know how to mitigate the problems from a 
bridge being out :)

And since you've basically told the script kiddies "Hey, here is 
something else for you to try..."

> Seriously, we considered writing a section like this.  But on careful 
> thought, it was not obvious how to mitigate the problem robustly.  The 
> Linux solution works pretty well under specific conditions, but writing 
> a BCP on how to safely use fragmentation for high bandwidth apps could 
> get thorny.  The safest thing to do is just not use fragmentation for 
> these apps, or if you absolutely must, at least add protection (like 
> IPsec).

True enough.  But as you point-out in the RFC, there are cases where 
applications are indeed trying to avoid the use of fragmentation, but 
those intermediate devices are hindering it.

Ain't life grand when the fundamental assumptions shift?-)

rick jones

(Continue reading)

Erblichs | 3 Apr 23:53 2006
Picon
Picon

Re: Seeking comments on draft-heffner-frag-harmful-00

John Heffner,

	Interesting..

	A few Short comments.. Possible fixes in #1, #4, #5, and #6.

	1) Does your 26 Mbps flow rate in section 2, almost imply that
	a connection should be multiplexed so that each sub connection
	has a bps rate of 26Mbps to remove this issue in IPv4 if
	fragmentation is an issue?

	2) How does xmit of say a 9k jumbo segments effect this?
	 Wasn't their work into accepting 9k size segments a few
	 years back?

	3) Does the use of say a 3/4 multiplier for the actual transmit
	size decrease the linklyhood of a fragment? Could we have tacked
	an additional header that caused the fragmentation, that this
	would fix?

	4) If a fragment does occur and out-of-order segments are
	seen should a algor like the fast-xmit used be implimented
	to drop the partial set of recv'd fragments. TCP will force the
	entire set to be rexmit'ed, right?

	5) Some datagrams being delivered to a system are comprised
	   of distinct objects which if modified are detected.
	    
          - compressed files.

(Continue reading)

John Heffner | 4 Apr 02:49 2006
Picon

Re: Seeking comments on draft-heffner-frag-harmful-00

Erblichs wrote:
> John Heffner,
> 
> 	Interesting..
> 
> 	A few Short comments.. Possible fixes in #1, #4, #5, and #6.
> 
> 	1) Does your 26 Mbps flow rate in section 2, almost imply that
> 	a connection should be multiplexed so that each sub connection
> 	has a bps rate of 26Mbps to remove this issue in IPv4 if
> 	fragmentation is an issue?

The problem occurs independently of flows.  It only depends on src,dst 
address pair.

> 	2) How does xmit of say a 9k jumbo segments effect this?
> 	 Wasn't their work into accepting 9k size segments a few
> 	 years back?

Using 9k frames instead of 1500 as in the examples scale the rate at 
which the problem can occur up by a factor of six.

> 	3) Does the use of say a 3/4 multiplier for the actual transmit
> 	size decrease the linklyhood of a fragment? Could we have tacked
> 	an additional header that caused the fragmentation, that this
> 	would fix?

There are many ways fragments can be created, not just from an extra 
tunnel header.  For example, it's natural to want to send 
disk-block-sized datagrams.  If the block size is >PMTU, then you end up 
(Continue reading)

Fred Baker | 4 Apr 03:04 2006
Picon

Re: [Tsvwg] Seeking comments on draft-heffner-frag-harmful-00


On Apr 3, 2006, at 4:11 PM, Rick Jones wrote:

> And since you've basically told the script kiddies "Hey, here is  
> something else for you to try..."

I could be completely misinformed, but I thought fragmentation  
attacks weren't news? Saying there are issues in an RFC isn't  
anywhere near as bad as naming the vendor in the discussion of the  
vulnerability...

http://www-src.lip6.fr/homepages/Fabrice.Legond-Aubry/www.ouah.org/ 
fragma.html
Rick Jones | 4 Apr 03:12 2006
Picon

Re: Seeking comments on draft-heffner-frag-harmful-00

> 	2) How does xmit of say a 9k jumbo segments effect this?
> 	 Wasn't their work into accepting 9k size segments a few
> 	 years back?

While the IETF may have said something wrt "jumbo frames" I don't think 
the IEEE has sanctioned them.  I'm not sure if they ever will.

rick jones


Gmane