Re: [TERNLI] Forwarding corrupt packets
Gorry Fairhurst <gorry@erg.abdn.ac.uk> Mon, 04 September 2006 20:01 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKKdN-0002HR-AF; Mon, 04 Sep 2006 16:01:29 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKKdL-0002G9-Uk for ternli@ietf.org; Mon, 04 Sep 2006 16:01:27 -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 1GKKdL-000632-D5 for ternli@ietf.org; Mon, 04 Sep 2006 16:01:27 -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 k84K1Jug018432; Mon, 4 Sep 2006 21:01:19 +0100 (BST)
Message-ID: <44FC860F.9090008@erg.abdn.ac.uk>
Date: Mon, 04 Sep 2006 21:01:19 +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> <44FC2CA7.90602@erg.abdn.ac.uk> <57784F3E-B93A-4D49-AEBA-F1124D952302@lurchi.franken.de>
In-Reply-To: <57784F3E-B93A-4D49-AEBA-F1124D952302@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: a92270ba83d7ead10c5001bb42ec3221
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, > > 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 >>>>> 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> >>>> >>>> >>>> >> >> > >
- [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