Re: [TERNLI] Forwarding corrupt packets
Joe Touch <touch@ISI.EDU> Fri, 01 September 2006 15:00 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJAVF-00012j-EP; Fri, 01 Sep 2006 11:00:17 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJAVE-00012e-4Q for ternli@ietf.org; Fri, 01 Sep 2006 11:00:16 -0400
Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJAVC-0001Em-Nm for ternli@ietf.org; Fri, 01 Sep 2006 11:00:16 -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 k81ExZC1018806; Fri, 1 Sep 2006 07:59:35 -0700 (PDT)
Message-ID: <44F84AD5.7070307@isi.edu>
Date: Fri, 01 Sep 2006 07:59:33 -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>
In-Reply-To: <1157121036.3192.148.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="------------enig5A77A380F9D033429D66314C"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7
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 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. Joe
- [TERNLI] Forwarding corrupt packets Michael Welzl
- Re: [TERNLI] Forwarding corrupt packets Joe Touch
- Re: [TERNLI] Forwarding corrupt packets Michael Welzl
- Re: [TERNLI] Forwarding corrupt packets Joe Touch
- Re: [TERNLI] Forwarding corrupt packets alessandro salvatori
- Re: [TERNLI] Forwarding corrupt packets Michael Welzl
- Re: [TERNLI] Forwarding corrupt packets Joe Touch
- Re: [TERNLI] Forwarding corrupt packets Michael Welzl
- Re: [TERNLI] Forwarding corrupt packets Gorry Fairhurst
- Re: [TERNLI] Forwarding corrupt packets Michael Tuexen
- Re: [TERNLI] Forwarding corrupt packets Michael Welzl
- Re: [TERNLI] Forwarding corrupt packets Gorry Fairhurst
- Re: [TERNLI] Forwarding corrupt packets Gorry Fairhurst
- Re: [TERNLI] Forwarding corrupt packets Michael Tuexen
- Re: [TERNLI] Forwarding corrupt packets Gorry Fairhurst
- Re: [TERNLI] Forwarding corrupt packets Michael Tuexen
- Re: [TERNLI] Forwarding corrupt packets Joe Touch
- Re: [TERNLI] Forwarding corrupt packets Michael Welzl
- Re: [TERNLI] Forwarding corrupt packets Michael Welzl
- Re: [TERNLI] Forwarding corrupt packets Gorry Fairhurst
- Re: [TERNLI] Forwarding corrupt packets Michael Tuexen
- Re: [TERNLI] Forwarding corrupt packets Gorry Fairhurst
- Re: [TERNLI] Forwarding corrupt packets Michael Tuexen
- Re: [TERNLI] Forwarding corrupt packets Joe Touch
- Re: [TERNLI] Forwarding corrupt packets Michael Tuexen
- Re: [TERNLI] Forwarding corrupt packets Joe Touch
- Re: [TERNLI] Forwarding corrupt packets Michael Tuexen
- Re: [TERNLI] Forwarding corrupt packets Michael Welzl
- Re: [TERNLI] Forwarding corrupt packets Randall Stewart
- Re: [TERNLI] Forwarding corrupt packets Randall Stewart
- Re: [TERNLI] Forwarding corrupt packets Gorry Fairhurst
- Re: [TERNLI] Forwarding corrupt packets Gorry Fairhurst