Re: [Int-area] FW: Last Call: 'Fragmentation Considered Very Harmful' to Informational RFC (draft-heffner-frag-harmful)

Joe Touch <touch@ISI.EDU> Sat, 14 October 2006 20:44 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYqMf-0001NX-Iw; Sat, 14 Oct 2006 16:44:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYqMe-0001NP-EO for int-area@ietf.org; Sat, 14 Oct 2006 16:44:12 -0400
Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYqMd-0002FE-1x for int-area@ietf.org; Sat, 14 Oct 2006 16:44:12 -0400
Received: from [192.168.1.42] (pool-71-106-94-15.lsanca.dsl-w.verizon.net [71.106.94.15]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id k9EKhRfg018265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 14 Oct 2006 13:43:29 -0700 (PDT)
Message-ID: <45314BE8.8000600@isi.edu>
Date: Sat, 14 Oct 2006 13:43:20 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: Matt Mathis <mathis@psc.edu>
Subject: Re: [Int-area] FW: Last Call: 'Fragmentation Considered Very Harmful' to Informational RFC (draft-heffner-frag-harmful)
References: <E1GXMkr-00060i-VM@stiedprstage1.ietf.org> <452C71DA.60708@piuha.net> <452CFDC7.4010003@isi.edu> <Pine.LNX.4.58.0610131613520.2581@tesla.psc.edu> <453019DE.9040001@isi.edu> <Pine.LNX.4.58.0610141351350.2581@tesla.psc.edu>
In-Reply-To: <Pine.LNX.4.58.0610141351350.2581@tesla.psc.edu>
X-Enigmail-Version: 0.94.0.0
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 386e0819b1192672467565a524848168
Cc: int-area@ietf.org
X-BeenThere: int-area@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/int-area>
List-Post: <mailto:int-area@lists.ietf.org>
List-Help: <mailto:int-area-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1201969167=="
Errors-To: int-area-bounces@lists.ietf.org


Matt Mathis wrote:
> On Fri, 13 Oct 2006, Joe Touch wrote:
> 
>>> (*mostly, because the other route is to strictly enforce the IP ID wrap time
>>> and fragment lifetimes.)
>> I'd prefer that approach to deliberately encourage breaking fragmentation.
> 
> let me get this straight: you would like to declare all IPv4 TCP
> connections running at full speed over fast Ethernet and faster to be
> protocol violations?  Some how I don't think others would agree.

Unless they stripe across separate IP addresses or ports, they are
violations of 791. We can change that, but we have not yet. Until we do,
it is a violation.

>>> (Ok one caveat: tunnels can also work if they greatly strengthen the IP ID
>>> and/or do their own fragmentation).
>> This is the bigger issue. Tunnels supposed to honor the DF bit, but
>> basically cannot. There are two alternatives:
>>
>> - clear DF in the outer header and take your chances
> 
> You missed my point (and part of why the problem space starts looking
> fractal).  If you think of the tunnel as a separate protocol that uses
> additional methods to protect itself from corruption (say by use of IPSEC, or
> an enhanced fragmentation mechanism, etc.) then it can be designed to support
> safe fragmentation.

That's basically what I said too.

> The fact that the payload is also IP packets which
> happen to be tagged DF, becomes irrelevant because they are not participating in
> the fragmentation itself.  They are just opaque payload data.  (Note that the
> tunnel should use it's own IPID space, not copied from the payload.)

That's true for the inner packet header, not the outer. The outer
defines how the tunnel works, and that's where fragmentation beyond the
tunnel head-end is problematic.

> There is not an easy way to detect if any particular combination of tunnel and
> endpoint features are safe, except to test if it fails with IPID=0.
> Unfortunately there are too many false fails to ship products in this
> configuration.

The issue of head-end fragmentation is independent from IPID=0; others
noted that this can be used for duplicate deletion in routers, so
flagging all your packets with the same ID is a good way to trigger
something (router, host) into thinking duplication is going on.

> One of the things I have musing about is writing a super jumbo tunnel protocol
> that would use its own fragmentation to put 64k IP jumbograms into 1500 byte
> IP packets with FEC (and without using IP fragmentation).   Think of the
> implications....

You'd have to fragment the jumbogram to do this, right?

Joe

_______________________________________________
Int-area mailing list
Int-area@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/int-area