Re: [TERNLI] Forwarding corrupt packets
Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Mon, 04 September 2006 20:32 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKL7I-0005MB-53; Mon, 04 Sep 2006 16:32:24 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKL7G-0005M4-Pf for ternli@ietf.org; Mon, 04 Sep 2006 16:32:22 -0400
Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKL7G-0004E5-6i for ternli@ietf.org; Mon, 04 Sep 2006 16:32:22 -0400
Received: from [192.168.1.50] (p508FCA94.dip.t-dialin.net [80.143.202.148]) by ilsa.franken.de (Postfix) with ESMTP id 7695A245C3; Mon, 4 Sep 2006 22:32:17 +0200 (CEST) (KNF account authenticated via SMTP-AUTH)
In-Reply-To: <44FC860F.9090008@erg.abdn.ac.uk>
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>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <7B1D0EF8-91DE-4D6A-AE4F-51776BF53F4D@lurchi.franken.de>
Content-Transfer-Encoding: 7bit
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
Subject: Re: [TERNLI] Forwarding corrupt packets
Date: Mon, 04 Sep 2006 22:32:15 +0200
To: gorry@erg.abdn.ac.uk, Randall Stewart <rrs@cisco.com>
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186
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
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. > >>> >>> 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> >>>>> >>>>> >>>>> >>> >>> > >
- [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