Re: [TERNLI] Forwarding corrupt packets

Michael Welzl <michael.welzl@uibk.ac.at> Fri, 01 September 2006 17:20 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJChF-00043T-He; Fri, 01 Sep 2006 13:20:49 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJChE-00043O-RZ for ternli@ietf.org; Fri, 01 Sep 2006 13:20:48 -0400
Received: from gibson.q2s.ntnu.no ([129.241.205.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJChD-0004g1-8y for ternli@ietf.org; Fri, 01 Sep 2006 13:20:48 -0400
Received: from dhcp103.q2s.ntnu.no (dhcp103.q2s.ntnu.no [129.241.205.103]) by gibson.q2s.ntnu.no (Postfix) with ESMTP id 478FE2DD28E; Fri, 1 Sep 2006 19:20:46 +0200 (CEST)
Subject: Re: [TERNLI] Forwarding corrupt packets
From: Michael Welzl <michael.welzl@uibk.ac.at>
To: Joe Touch <touch@ISI.EDU>
In-Reply-To: <44F84AD5.7070307@isi.edu>
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>
Content-Type: text/plain
Organization: University of Innsbruck
Message-Id: <1157131227.3192.220.camel@lap10-c703.uibk.ac.at>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4)
Date: 01 Sep 2006 19:20:28 +0200
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365
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

> > 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.

The same is the case if the IP checksum is wrong.

In a February 2005 discussion on the end2end-interest list, I said:

>> Still, that doesn't make sense to me. What if you transfer an
>> IPv6 packet across a link layer that does *NOT* check your data -
>> why wouldn't this cause harm to the source / destination addresses,
>> and therefore cause wrong router behavior downstream? 

and you answered:

> It doesn't cause harm at the destination, since there's supposed
> to be a transport checksum (even for ICMP - one was added). I
> suppose there's no perceived harm in sending some corrupted
> traffic through the wrong paths.
> 
> Note - this is designed to address corruption, not malicious behavior.

...and that's why I now believe that. You convinced me of it.


> 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.

I'd agree that having it look at the transport layer is not
clean design, but that's what we ended up with in the UDP-Lite RFC:

   For a link that supports
   partial error detection, the Checksum Coverage field in the UDP-Lite
   header MAY be used as a hint of where errors do not need to be
   detected.  Lower layers MUST use a strong error detection mechanism
   [RFC-3819] to detect at least errors that occur in the sensitive part
   of the packet, and discard damaged packets.  The sensitive part
   consists of the octets between the first octet of the IP header and
   the last octet identified by the Checksum Coverage field.  The
   sensitive part would thus be treated in exactly the same way as for a
   UDP packet.


If you're going to do this, it might be better to selectively
enable/disable it.


> > 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.

What you're saying seems to mean that a link layer must not
forward corrupt data unless it has a means to check whether
at least its header is correct. I don't know any link layer
technology that can do this - so you're saying that partial
and separate checksums as in UDP-Lite and DCCP should not
exist, or only be there for the case where you have a link
layer that can restrict its checksum to the link layer header.

Even that might be a nice feature for a new link layer
technology in my opinion, but in any case you're
contradicting existing language in the UDP-Lite and
DCCP RFCs, where it is assumed that link layers can
in fact forward corrupt data.

In any case, it seems to me that we're again debating an
implementation detail here - partial and separate checksums
are there, so it is assumed that there are (or will be)
link layers which forward some corrupt packets for one
way or another. Based on this assumption, wouldn't this
explicit message make sense?


> >> 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.

Let's pick DCCP as an example protocol. If C throttles its
connection because of corruption, it means that the Data
Checksum option is in place - which will detect a failure
in the header and therefore drop the packet. This feature
("option" - one has to be careful what one calls a feature
in DCCP) is there to prevent exactly this type of problem
from occurring.


> >> 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.

Again, you seem to contradict your original statement from 2005.
If you changed your mind, why?


> > 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.

Same point again.


Cheers,
Michael