Re: [TERNLI] Forwarding corrupt packets

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Mon, 04 September 2006 13:38 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKEeJ-0002FN-C7; Mon, 04 Sep 2006 09:38:03 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKEe7-0001tM-Aa for ternli@ietf.org; Mon, 04 Sep 2006 09:37:51 -0400
Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKERw-00017w-53 for ternli@ietf.org; Mon, 04 Sep 2006 09:25:17 -0400
Received: from [192.168.1.100] (p508FDF82.dip.t-dialin.net [80.143.223.130]) by ilsa.franken.de (Postfix) with ESMTP id 7AB5B245CA; Mon, 4 Sep 2006 15:25:14 +0200 (CEST) (KNF account authenticated via SMTP-AUTH)
In-Reply-To: <44FC2484.50201@erg.abdn.ac.uk>
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>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <EE4E54BA-BCEB-4DD7-86AB-B2A44A24ACD0@lurchi.franken.de>
Content-Transfer-Encoding: 7bit
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
Subject: Re: [TERNLI] Forwarding corrupt packets
Date: Mon, 4 Sep 2006 15:25:12 +0200
To: gorry@erg.abdn.ac.uk
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
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 Gorry,

see my comments in-line.

Best regards
Michael

On Sep 4, 2006, at 3:05 PM, Gorry Fairhurst wrote:

> So, I had missed this being discussed (sorry).
>
> I'm quite confused about several things:
>
> * In Section 3 it says:
>    The SCTP endpoint can inform its peer that it has received an SCTP
>    packet, but the CRC-32 was wrong.
>
> I presume though that the receiver can somehow verfy that the  
> original packet has been sent with a particular IP source, and  
> protocol. How?
We try to lookup the association based on the IP addresses, port  
numbers and verification tag.
If this is successful, we assume that the error is in the payload,  
but we still know the
peer. So we send back the PKTDRP report.
If the lookup of the association is not successful (because the error  
is in the port numbers
or verification tag (8 bytes) then we simply drop the packet.
>
> I'm curious also here how you know some details
>
> * 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), the
port numbers and the verification tag must match before we take any  
action.
>
> * How do you verify this isn't a third-party DoS attack, because  
> presumably you can't rely on sequence numbers, ports, etc to help you?
The verification tag must match... But I do not see a point here.  
Someone sending us a packet
such that we send a PKTDRP report to the victim could just send the  
PKTDRP report to the victim
using our address as the source. So I think security is not a problem  
here.
>
> * I think I could have missed it, but what is the mechanism by  
> which an IP packet passes through the node and receives a treatment  
> that leaves it with a corrupted CRC-32 at the transport layer, but  
> some (reliable) understanding of the content (IP addresses, length,  
> protocol, etc).
I saw a buggy switch which corrupted always some bytes in the SCTP  
payload. Therefore the IP header
checksum was correct, the Ethernet CRC was correct, because the  
switch computed it correclty,
only the SCTP checksum was wrong.
>
> * If you return a message from a mid-box, how do you know that  
> routers down-stream of the mid-box would have forwared this packet?
I'm not sure what you are asking about here... Routers do not look at  
the SCTP checksum, so why
would they care? The wrong checksum indication will come from an end- 
point most likely.
>
> Gorry
>
>
> Michael Tuexen wrote:
>> Dear all,
>> for SCTP there is an ID
>> http://www.ietf.org/internet-drafts/draft-stewart-sctp- 
>> pktdrprep-05.txt
>> which sends back a packet to the sender if the receiver detects a   
>> transport
>> layer checksum failure...
>> Best regards
>> Michael
>> On Sep 4, 2006, at 9:59 AM, Michael Welzl wrote:
>>>> The question is the impact of the bad packet.
>>
> <Snip>
>
>
>