Re: [TERNLI] Forwarding corrupt packets

Joe Touch <touch@ISI.EDU> Fri, 01 September 2006 15:00 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1GJAVF-00012j-EP; Fri, 01 Sep 2006 11:00:17 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1GJAVE-00012e-4Q for; Fri, 01 Sep 2006 11:00:16 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1GJAVC-0001Em-Nm for; Fri, 01 Sep 2006 11:00:16 -0400
Received: from [] ( []) by (8.13.8/8.13.6) with ESMTP id k81ExZC1018806; Fri, 1 Sep 2006 07:59:35 -0700 (PDT)
Message-ID: <>
Date: Fri, 01 Sep 2006 07:59:33 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20060719)
MIME-Version: 1.0
To: Michael Welzl <>
Subject: Re: [TERNLI] Forwarding corrupt packets
References: <> <> <>
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5A77A380F9D033429D66314C"
X-ISI-4-43-8-MailScanner: Found to be clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport-Enhancing Refinements to the Network Layer Interface <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

Michael Welzl wrote:
>> The only reason the network would think a packet is corrupt:
>> 1) bad net checksum (e.g., IPv4)
> I agree that, if this checksum is known to be corrupt, the
> packet should be dropped.
>> 2) bad link checksum
> which normally covers everything, e.g. in 802.11 nets AFAIK.
> So that's the one that I'm concerned about.
>> In both cases, the destination address is not trusted anymore, so you're
>> potentially sending the corrupt packet to the wrong _place_. If you
>> can't send it the right place, then why are you sending it?
> i remember you saying some time ago that sending it to the
> wrong destination isn't a big problem for the network, and
> therefore the lack of a checksum in ipv6 isn't a big issue.

*ONLY* because there is a link checksum that is *checked*.

> chances are that it would reach the right place, so where's
> the problem?

Why do you believe that? With multiaccess networking regaining dominance
(802.11, CDMA, etc.), a bad link checksum means the packet header may be
corrupted (as well as the data). In those cases, the *link* MUST NOT
forward the packet; it doesn't know where to forward it.

>> This isn't a new issue; it's one of the reasons for the partial checksum
>> in lite/DCCP - but also why it should be only over the _data_ portion.
> This is at least the only portion the end node is concerned
> with, so yep - the precise message from the sender would have
> to be "corrupt data portion is okay" (no matter how exactly
> the element in the network would handle this message - e.g. by
> looking at the data portion, which I consider ugly design,

The link/net ought not look at the transport layer. If it does, it's
because it needs to access info at that layer (for app-layer
forwarding). In that case, it's necessary to drop the packet because
forwarding isn't possible.

It's self-correcting - anyone who needs to look at data that's corrupt
ought not do so, period. For any data, anywhere in the network.

> or by always forwarding corrupt data when at least the IP
> checksum is ok, which I'd prefer).

If the header is OK (link, net, or app - based on what kind of
forwarding is happening), then it's OK to forward. If not, then not.

>> In those conditions, you might end up with one e2e-pair causing a
>> separate endpoint to throttle-back thinking its packets are corrupted.
>> That cross-contamination seems like a sufficient reason not to do this.
> I don't get this - could you go into more details?

A sends to B. The packet gets corrupted and goes to C. C throttle's ITS
connections because it got corrupted packets, but it didn't. Or
shouldn't have.

>> IMO, partial transport checksums are useful only where the header
>> checksum is still valid; otherwise, there's no point in interpreting the
>> header at all.
> As I say above, that's an implementation detail in my opinion.

I disagree; this is a fundamental statement about interpreting bits that
are corrupt. It's a mistake to do so. If that impedes forwarding, then
you MUST NOT forward.

> We can make recommendations in either direction - right now,
> I'm just suggesting this explicit message between the transport
> endpoints and the network.

If the network header is corrupt - or even if the transport header is
corrupt - the network doesn't know which endpoints or apps in the
endpoint to inform.

In that case, silence is the appropriate response.