Re: [TERNLI] Forwarding corrupt packets

Gorry Fairhurst <> Mon, 04 September 2006 20:01 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1GKKdN-0002HR-AF; Mon, 04 Sep 2006 16:01:29 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1GKKdL-0002G9-Uk for; Mon, 04 Sep 2006 16:01:27 -0400
Received: from [2001:630:241:204:203:baff:fe9a:8c9b] ( by with esmtp (Exim 4.43) id 1GKKdL-000632-D5 for; Mon, 04 Sep 2006 16:01:27 -0400
Received: from [] ( []) by (8.13.4/8.13.4) with ESMTP id k84K1Jug018432; Mon, 4 Sep 2006 21:01:19 +0100 (BST)
Message-ID: <>
Date: Mon, 04 Sep 2006 21:01:19 +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: a92270ba83d7ead10c5001bb42ec3221
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,
> comments in-line.
> Best regards
> Michael
> On Sep 4, 2006, at 3:39 PM, Gorry Fairhurst wrote:
>> 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.
> and the addresses and the port numbers. For IPv4 this is 4+4+2+2+4=16  
> bytes that must match.
>>>> 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.
> 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.
Yep, that's what I wanted to see :-)

>>> 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).
> 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.
This is what I thought, but this seems a potentially dangerous signal to 
give, if it can be incorrect. I guess if the signal says I got "X" and 
it was the correct size and has the fields set (as you said), then it is 
safe to re-send X when the congestion window permits, without 
considering this as a congestion loss.

It seems like the danger is only if the sender makes assumptions about 
any other packets that failed to reach their intended destination.

>>>> * 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????
> That is not the intention of the document. The core of the document  is 
> to handle the case where some middleboxes are "tunneling" the traffic 
 > and there is packet loss without
> congestion. This can happen, for example, on satellite links.
> So the purpose of the document is to inform the sender that some  
> packets have been dropped but not due to congestion.
> The support of the checksum error stuff is there because it was very  
> easy to add and it is
> very helpful for finding problem as the one above.
OK - so I guess I still missed how you "know" packets lost on a link (or 
tunnel) would have reached the destination, if only they had not been lost?

>> 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.
> Yes, and if it is from an middle box, it is a special box, which  
> detects this stuff and does
> not forward the corrupted packet, but sends back that notification  
> instead. But normal routers will just forward it...
OK. I think this is a little different to UDP-Lite, in that the 
assuymption in that case, and with DCCP, is that the delivery is doing 
useful work for the end-points. Whereas if you are only using it to 
generate a NACK, then I can see whty you'd rather get the special box to 
fix this.

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