Re: [TERNLI] Forwarding corrupt packets

Randall Stewart <rrs@cisco.com> Tue, 05 September 2006 11:07 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKYmJ-0006sP-6d; Tue, 05 Sep 2006 07:07:39 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKYmH-0006rl-Qy for ternli@ietf.org; Tue, 05 Sep 2006 07:07:37 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKYmE-0008NX-3N for ternli@ietf.org; Tue, 05 Sep 2006 07:07:37 -0400
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 05 Sep 2006 04:06:58 -0700
X-IronPort-AV: i="4.08,212,1154934000"; d="scan'208"; a="317632134:sNHT94621576350"
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k85B6vsQ018868; Tue, 5 Sep 2006 04:06:57 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k85B6uQV022208; Tue, 5 Sep 2006 04:06:57 -0700 (PDT)
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Sep 2006 04:06:56 -0700
Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Sep 2006 04:06:55 -0700
Message-ID: <44FD5A2F.9020601@cisco.com>
Date: Tue, 05 Sep 2006 07:06:23 -0400
From: Randall Stewart <rrs@cisco.com>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060223
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> <44FC2CA7.90602@erg.abdn.ac.uk> <57784F3E-B93A-4D49-AEBA-F1124D952302@lurchi.franken.de> <44FC860F.9090008@erg.abdn.ac.uk> <7B1D0EF8-91DE-4D6A-AE4F-51776BF53F4D@lurchi.franken.de>
In-Reply-To: <7B1D0EF8-91DE-4D6A-AE4F-51776BF53F4D@lurchi.franken.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 05 Sep 2006 11:06:55.0925 (UTC) FILETIME=[664B1650:01C6D0DB]
DKIM-Signature: a=rsa-sha1; q=dns; l=8662; t=1157454417; x=1158318417; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:Randall=20Stewart=20<rrs@cisco.com> |Subject:Re=3A=20[TERNLI]=20Forwarding=20corrupt=20packets; X=v=3Dcisco.com=3B=20h=3DFhAEj61I/6Kdz9a6+810YG65OJE=3D; b=P0+3lWIqDwaBTSTagYNlsWLWsiUofqFjhOQQGTBgqiTpp7I/AjnI/Gou2qIWJOZixI9y1AMh H3Qku1UZGMOJK4G0Xow6uwPyLWtnYJxHYRgssDcu2PEuhFgrc9ZJFF/F;
Authentication-Results: sj-dkim-1.cisco.com; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6907f330301e69261fa73bed91449a20
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

Michael Tuexen wrote:
> Hi Gorry,
> 
> see my comments in-line.
> 
> Best regards
> Michael
> 
> On Sep 4, 2006, at 10:01 PM, Gorry Fairhurst wrote:
> 
>> 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.
> 
> Agreed. But we do not do this. We take it just as an indication that  
> the packet being reported was corrupted during
> transmission, but made it to the reporting node. So there was no  
> congestion.
> 
>>
>>>>
>>>>>> * 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?
> 
> Here you are talking about the tunnel endpoints. Consider the case  
> where the link has a high
> error rate and the receiving end of the tunnel got the packet, but  
> corrupted. If it knows
> that the corruption is not related to congestion, it can send the  
> report. But *if* the
> tunnel endpoints run an appropriate tunneling protocol with their own  
> acks, even the
> sending side of the tunnel could know that the receiver only got it  
> corrupted.

This is what Cisco's RBSCP does.. its a released feature
offered in most of our routers.. intended for Satellite network
configurations with high loss rates... (not the new K band but
the older C band sat's)

R

> 
>>
>>>>
>>>> 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.
> 
> Yes, it is different from UDP-lite. SCTP never presents payload which  
> was received with checksum errors to the user.
> It is only to speed up the retransmission the get the payload without  
> checksum errors to the receiver.
> 
>>
>>>>>>
>>>>>> 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>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
> 


-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 815-342-5222 (cell)