Re: [tsv-area] Fwd: I-D ACTION:draft-heffner-frag-harmful-03.txt
Bob Briscoe <rbriscoe@jungle.bt.co.uk> Wed, 03 January 2007 13:45 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H26R8-0004zj-MI; Wed, 03 Jan 2007 08:45:46 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H26R7-0004s4-CY for tsv-area@ietf.org; Wed, 03 Jan 2007 08:45:45 -0500
Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H26R2-0000Oa-LP for tsv-area@ietf.org; Wed, 03 Jan 2007 08:45:45 -0500
Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jan 2007 13:45:39 +0000
Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 3 Jan 2007 13:45:36 +0000
Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1167831935499; Wed, 3 Jan 2007 13:45:35 +0000
Received: from mut.jungle.bt.co.uk ([10.215.130.159]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l03DjVSI006017; Wed, 3 Jan 2007 13:45:33 GMT
Message-Id: <5.2.1.1.2.20070103113937.046cf228@pop3.jungle.bt.co.uk>
X-Sender: rbriscoe@pop3.jungle.bt.co.uk
X-Mailer: QUALCOMM Windows Eudora Version 5.2.1
Date: Wed, 03 Jan 2007 13:45:42 +0000
To: Matt Mathis <mathis@psc.edu>, John Heffner <jheffner@psc.edu>
From: Bob Briscoe <rbriscoe@jungle.bt.co.uk>
Subject: Re: [tsv-area] Fwd: I-D ACTION:draft-heffner-frag-harmful-03.txt
In-Reply-To: <A6F8775A-30E5-41D5-B6D0-E9A9FA945260@netlab.nec.de>
References: <E1GrhEn-0004XJ-NE@stiedprstage1.ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: -1.36 () ALL_TRUSTED
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
X-OriginalArrivalTime: 03 Jan 2007 13:45:36.0895 (UTC) FILETIME=[72CDD0F0:01C72F3D]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f
Cc: int-area@ietf.org, tsv-area@ietf.org
X-BeenThere: tsv-area@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF Transport Area Mailing List <tsv-area.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tsv-area>
List-Post: <mailto:tsv-area@ietf.org>
List-Help: <mailto:tsv-area-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=subscribe>
Errors-To: tsv-area-bounces@ietf.org
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/int-area@lists.ietf.org/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. +44 1473 645196
- [tsv-area] Fwd: I-D ACTION:draft-heffner-frag-har… Lars Eggert
- Re: [tsv-area] Fwd: I-D ACTION:draft-heffner-frag… Bob Briscoe
- Re: [tsv-area] Fwd: I-D ACTION:draft-heffner-frag… John Heffner
- fragmentation and tunnels (was: RE: [Int-area] Re… Templin, Fred L
- RE: [Int-area] Re: [tsv-area] Fwd: I-DACTION:draf… Templin, Fred L
- Re: [tsv-area] Fwd: I-D ACTION:draft-heffner-frag… Bob Briscoe
- Re: fragmentation and tunnels (was: RE: [Int-area… Bob Briscoe
- RE: fragmentation and tunnels (was: RE: [Int-area… Templin, Fred L
- RE: fragmentation and tunnels (was: RE: [Int-area… Bob Briscoe
- RE: fragmentation and tunnels (was: RE: [Int-area… Templin, Fred L