Re: [TERNLI] Forwarding corrupt packets

Gorry Fairhurst <> Mon, 04 September 2006 13:40 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1GKEgF-00031J-5M; Mon, 04 Sep 2006 09:40:03 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1GKEgD-00031D-Rc for; Mon, 04 Sep 2006 09:40:01 -0400
Received: from [2001:630:241:204:203:baff:fe9a:8c9b] ( by with esmtp (Exim 4.43) id 1GKEgD-0003mC-8e for; Mon, 04 Sep 2006 09:40:01 -0400
Received: from [] ( []) by (8.13.4/8.13.4) with ESMTP id k84Ddpw3021472; Mon, 4 Sep 2006 14:39:52 +0100 (BST)
Message-ID: <>
Date: Mon, 04 Sep 2006 14:39:51 +0100
From: Gorry Fairhurst <>
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 <>
Subject: Re: [TERNLI] Forwarding corrupt packets
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-ERG-MailScanner: Found to be clean
X-Spam-Status: No
X-Spam-Score: -2.8 (--)
X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede
Cc:, Joe Touch <touch@ISI.EDU>
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport-Enhancing Refinements to the Network Layer Interface <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

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 

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