Re: [TERNLI] Forwarding corrupt packets

Joe Touch <touch@ISI.EDU> Mon, 04 September 2006 16:02 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKGtv-00081X-Uy; Mon, 04 Sep 2006 12:02:19 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKGtu-0007zo-2v for ternli@ietf.org; Mon, 04 Sep 2006 12:02:18 -0400
Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKGts-0000aJ-NI for ternli@ietf.org; Mon, 04 Sep 2006 12:02:18 -0400
Received: from [192.168.1.42] (pool-71-106-94-15.lsanca.dsl-w.verizon.net [71.106.94.15]) by vapor.isi.edu (8.13.8/8.13.6) with ESMTP id k84G1vGo023429; Mon, 4 Sep 2006 09:01:57 -0700 (PDT)
Message-ID: <44FC4DF4.8090004@isi.edu>
Date: Mon, 04 Sep 2006 09:01:56 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: Michael Welzl <michael.welzl@uibk.ac.at>
Subject: Re: [TERNLI] Forwarding corrupt packets
References: <1157097623.3192.34.camel@lap10-c703.uibk.ac.at> <44F83E74.1080603@isi.edu> <1157121036.3192.148.camel@lap10-c703.uibk.ac.at> <44F84AD5.7070307@isi.edu> <1157131227.3192.220.camel@lap10-c703.uibk.ac.at> <44F8780D.9060503@isi.edu> <1157356740.3197.57.camel@lap10-c703.uibk.ac.at>
In-Reply-To: <1157356740.3197.57.camel@lap10-c703.uibk.ac.at>
X-Enigmail-Version: 0.94.0.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5EAA8E7D0EAE85CFB4290C91"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Cc: ternli@ietf.org
X-BeenThere: ternli@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport-Enhancing Refinements to the Network Layer Interface <ternli.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ternli>, <mailto:ternli-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ternli>
List-Post: <mailto:ternli@ietf.org>
List-Help: <mailto:ternli-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ternli>, <mailto:ternli-request@ietf.org?subject=subscribe>
Errors-To: ternli-bounces@ietf.org


Michael Welzl wrote:
>> The question is the impact of the bad packet.
...
>> If the transport reacts to corrupt packets - as would be the case with
>> UDP-lite and some configs of DCCP - that would be very bad. The
>> difference is whether we're talking about corrupted data and corrupted
>> headers; corrupt data isn't too bad (that's what UDP-lite and DCCP are
>> designed for). Corrupt headers are VERY bad to forward.
> 
> I still don't get it - no matter how you use them, the
> reaction of DCCP and UDP-Lite would always be to silently
> discard a packet if the transport header is wrong, so
> no harm is being done (except for the potential waste of
> bandwidth you mention above, but we agree that this isn't
> substantial).

Bad body, good header: the harm is the bandwidth to the correct
endpoint; the benefit is that this endpoint knows something legitimate,
and the packet serves as its own corruption signal

Bad header: the harm is the signal is sent to the WRONG endpoint.

I reviewed the Feb 2005 discussion on this issue from End2end-interest.

Here's the summary:

- IPv6 does NOT, in RFC2640, require link checksums (as UDP-Lite does).

The relevant text is:

-------------------------------
> Although IPv6 (at 
> least as I recall) omits the IP checksum because of sufficient link 
> checksums to detect corrupted packets, there's no requirement that link 
> layers have such checksums (as hinted in the UDP-Lite RFC) - at least 
> not in 2460 (anyone else know anywhere else a body is buried in this 
> regard?)
-------------------------------

I saw no followup to that question.

- I said that UDP-Lite's requirement of link checksums was an ugly layer
violation. I still think that's the case.

As far as I can tell, UDP-Lite is relaxing a requirement in IPv6 -
allowing partial link checksums rather than full, but I can't locate
that requirement, as per above.

---

I don't have a problem with forwarding the information to the wrong
place; I have a problem with the wrong place acting on it. You're
assuming that the UDP-Lite partial checksum is sufficient to avoid that;
for some reason, the UDP-Lite authors and WG clearly did not.

It'd be useful to review the UDP-lite discussions as to why that text
was required so prominently.

Joe