Subject: [Int-area] Seeking comments on draft-heffner-frag-harmful-00

From: John Heffner <[email-masked]>
Date: Mon, 03 Apr 2006 16:12:33 -0400

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

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: John Heffner <[email-masked]>
Date: Mon, 03 Apr 2006 18:09:06 -0400

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

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.

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

Thanks,
   -John

---

From: John Heffner <[email-masked]>
Date: Mon, 03 Apr 2006 18:44:48 -0400

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

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

Thanks,
   -John

---

From: John Heffner <[email-masked]>
Date: Mon, 03 Apr 2006 20:49:31 -0400

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

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

What you're describing is like what Linux does now.  It works pretty 
well under most realistic conditions.  Aside from some theoretical 
corner cases, a couple practical issues:

1) The sender has no way of knowing that the receiver is implementing this.

2) NATs.

> 	5) Some datagrams being delivered to a system are comprised
> 	   of distinct objects which if modified are detected.
> 	    
>           - compressed files.
> 
> 	   I assume that the distinct items being created is not in the
> 	   scope of this memo, but decrease the chance of a TCP checksum
> 	   being accepted at a higher layer.
> 
> 	   However, if the above is true, would it be wise on some object
> 	   types to do a non-lossy compression before xmit knowing that the
> 	   expand would detect any abnormalities????

You could...  Cryptographic hashes would be better yet.

> 	6) It sounds like some type of SACK ack that states
> 	   fragmented segment dropped, redo your path MTU and decrease
> 	   segment size; is NEEDED.

When MTU discovery is working, and the DF bit is not ignored, it should 
be adequate.

Thanks,
   -John

---

From: Fred Baker <[email-masked]>
Date: Mon, 3 Apr 2006 18:04:50 -0700

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