Re: [TERNLI] Forwarding corrupt packets

Michael Welzl <michael.welzl@uibk.ac.at> Mon, 04 September 2006 17:15 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKI2m-0008Dz-QA; Mon, 04 Sep 2006 13:15:32 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKI2l-0008Du-RC for ternli@ietf.org; Mon, 04 Sep 2006 13:15:31 -0400
Received: from gibson.q2s.ntnu.no ([129.241.205.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKI2k-0004LE-CI for ternli@ietf.org; Mon, 04 Sep 2006 13:15:31 -0400
Received: from dhcp103.q2s.ntnu.no (dhcp103.q2s.ntnu.no [129.241.205.103]) by gibson.q2s.ntnu.no (Postfix) with ESMTP id B27702DD329; Mon, 4 Sep 2006 19:15:29 +0200 (CEST)
Subject: Re: [TERNLI] Forwarding corrupt packets
From: Michael Welzl <michael.welzl@uibk.ac.at>
To: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <57784F3E-B93A-4D49-AEBA-F1124D952302@lurchi.franken.de>
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> <85C961BE-2B32-4A31-8235-49CCDCF1332D@lurchi.franken.de> <44FC2484.50201@erg.abdn.ac.uk> <EE4E54BA-BCEB-4DD7-86AB-B2A44A24ACD0@lurchi.franken.de> <44FC2CA7.90602@erg.abdn.ac.uk> <57784F3E-B93A-4D49-AEBA-F1124D952302@lurchi.franken.de>
Content-Type: text/plain
Organization: University of Innsbruck
Message-Id: <1157390125.3291.43.camel@lap10-c703.uibk.ac.at>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4)
Date: 04 Sep 2006 19:15:25 +0200
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: ternli@ietf.org, Joe Touch <touch@ISI.EDU>
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

Hi,

I think that this SCTP proposal is very interesting -
especially because it doesn't use another checksum but
just assumes that everything is right because it's
improbable to hit the right association anyway. I'm
not yet quite sure whether I like or dislike the
idea, though.

I guess I dislike it:

> >>> * How do you find the process to respond to (since ports are not   
> >>> protected by an IP checksum)?
> >> We just try. Please note that the IP addresses (protected by the  
> >> IP  header checksum),
> > Yes for IPv4, but not for IPv6.
> Correct. However, if there is an error in the IP addresses, it is  
> unlikely that the
> 16+16+2+2+4=40 bytes still match an existing association.

unlikely enough? does this enable an attacker to do bad things,
or doesn't it?

I'm thinking of a very recent email by Joe, where he explained
that bad things can happen if a receiver tells a sender to
slow down because the receiver has received a (corrupt) packet
which it should never have received in the fist place. My
argument was that this would never happen - in DCCP as well
as UDP-Lite, the transport header is always checked.

All of a sudden, your proposal seems to change this matter.
In this context, "we just try" just doesn't have a good
sound to it...


> Hmm. What we have in mind is that the sender gets an indication that  
> a packet was not successfully
> received but was not dropped because of congestion in the network. So  
> the sender does not see
> this "packet drop" as a congestion indication.

and how does a sender react? In the discussions for the
DCCP Data Checksum, there was agreement that we don't know
enough about the right sender reaction to corruption yet -
but simply sending at the same rate without reducing it
at all would not be the right thing to do.

This seems to contradict the following part of your draft:

      The DATA
      chunk should be treated just as if it had been marked for fast
      retransmit with the exception that no adjustment should be made to
      the value of cwnd (providing that the receiver can validate a
      portion of the packet as being what was sent).


Cheers,
Michael