Re: [TERNLI] Forwarding corrupt packets

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Mon, 04 September 2006 13:40 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKEgF-00031J-5M; Mon, 04 Sep 2006 09:40:03 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKEgD-00031D-Rc for ternli@ietf.org; Mon, 04 Sep 2006 09:40:01 -0400
Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKEgD-0003mC-8e for ternli@ietf.org; Mon, 04 Sep 2006 09:40:01 -0400
Received: from [139.133.207.155] (dhcp-207-155.erg.abdn.ac.uk [139.133.207.155]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k84Ddpw3021472; Mon, 4 Sep 2006 14:39:52 +0100 (BST)
Message-ID: <44FC2CA7.90602@erg.abdn.ac.uk>
Date: Mon, 04 Sep 2006 14:39:51 +0100
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Organization: University of Aberdeen, UK
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
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> <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>
In-Reply-To: <EE4E54BA-BCEB-4DD7-86AB-B2A44A24ACD0@lurchi.franken.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-ERG-MailScanner: Found to be clean
X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk
X-Spam-Status: No
X-Spam-Score: -2.8 (--)
X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede
Cc: ternli@ietf.org, Joe Touch <touch@ISI.EDU>
X-BeenThere: ternli@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: gorry@erg.abdn.ac.uk
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 Tuexen wrote:

> 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.
> 
OK, so if I think you're saying the verification tag effectively 
provides you with a cookie that identifies the flow.

>>
>> 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), 
Yes for IPv4, but not for IPv6.

> 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.
> 
My worry was more that the "attack" made *that receiver* send an error 
report, that takes capacity on the return route, and then causes the 
corresponding sender to get a valid message (from the receiver) saying 
there are link errors (when there are not), and to somehow ignore other 
losses on the forward route (which may not even go via a link that has 
errors).

>> * 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.
> 
OK, and buggy routers can do this too. However, should we really be 
building IETF documents to work around such bugs????

If that is the main motivation, I think this is ill-founded. Do you have 
other uses in mind?

>>
>> * 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.
> 
If it's from an end-point, that seems to answer my question.
>>
>> 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>
>>
>>
>>
> 
>