[Int-area] Re: [tsv-area] Fwd: I-D ACTION:draft-heffner-frag-harmful-03.txt

[Bob Briscoe <[e-mail]>]

Matt, John,

1/ During the lifetime of this draft its scope has become restricted to 
soley describing the problem. That's good (and it's a good solid draft), 
but the abstract or intro needs to explictly say what it is deliberately 
not setting out to say (not describing partial solutions, not proposing 
solutions).

2/ Given the new restricted scope, the title is wrong - it's snappy, but 
not appropriate for this draft any more. It should be "Field Wrapping 
Problems with IP Fragmentation" or some such.

"IPv4 Fragmentation Considered Very Harmful" attributes blame squarely on 
the fragmentation protocol (as opposed to re-assembly implementations - see 
later). This title effectively says "You SHOULD NOT fragment with a 16b ID 
field", which is beyond what the text dares to say, and it's beyond what an 
informational draft should say.

Even if this was a BCP rather than informational, I would say it would be 
wrong to deprecate 16b fragmentation anyway. There are good reasons why 
fragmentation is useful (e.g. in tunnels), so we need to try really hard to 
find robust ways to do it before writing it off as deprecated. Saying it's 
very harmful should only be a last resort if we /prove/ it cannot ever be 
done robustly.

As we know, one way to fragment with improved robustness is to use more 
bits for the ID field. But if 16b fragmentation is a problem now, 32b 
fragmentation will be a problem in the future (not so distant future as 
Matt pointed out on int-area 
<http://osdir.com/ml/[e-mail]/msg00545.html>). IP is 
sufficiently pivotal at the neck of the hour glass that anything we say 
about it should endure for decades. I would contend that the IETF shouldn't 
condone putting off a problem to a later date when we know it will return. 
The present title leads us towards that sort of solution, implying "32b ID 
fields aren't [ever] very harmful" - on a draft that isn't even meant to be 
discussing solutions.

Given hierarchical layering is here to stay (and always has been), it would 
be more fruitful to admit that we need to be able to do fragmentation 
robustly and so we cannot avoid choosing an ID field width that will
- either not be wide enough at some future time
- or will be overly wasteful today.

In this vein, it would be useful to focus everyone on designing better 
re-assembly /implementations/ around a 16b fragmentation /protocol/ (see a 
possible idea below). There is no proof yet that we have reached the end of 
our innovation potential on this.

A sketch idea for a more robust re-assembly implementation:
On receipt of each fragment, within the re-assembly implementation increase 
the precision of the ID field by adding a "received timestamp" of 
sufficient precision. Then on a first pass, match fragments only if the 
fragment IDs match AND the timestamps are within a certain narrow range of 
each other. Otherwise hold the fragment and, as a last resort later, widen 
the timestamp range that will cause a match - perhaps when the fragment is 
about to be expired from the buffer (...rest of implementation left as an 
exercise for the reader).

In summary, a 16bit fragment ID field should be innocent until proven 
guilty. As long as the culprit might be /implementations/, the title 
shouldn't presume the IPv4 fragmentation /protocol/ is guilty.


3/ The draft should say something about how the problem gets worse if the 
sender uses a pseudo-random number generator for the IPid field (as recent 
versions of OpenBSD and some versions of FreeBSD do). Then there is no 
longer a deterministic wrapping problem, but there is /always/ some small 
probability of a clash within the max packet lifetime. A good ref for this is:

S. Bellovin, ``A Technique for Counting NATted Hosts,'' Proceedings of the 
Second Internet Measurement Workshop, November 2002. 
http://www.cs.columbia.edu/~smb/papers/fnat.pdf



Bob

At 07:06 06/12/2006, Lars Eggert wrote:
>Hi,
>
>could the people who had commented on the -02 revision during IETF LC
>please take a look whether the latest revision addresses their issues?
>
>Begin forwarded message:
>>A New Internet-Draft is available from the on-line Internet-Drafts
>>directories.
>>
>>         Title           : IPv4 Fragmentation Considered Very Harmful
>>         Author(s)       : J. Heffner, et al.
>>         Filename        : draft-heffner-frag-harmful-03.txt
>>         Pages           : 9
>>         Date            : 2006-12-5
>
>Thanks,
>Lars
>
>
>

____________________________________________________________________________
Notice: This contribution is the personal view of the author and does not 
necessarily reflect the technical nor commercial direction of BT plc.
____________________________________________________________________________
Bob Briscoe,                           Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    [phone] 



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