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)
- [TERNLI] Forwarding corrupt packets Michael Welzl
- Re: [TERNLI] Forwarding corrupt packets Joe Touch
- Re: [TERNLI] Forwarding corrupt packets Michael Welzl
- Re: [TERNLI] Forwarding corrupt packets Joe Touch
- Re: [TERNLI] Forwarding corrupt packets alessandro salvatori
- Re: [TERNLI] Forwarding corrupt packets Michael Welzl
- Re: [TERNLI] Forwarding corrupt packets Joe Touch
- Re: [TERNLI] Forwarding corrupt packets Michael Welzl
- Re: [TERNLI] Forwarding corrupt packets Gorry Fairhurst
- Re: [TERNLI] Forwarding corrupt packets Michael Tuexen
- Re: [TERNLI] Forwarding corrupt packets Michael Welzl
- Re: [TERNLI] Forwarding corrupt packets Gorry Fairhurst
- Re: [TERNLI] Forwarding corrupt packets Gorry Fairhurst
- Re: [TERNLI] Forwarding corrupt packets Michael Tuexen
- Re: [TERNLI] Forwarding corrupt packets Gorry Fairhurst
- Re: [TERNLI] Forwarding corrupt packets Michael Tuexen
- Re: [TERNLI] Forwarding corrupt packets Joe Touch
- Re: [TERNLI] Forwarding corrupt packets Michael Welzl
- Re: [TERNLI] Forwarding corrupt packets Michael Welzl
- Re: [TERNLI] Forwarding corrupt packets Gorry Fairhurst
- Re: [TERNLI] Forwarding corrupt packets Michael Tuexen
- Re: [TERNLI] Forwarding corrupt packets Gorry Fairhurst
- Re: [TERNLI] Forwarding corrupt packets Michael Tuexen
- Re: [TERNLI] Forwarding corrupt packets Joe Touch
- Re: [TERNLI] Forwarding corrupt packets Michael Tuexen
- Re: [TERNLI] Forwarding corrupt packets Joe Touch
- Re: [TERNLI] Forwarding corrupt packets Michael Tuexen
- Re: [TERNLI] Forwarding corrupt packets Michael Welzl
- Re: [TERNLI] Forwarding corrupt packets Randall Stewart
- Re: [TERNLI] Forwarding corrupt packets Randall Stewart
- Re: [TERNLI] Forwarding corrupt packets Gorry Fairhurst
- Re: [TERNLI] Forwarding corrupt packets Gorry Fairhurst