From ternli-bounces@ietf.org Fri Sep 01 04:00:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ3xF-0004Hp-7s; Fri, 01 Sep 2006 04:00:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ3xD-0004Hk-Mf for ternli@ietf.org; Fri, 01 Sep 2006 04:00:43 -0400 Received: from gibson.q2s.ntnu.no ([129.241.205.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJ3xC-0003Vq-D0 for ternli@ietf.org; Fri, 01 Sep 2006 04:00:43 -0400 Received: from dhcp103.q2s.ntnu.no (dhcp103.q2s.ntnu.no [129.241.205.103]) by gibson.q2s.ntnu.no (Postfix) with ESMTP id 961022DD292 for ; Fri, 1 Sep 2006 10:00:40 +0200 (CEST) From: Michael Welzl To: ternli@ietf.org Content-Type: text/plain Organization: University of Innsbruck Message-Id: <1157097623.3192.34.camel@lap10-c703.uibk.ac.at> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 01 Sep 2006 10:00:23 +0200 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [TERNLI] Forwarding corrupt packets X-BeenThere: ternli@ietf.org 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: , Errors-To: ternli-bounces@ietf.org Hi all, Here's an idea for a potentially useful message that could be exchanged between end systems and the inner network: >From transport end point to network: "Corruption Acceptable (CA)" (meaning that it would be preferrable to forward packets that are corrupt rather than drop them) >From network to transport end point: "Corruption Forwarding supported (CF)" Purpose: help the end system decide whether to use UDP-Lite, or partial checksums in DCCP, or the Data Checksum option in DCCP. These functions don't yield a benefit if a network element drops all corrupt packets anyway. A CF message could indicate that they would yield a benefit. A CA message could increase the chance of seeing a benefit. What do you say? Cheers, Michael From ternli-bounces@ietf.org Fri Sep 01 10:07:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ9fu-0007bo-CL; Fri, 01 Sep 2006 10:07:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ9fu-0007bj-4s for ternli@ietf.org; Fri, 01 Sep 2006 10:07:14 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJ9fs-0006x3-Q6 for ternli@ietf.org; Fri, 01 Sep 2006 10:07:14 -0400 Received: from [192.168.1.42] (pool-71-106-94-15.lsanca.dsl-w.verizon.net [71.106.94.15]) by vapor.isi.edu (8.13.8/8.13.6) with ESMTP id k81E6puO008530; Fri, 1 Sep 2006 07:06:51 -0700 (PDT) Message-ID: <44F83E74.1080603@isi.edu> Date: Fri, 01 Sep 2006 07:06:44 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Michael Welzl Subject: Re: [TERNLI] Forwarding corrupt packets References: <1157097623.3192.34.camel@lap10-c703.uibk.ac.at> In-Reply-To: <1157097623.3192.34.camel@lap10-c703.uibk.ac.at> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7BDC9AB1A9789789F26B9258" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: ternli@ietf.org X-BeenThere: ternli@ietf.org 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: , Errors-To: ternli-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7BDC9AB1A9789789F26B9258 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Michael Welzl wrote: > Hi all, >=20 > Here's an idea for a potentially useful message that > could be exchanged between end systems and the inner > network: >=20 >>From transport end point to network: > "Corruption Acceptable (CA)" (meaning that it would be > preferrable to forward packets that are corrupt rather > than drop them) >=20 >>From network to transport end point: "Corruption > Forwarding supported (CF)" >=20 > Purpose: help the end system decide whether to use > UDP-Lite, or partial checksums in DCCP, or the > Data Checksum option in DCCP. Why does the _network_ need to know about these? The network doesn't check (or shouldn't check) transport checksums. The only reason the network would think a packet is corrupt: 1) bad net checksum (e.g., IPv4) 2) bad link checksum In both cases, the destination address is not trusted anymore, so you're potentially sending the corrupt packet to the wrong _place_. If you can't send it the right place, then why are you sending it? This isn't a new issue; it's one of the reasons for the partial checksum in lite/DCCP - but also why it should be only over the _data_ portion. In those conditions, you might end up with one e2e-pair causing a separate endpoint to throttle-back thinking its packets are corrupted. That cross-contamination seems like a sufficient reason not to do this. IMO, partial transport checksums are useful only where the header checksum is still valid; otherwise, there's no point in interpreting the header at all. Joe --------------enig7BDC9AB1A9789789F26B9258 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE+D55E5f5cImnZrsRAibaAKDALme2dSlXBtamVvJoVeTfRxMXpgCfZab+ 5JLGAAu/9Mxc6qHwXhShDKA= =XDel -----END PGP SIGNATURE----- --------------enig7BDC9AB1A9789789F26B9258-- From ternli-bounces@ietf.org Fri Sep 01 10:31:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJA2s-0007lW-8z; Fri, 01 Sep 2006 10:30:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJA2r-0007lJ-3M for ternli@ietf.org; Fri, 01 Sep 2006 10:30:57 -0400 Received: from gibson.q2s.ntnu.no ([129.241.205.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJA2p-0008CN-Eh for ternli@ietf.org; Fri, 01 Sep 2006 10:30:56 -0400 Received: from dhcp103.q2s.ntnu.no (dhcp103.q2s.ntnu.no [129.241.205.103]) by gibson.q2s.ntnu.no (Postfix) with ESMTP id 74D192DD292; Fri, 1 Sep 2006 16:30:54 +0200 (CEST) Subject: Re: [TERNLI] Forwarding corrupt packets From: Michael Welzl To: Joe Touch In-Reply-To: <44F83E74.1080603@isi.edu> References: <1157097623.3192.34.camel@lap10-c703.uibk.ac.at> <44F83E74.1080603@isi.edu> Content-Type: text/plain Organization: University of Innsbruck Message-Id: <1157121036.3192.148.camel@lap10-c703.uibk.ac.at> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 01 Sep 2006 16:30:36 +0200 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: ternli@ietf.org X-BeenThere: ternli@ietf.org 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: , Errors-To: ternli-bounces@ietf.org On Fri, 2006-09-01 at 16:06, Joe Touch wrote: > Michael Welzl wrote: > > Hi all, > > > > Here's an idea for a potentially useful message that > > could be exchanged between end systems and the inner > > network: > > > >>From transport end point to network: > > "Corruption Acceptable (CA)" (meaning that it would be > > preferrable to forward packets that are corrupt rather > > than drop them) > > > >>From network to transport end point: "Corruption > > Forwarding supported (CF)" > > > > Purpose: help the end system decide whether to use > > UDP-Lite, or partial checksums in DCCP, or the > > Data Checksum option in DCCP. > > Why does the _network_ need to know about these? The network doesn't > check (or shouldn't check) transport checksums. > > The only reason the network would think a packet is corrupt: > > 1) bad net checksum (e.g., IPv4) I agree that, if this checksum is known to be corrupt, the packet should be dropped. > 2) bad link checksum which normally covers everything, e.g. in 802.11 nets AFAIK. So that's the one that I'm concerned about. > In both cases, the destination address is not trusted anymore, so you're > potentially sending the corrupt packet to the wrong _place_. If you > can't send it the right place, then why are you sending it? i remember you saying some time ago that sending it to the wrong destination isn't a big problem for the network, and therefore the lack of a checksum in ipv6 isn't a big issue. chances are that it would reach the right place, so where's the problem? > This isn't a new issue; it's one of the reasons for the partial checksum > in lite/DCCP - but also why it should be only over the _data_ portion. This is at least the only portion the end node is concerned with, so yep - the precise message from the sender would have to be "corrupt data portion is okay" (no matter how exactly the element in the network would handle this message - e.g. by looking at the data portion, which I consider ugly design, or by always forwarding corrupt data when at least the IP checksum is ok, which I'd prefer). > In those conditions, you might end up with one e2e-pair causing a > separate endpoint to throttle-back thinking its packets are corrupted. > That cross-contamination seems like a sufficient reason not to do this. I don't get this - could you go into more details? > IMO, partial transport checksums are useful only where the header > checksum is still valid; otherwise, there's no point in interpreting the > header at all. As I say above, that's an implementation detail in my opinion. We can make recommendations in either direction - right now, I'm just suggesting this explicit message between the transport endpoints and the network. Cheers, Michael From ternli-bounces@ietf.org Fri Sep 01 11:00:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJAVF-00012j-EP; Fri, 01 Sep 2006 11:00:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJAVE-00012e-4Q for ternli@ietf.org; Fri, 01 Sep 2006 11:00:16 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJAVC-0001Em-Nm for ternli@ietf.org; Fri, 01 Sep 2006 11:00:16 -0400 Received: from [192.168.1.42] (pool-71-106-94-15.lsanca.dsl-w.verizon.net [71.106.94.15]) by vapor.isi.edu (8.13.8/8.13.6) with ESMTP id k81ExZC1018806; Fri, 1 Sep 2006 07:59:35 -0700 (PDT) Message-ID: <44F84AD5.7070307@isi.edu> Date: Fri, 01 Sep 2006 07:59:33 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Michael Welzl 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> In-Reply-To: <1157121036.3192.148.camel@lap10-c703.uibk.ac.at> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5A77A380F9D033429D66314C" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: ternli@ietf.org X-BeenThere: ternli@ietf.org 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: , Errors-To: ternli-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5A77A380F9D033429D66314C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Michael Welzl wrote: =2E.. >> The only reason the network would think a packet is corrupt: >> >> 1) bad net checksum (e.g., IPv4) >=20 > I agree that, if this checksum is known to be corrupt, the > packet should be dropped. >=20 >> 2) bad link checksum >=20 > which normally covers everything, e.g. in 802.11 nets AFAIK. > So that's the one that I'm concerned about. >=20 >> In both cases, the destination address is not trusted anymore, so you'= re >> potentially sending the corrupt packet to the wrong _place_. If you >> can't send it the right place, then why are you sending it? >=20 > i remember you saying some time ago that sending it to the > wrong destination isn't a big problem for the network, and > therefore the lack of a checksum in ipv6 isn't a big issue. *ONLY* because there is a link checksum that is *checked*. > chances are that it would reach the right place, so where's > the problem? Why do you believe that? With multiaccess networking regaining dominance (802.11, CDMA, etc.), a bad link checksum means the packet header may be corrupted (as well as the data). In those cases, the *link* MUST NOT forward the packet; it doesn't know where to forward it. >> This isn't a new issue; it's one of the reasons for the partial checks= um >> in lite/DCCP - but also why it should be only over the _data_ portion.= >=20 > This is at least the only portion the end node is concerned > with, so yep - the precise message from the sender would have > to be "corrupt data portion is okay" (no matter how exactly > the element in the network would handle this message - e.g. by > looking at the data portion, which I consider ugly design, The link/net ought not look at the transport layer. If it does, it's because it needs to access info at that layer (for app-layer forwarding). In that case, it's necessary to drop the packet because forwarding isn't possible. It's self-correcting - anyone who needs to look at data that's corrupt ought not do so, period. For any data, anywhere in the network. > or by always forwarding corrupt data when at least the IP > checksum is ok, which I'd prefer). If the header is OK (link, net, or app - based on what kind of forwarding is happening), then it's OK to forward. If not, then not. >> In those conditions, you might end up with one e2e-pair causing a >> separate endpoint to throttle-back thinking its packets are corrupted.= >> That cross-contamination seems like a sufficient reason not to do this= =2E >=20 > I don't get this - could you go into more details? A sends to B. The packet gets corrupted and goes to C. C throttle's ITS connections because it got corrupted packets, but it didn't. Or shouldn't have. >> IMO, partial transport checksums are useful only where the header >> checksum is still valid; otherwise, there's no point in interpreting t= he >> header at all. >=20 > As I say above, that's an implementation detail in my opinion. I disagree; this is a fundamental statement about interpreting bits that are corrupt. It's a mistake to do so. If that impedes forwarding, then you MUST NOT forward. > We can make recommendations in either direction - right now, > I'm just suggesting this explicit message between the transport > endpoints and the network. If the network header is corrupt - or even if the transport header is corrupt - the network doesn't know which endpoints or apps in the endpoint to inform. In that case, silence is the appropriate response. Joe --------------enig5A77A380F9D033429D66314C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE+ErVE5f5cImnZrsRAo0nAJ9lTgjPKnPRdkhRtf9AG7x8SuFgPQCghoYv xw5+ieBD8DGlrmx5pRPYNPQ= =LqIU -----END PGP SIGNATURE----- --------------enig5A77A380F9D033429D66314C-- From ternli-bounces@ietf.org Fri Sep 01 12:27:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJBrJ-0005cY-5O; Fri, 01 Sep 2006 12:27:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJBrH-0005cT-KB for ternli@ietf.org; Fri, 01 Sep 2006 12:27:07 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJAQD-0000y3-JO for ternli@ietf.org; Fri, 01 Sep 2006 10:55:05 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GJAAw-0003eq-IY for ternli@ietf.org; Fri, 01 Sep 2006 10:39:20 -0400 Received: by ug-out-1314.google.com with SMTP id m2so998840uge for ; Fri, 01 Sep 2006 07:39:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mKkvp1SXCfuWEF1Nsi2FVLW5Y49GDtYccD5LG1hbukjFpT6qXq7nL5XSiSoPBLtMxqquyCQeWjgkhKzbRcya/j1ci3C7PPN+p7Ite3wuQki4uEjUmmmGgMdhKMi0kH/sy0mTOV7NsGuFZ3+ODst+ApZkok7UUdjW+j2D4x8RTQ8= Received: by 10.66.240.12 with SMTP id n12mr1233030ugh; Fri, 01 Sep 2006 07:39:17 -0700 (PDT) Received: by 10.66.232.1 with HTTP; Fri, 1 Sep 2006 07:39:16 -0700 (PDT) Message-ID: <517e86fb0609010739w1a9c8c38wcf19159818e35f0@mail.gmail.com> Date: Fri, 1 Sep 2006 14:39:16 +0000 From: "alessandro salvatori" To: "Michael Welzl" Subject: Re: [TERNLI] Forwarding corrupt packets In-Reply-To: <1157121036.3192.148.camel@lap10-c703.uibk.ac.at> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1157097623.3192.34.camel@lap10-c703.uibk.ac.at> <44F83E74.1080603@isi.edu> <1157121036.3192.148.camel@lap10-c703.uibk.ac.at> X-Spam-Score: -2.5 (--) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ternli@ietf.org X-BeenThere: ternli@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sandr8@gmail.com List-Id: Transport-Enhancing Refinements to the Network Layer Interface List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ternli-bounces@ietf.org On 01 Sep 2006 16:30:36 +0200, Michael Welzl wrote: > > In both cases, the destination address is not trusted anymore, so you're > > potentially sending the corrupt packet to the wrong _place_. If you > > can't send it the right place, then why are you sending it? > > i remember you saying some time ago that sending it to the > wrong destination isn't a big problem for the network, and > therefore the lack of a checksum in ipv6 isn't a big issue. > > chances are that it would reach the right place, so where's > the problem? Well, let me be the devil's lawyer... Can you trust the TTL field to be monotonically decreased if frames get corrupted? You can not, and packets would be able to be forwarded forever. Well, they wouldn't if they eventually reached their destination, but remember the fact that you might forward packets with a varying destination address, and you wouldn't even need to have route loops to keep trying to route to a "moving" target... -- Alessandro Salvatori From ternli-bounces@ietf.org Fri Sep 01 13:20:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJChF-00043T-He; Fri, 01 Sep 2006 13:20:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJChE-00043O-RZ for ternli@ietf.org; Fri, 01 Sep 2006 13:20:48 -0400 Received: from gibson.q2s.ntnu.no ([129.241.205.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJChD-0004g1-8y for ternli@ietf.org; Fri, 01 Sep 2006 13:20:48 -0400 Received: from dhcp103.q2s.ntnu.no (dhcp103.q2s.ntnu.no [129.241.205.103]) by gibson.q2s.ntnu.no (Postfix) with ESMTP id 478FE2DD28E; Fri, 1 Sep 2006 19:20:46 +0200 (CEST) Subject: Re: [TERNLI] Forwarding corrupt packets From: Michael Welzl To: Joe Touch In-Reply-To: <44F84AD5.7070307@isi.edu> 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> Content-Type: text/plain Organization: University of Innsbruck Message-Id: <1157131227.3192.220.camel@lap10-c703.uibk.ac.at> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 01 Sep 2006 19:20:28 +0200 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: ternli@ietf.org X-BeenThere: ternli@ietf.org 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: , Errors-To: ternli-bounces@ietf.org > > chances are that it would reach the right place, so where's > > the problem? > > Why do you believe that? With multiaccess networking regaining dominance > (802.11, CDMA, etc.), a bad link checksum means the packet header may be > corrupted (as well as the data). In those cases, the *link* MUST NOT > forward the packet; it doesn't know where to forward it. The same is the case if the IP checksum is wrong. In a February 2005 discussion on the end2end-interest list, I said: >> Still, that doesn't make sense to me. What if you transfer an >> IPv6 packet across a link layer that does *NOT* check your data - >> why wouldn't this cause harm to the source / destination addresses, >> and therefore cause wrong router behavior downstream? and you answered: > It doesn't cause harm at the destination, since there's supposed > to be a transport checksum (even for ICMP - one was added). I > suppose there's no perceived harm in sending some corrupted > traffic through the wrong paths. > > Note - this is designed to address corruption, not malicious behavior. ...and that's why I now believe that. You convinced me of it. > The link/net ought not look at the transport layer. If it does, it's > because it needs to access info at that layer (for app-layer > forwarding). In that case, it's necessary to drop the packet because > forwarding isn't possible. I'd agree that having it look at the transport layer is not clean design, but that's what we ended up with in the UDP-Lite RFC: For a link that supports partial error detection, the Checksum Coverage field in the UDP-Lite header MAY be used as a hint of where errors do not need to be detected. Lower layers MUST use a strong error detection mechanism [RFC-3819] to detect at least errors that occur in the sensitive part of the packet, and discard damaged packets. The sensitive part consists of the octets between the first octet of the IP header and the last octet identified by the Checksum Coverage field. The sensitive part would thus be treated in exactly the same way as for a UDP packet. If you're going to do this, it might be better to selectively enable/disable it. > > or by always forwarding corrupt data when at least the IP > > checksum is ok, which I'd prefer). > > If the header is OK (link, net, or app - based on what kind of > forwarding is happening), then it's OK to forward. If not, then not. What you're saying seems to mean that a link layer must not forward corrupt data unless it has a means to check whether at least its header is correct. I don't know any link layer technology that can do this - so you're saying that partial and separate checksums as in UDP-Lite and DCCP should not exist, or only be there for the case where you have a link layer that can restrict its checksum to the link layer header. Even that might be a nice feature for a new link layer technology in my opinion, but in any case you're contradicting existing language in the UDP-Lite and DCCP RFCs, where it is assumed that link layers can in fact forward corrupt data. In any case, it seems to me that we're again debating an implementation detail here - partial and separate checksums are there, so it is assumed that there are (or will be) link layers which forward some corrupt packets for one way or another. Based on this assumption, wouldn't this explicit message make sense? > >> In those conditions, you might end up with one e2e-pair causing a > >> separate endpoint to throttle-back thinking its packets are corrupted. > >> That cross-contamination seems like a sufficient reason not to do this. > > > > I don't get this - could you go into more details? > > A sends to B. The packet gets corrupted and goes to C. C throttle's ITS > connections because it got corrupted packets, but it didn't. Or > shouldn't have. Let's pick DCCP as an example protocol. If C throttles its connection because of corruption, it means that the Data Checksum option is in place - which will detect a failure in the header and therefore drop the packet. This feature ("option" - one has to be careful what one calls a feature in DCCP) is there to prevent exactly this type of problem from occurring. > >> IMO, partial transport checksums are useful only where the header > >> checksum is still valid; otherwise, there's no point in interpreting the > >> header at all. > > > > As I say above, that's an implementation detail in my opinion. > > I disagree; this is a fundamental statement about interpreting bits that > are corrupt. It's a mistake to do so. If that impedes forwarding, then > you MUST NOT forward. Again, you seem to contradict your original statement from 2005. If you changed your mind, why? > > We can make recommendations in either direction - right now, > > I'm just suggesting this explicit message between the transport > > endpoints and the network. > > If the network header is corrupt - or even if the transport header is > corrupt - the network doesn't know which endpoints or apps in the > endpoint to inform. > > In that case, silence is the appropriate response. Same point again. Cheers, Michael From ternli-bounces@ietf.org Fri Sep 01 14:12:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJDVb-0003ko-7d; Fri, 01 Sep 2006 14:12:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJDVa-0003kj-FK for ternli@ietf.org; Fri, 01 Sep 2006 14:12:50 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJDVZ-0000NY-Vj for ternli@ietf.org; Fri, 01 Sep 2006 14:12:50 -0400 Received: from [128.9.168.63] (bet.isi.edu [128.9.168.63]) by vapor.isi.edu (8.13.8/8.13.6) with ESMTP id k81ICNMn029920; Fri, 1 Sep 2006 11:12:23 -0700 (PDT) Message-ID: <44F8780D.9060503@isi.edu> Date: Fri, 01 Sep 2006 11:12:29 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Michael Welzl 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> In-Reply-To: <1157131227.3192.220.camel@lap10-c703.uibk.ac.at> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigED77F9026B0C4539B5AB3A26" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Cc: ternli@ietf.org X-BeenThere: ternli@ietf.org 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: , Errors-To: ternli-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigED77F9026B0C4539B5AB3A26 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Michael Welzl wrote: >>> chances are that it would reach the right place, so where's >>> the problem? >> Why do you believe that? With multiaccess networking regaining dominan= ce >> (802.11, CDMA, etc.), a bad link checksum means the packet header may = be >> corrupted (as well as the data). In those cases, the *link* MUST NOT >> forward the packet; it doesn't know where to forward it. >=20 > The same is the case if the IP checksum is wrong. Agreed. > In a February 2005 discussion on the end2end-interest list, I said: >=20 >>> Still, that doesn't make sense to me. What if you transfer an >>> IPv6 packet across a link layer that does *NOT* check your data - >>> why wouldn't this cause harm to the source / destination addresses, >>> and therefore cause wrong router behavior downstream?=20 >=20 > and you answered: >=20 >> It doesn't cause harm at the destination, since there's supposed >> to be a transport checksum (even for ICMP - one was added). I >> suppose there's no perceived harm in sending some corrupted >> traffic through the wrong paths. >> >> Note - this is designed to address corruption, not malicious behavior.= >=20 > ...and that's why I now believe that. You convinced me of it. The question is the impact of the bad packet. If the transport checks things and silently discards bad packets, then the only harm is bandwidth, and I figured this wouldn't be substantial (since errors are presumably somewhat random). If the transport reacts to corrupt packets - as would be the case with UDP-lite and some configs of DCCP - that would be very bad. The difference is whether we're talking about corrupted data and corrupted headers; corrupt data isn't too bad (that's what UDP-lite and DCCP are designed for). Corrupt headers are VERY bad to forward. >> The link/net ought not look at the transport layer. If it does, it's >> because it needs to access info at that layer (for app-layer >> forwarding). In that case, it's necessary to drop the packet because >> forwarding isn't possible. >=20 > I'd agree that having it look at the transport layer is not > clean design, but that's what we ended up with in the UDP-Lite RFC: >=20 > For a link that supports > partial error detection, the Checksum Coverage field in the UDP-Lite= > header MAY be used as a hint of where errors do not need to be > detected. Lower layers MUST use a strong error detection mechanism > [RFC-3819] to detect at least errors that occur in the sensitive par= t > of the packet, and discard damaged packets. The sensitive part > consists of the octets between the first octet of the IP header and > the last octet identified by the Checksum Coverage field. The > sensitive part would thus be treated in exactly the same way as for = a > UDP packet. The link isn't looking at the net layer for forwarding here; it's looking only for an optimization to detect errors over a subset of the packet. For UDP-lite, when the link error is detected (above), the checksum coverage field could be wrong, which means that it's inappropriate to use that information to limit link error coverage, and that the packet MUST be discarded (see 'discard' above). > If you're going to do this, it might be better to selectively > enable/disable it. I disagree; once link protection is provided as noted above and the UDP-lite checksum fails, there is NO utility in forwarding the corrupted packet anywhere. So you forward it to the endpoint... to which port? The port is corrupt, so you can't know you're sending it the right place. >>> or by always forwarding corrupt data when at least the IP >>> checksum is ok, which I'd prefer). >> If the header is OK (link, net, or app - based on what kind of >> forwarding is happening), then it's OK to forward. If not, then not. >=20 > What you're saying seems to mean that a link layer must not > forward corrupt data unless it has a means to check whether > at least its header is correct. Yes- that's how I read section 4 of the UDP-lite doc, quoted above, and repeated in specific here: ---- Lower layers MUST use a strong error detection mechanism [RFC-3819] to detect at least errors that occur in the sensitive part of the packet, and discard damaged packets. ---- > I don't know any link layer > technology that can do this - so you're saying that partial > and separate checksums as in UDP-Lite and DCCP should not > exist, or only be there for the case where you have a link > layer that can restrict its checksum to the link layer header. That's exactly how I read section 4 above. > Even that might be a nice feature for a new link layer > technology in my opinion, but in any case you're > contradicting existing language in the UDP-Lite and > DCCP RFCs, where it is assumed that link layers can > in fact forward corrupt data. Yup. Further in sec 4 of the same doc: --- Link layers that do not support partial error detection suitable for UDP-Lite, as described above, MUST detect errors in the entire UDP- Lite packet, and MUST discard damaged packets [RFC-3819]. --- > In any case, it seems to me that we're again debating an > implementation detail here - partial and separate checksums > are there, so it is assumed that there are (or will be) > link layers which forward some corrupt packets for one > way or another. Based on this assumption, wouldn't this > explicit message make sense? No; UDP-lite requires that the packets be discarded. I don't agree that sending a signal about corrupt header info is ever appropriate. >>>> In those conditions, you might end up with one e2e-pair causing a >>>> separate endpoint to throttle-back thinking its packets are corrupte= d. >>>> That cross-contamination seems like a sufficient reason not to do th= is. >>> I don't get this - could you go into more details? >> A sends to B. The packet gets corrupted and goes to C. C throttle's IT= S >> connections because it got corrupted packets, but it didn't. Or >> shouldn't have. >=20 > Let's pick DCCP as an example protocol. If C throttles its > connection because of corruption, it means that the Data > Checksum option is in place - which will detect a failure > in the header and therefore drop the packet. This feature > ("option" - one has to be careful what one calls a feature > in DCCP) is there to prevent exactly this type of problem > from occurring. That assumes: a) partial coverage of the packet by a strong link layer b) correct checksum of the packet at the DCCP-partial layer I.e., IMO, the same requirements as for UDP-lite (I haven't checked DCCP, which is a longer spec, but I'll assume it has similar requirements, or -should- ;-) >>>> IMO, partial transport checksums are useful only where the header >>>> checksum is still valid; otherwise, there's no point in interpreting= the >>>> header at all. >>> As I say above, that's an implementation detail in my opinion. >> I disagree; this is a fundamental statement about interpreting bits th= at >> are corrupt. It's a mistake to do so. If that impedes forwarding, then= >> you MUST NOT forward. >=20 > Again, you seem to contradict your original statement from 2005. > If you changed your mind, why? See above; header vs. data. I've never presumed that forwarding or signalling based on a corrupt header is appropriate. >>> We can make recommendations in either direction - right now, >>> I'm just suggesting this explicit message between the transport >>> endpoints and the network. >> If the network header is corrupt - or even if the transport header is >> corrupt - the network doesn't know which endpoints or apps in the >> endpoint to inform. >> >> In that case, silence is the appropriate response. >=20 > Same point again. Same reply ;-) Joe --------------enigED77F9026B0C4539B5AB3A26 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE+HgNE5f5cImnZrsRApTGAKD43V+shWQtOnZaGMViQ8ReFFd+3wCdHP1y ad4E1d/WndxPQDshoKSzcTk= =0lwX -----END PGP SIGNATURE----- --------------enigED77F9026B0C4539B5AB3A26-- From ternli-bounces@ietf.org Mon Sep 04 03:59:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GK9MQ-0004RO-1h; Mon, 04 Sep 2006 03:59:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GK9MO-0004Pk-0f for ternli@ietf.org; Mon, 04 Sep 2006 03:59:12 -0400 Received: from gibson.q2s.ntnu.no ([129.241.205.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GK9MN-0000xT-E4 for ternli@ietf.org; Mon, 04 Sep 2006 03:59:11 -0400 Received: from dhcp103.q2s.ntnu.no (dhcp103.q2s.ntnu.no [129.241.205.103]) by gibson.q2s.ntnu.no (Postfix) with ESMTP id 66CD52DD342; Mon, 4 Sep 2006 09:59:05 +0200 (CEST) Subject: Re: [TERNLI] Forwarding corrupt packets From: Michael Welzl To: Joe Touch In-Reply-To: <44F8780D.9060503@isi.edu> 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> Content-Type: text/plain Organization: University of Innsbruck Message-Id: <1157356740.3197.57.camel@lap10-c703.uibk.ac.at> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 04 Sep 2006 09:59:01 +0200 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: ternli@ietf.org X-BeenThere: ternli@ietf.org 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: , Errors-To: ternli-bounces@ietf.org > The question is the impact of the bad packet. > > If the transport checks things and silently discards bad packets, then > the only harm is bandwidth, and I figured this wouldn't be substantial > (since errors are presumably somewhat random). Agreed. > If the transport reacts to corrupt packets - as would be the case with > UDP-lite and some configs of DCCP - that would be very bad. The > difference is whether we're talking about corrupted data and corrupted > headers; corrupt data isn't too bad (that's what UDP-lite and DCCP are > designed for). Corrupt headers are VERY bad to forward. I still don't get it - no matter how you use them, the reaction of DCCP and UDP-Lite would always be to silently discard a packet if the transport header is wrong, so no harm is being done (except for the potential waste of bandwidth you mention above, but we agree that this isn't substantial). > >> The link/net ought not look at the transport layer. If it does, it's > >> because it needs to access info at that layer (for app-layer > >> forwarding). In that case, it's necessary to drop the packet because > >> forwarding isn't possible. > > > > I'd agree that having it look at the transport layer is not > > clean design, but that's what we ended up with in the UDP-Lite RFC: > > > > For a link that supports > > partial error detection, the Checksum Coverage field in the UDP-Lite > > header MAY be used as a hint of where errors do not need to be > > detected. Lower layers MUST use a strong error detection mechanism > > [RFC-3819] to detect at least errors that occur in the sensitive part > > of the packet, and discard damaged packets. The sensitive part > > consists of the octets between the first octet of the IP header and > > the last octet identified by the Checksum Coverage field. The > > sensitive part would thus be treated in exactly the same way as for a > > UDP packet. > > The link isn't looking at the net layer for forwarding here; it's > looking only for an optimization to detect errors over a subset of the > packet. > > For UDP-lite, when the link error is detected (above), the checksum > coverage field could be wrong, which means that it's inappropriate to > use that information to limit link error coverage, and that the packet > MUST be discarded (see 'discard' above). I see that this is in the specification, but I question that it would have to be so strict (could also be a SHOULD in my opinion). The reason is that the checksum coverage field is itself covered by UDP-Lite's checksum in any case, so the harm is again just a waste of bandwidth. > > If you're going to do this, it might be better to selectively > > enable/disable it. > > I disagree; once link protection is provided as noted above and the > UDP-lite checksum fails, there is NO utility in forwarding the corrupted > packet anywhere. So you forward it to the endpoint... to which port? The > port is corrupt, so you can't know you're sending it the right place. I agree that UDP-lite detection by links as above eliminates any need for such explicit signaling. I however question that this is clean design - now links should detect UDP-Lite, look at the checksum coverage field, then they should also detect DCCP and forward corrupt data if it makes sense according to the DCCP header. What's next? This is why I'd prefer an explicit message. This being said, there are of course also issues with it - for instance, if the link layer should only do this for the specific flow which requests it, it must again look at the IP header to classify flows. This is probably not much "cleaner" than the scenario I criticize here. Then again, a link could just forward any corrupt data for a while upon reception of such a message, and that single state would have to be refreshed. I'm guessing that you won't like that - such behavior of course requires all the receivers to be able to "survive" the reception of corrupt data. I think that this should be the case anyway, though - that's why we have transport checksums. > > What you're saying seems to mean that a link layer must not > > forward corrupt data unless it has a means to check whether > > at least its header is correct. > > Yes- that's how I read section 4 of the UDP-lite doc, quoted above, and > repeated in specific here: > > ---- > Lower layers MUST use a strong error detection mechanism [RFC-3819] to > detect at least errors that occur in the sensitive part of the packet, > and discard damaged packets. > ---- I say that this is too strict, based on our previous discussion, where you (convincingly) argued that it was okay for a link to forward IPv6 packets with errors. Now you refer to a much stricter specification - so let's use TCP over IPV6 as a reference, not UDP-Lite. > > I don't know any link layer > > technology that can do this - so you're saying that partial > > and separate checksums as in UDP-Lite and DCCP should not > > exist, or only be there for the case where you have a link > > layer that can restrict its checksum to the link layer header. > > That's exactly how I read section 4 above. Hm, right, both the UDP-Lite and DCCP spec are as strict as that about this issue, requiring this (in my opinion ugly) method of communication between the transport and link layers anyway, perhaps making it pointless to add additional explicit communication... > > Even that might be a nice feature for a new link layer > > technology in my opinion, but in any case you're > > contradicting existing language in the UDP-Lite and > > DCCP RFCs, where it is assumed that link layers can > > in fact forward corrupt data. > > Yup. Further in sec 4 of the same doc: > --- > Link layers that do not support partial error detection suitable for > UDP-Lite, as described above, MUST detect errors in the entire UDP- > Lite packet, and MUST discard damaged packets [RFC-3819]. > --- *sigh* ... I just forgot how strict all that text was. I wish it wasn't. > > Let's pick DCCP as an example protocol. If C throttles its > > connection because of corruption, it means that the Data > > Checksum option is in place - which will detect a failure > > in the header and therefore drop the packet. This feature > > ("option" - one has to be careful what one calls a feature > > in DCCP) is there to prevent exactly this type of problem > > from occurring. > > That assumes: > > a) partial coverage of the packet by a strong link > layer > > b) correct checksum of the packet at the DCCP-partial > layer > > I.e., IMO, the same requirements as for UDP-lite (I haven't checked > DCCP, which is a longer spec, but I'll assume it has similar > requirements, or -should- ;-) This would also work without a), and that's exactly why I think that the specifications (indeed, both of them have these statements you quote here) are too strict in this aspect. But that's just the way they are, so I guess there's no point in debating them right now. > > Again, you seem to contradict your original statement from 2005. > > If you changed your mind, why? > > See above; header vs. data. I've never presumed that forwarding or > signalling based on a corrupt header is appropriate. Well yes, you said it's appropriate to forward an IPv6 packet with a broken IPv6 header, or at least that it doesn't cause harm. This type of forwarding just isn't happening for DCCP and UDP-Lite because their specs are so strict about this matter. Cheers, Michael From ternli-bounces@ietf.org Mon Sep 04 07:01:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKCD5-0008CD-61; Mon, 04 Sep 2006 07:01:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKCD3-0008C5-Vj for ternli@ietf.org; Mon, 04 Sep 2006 07:01:45 -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 1GKCD3-0005Tn-CX for ternli@ietf.org; Mon, 04 Sep 2006 07:01:45 -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 k84B1aN6010409; Mon, 4 Sep 2006 12:01:36 +0100 (BST) Message-ID: <44FC0790.6010200@erg.abdn.ac.uk> Date: Mon, 04 Sep 2006 12:01:36 +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 Welzl 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> In-Reply-To: <1157121036.3192.148.camel@lap10-c703.uibk.ac.at> 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: c54bc2f42d02429833c0ca4b8725abd7 Cc: ternli@ietf.org, Joe Touch 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ternli-bounces@ietf.org A) On which link layers support this? Not all link-layers necessarily check all the bytes within a link framer when calculating the frame integrity check (e.g. CRC-16 or CRC-32). A classic example of this is the ISO HDLC frame format, that has long included a frame-type called UIH, which assigns the CRC to cover a pre-agreed minimum number of bytes (perhaps pre-configured, perhaps negotiated using the XID method). Frames with invalid CRCs are discarded, frames with good CRCs are forwarded without judgement on the remaining content. This could be used by a UDP-Lite aware (L4 snooping) link driver to select to choose UIH format in favour of UI frames, when this is compatible with the UDP-Lite coverage value. HDLC Voice links have used this format, and something similar is supported in some of 3GPP specs. BUT DO NOTE, to support this and get strong benefits you have to make the correct PHY decisions, which impacts coding, modulation, synchronisation, etc. - It's not just a matter of ignoring the CRC and hoping for the best. If you don't use a CRC at all, you increase the chance of mis-delivery to others (and the possibility of getting mangled packets). This is particularly bad for IPv6 nodes. The IPv4 checksum is too weak to really give you much confidence under these cases either;-). --- B) On whether this extra signalling is useful? What I don't understand is the "essence" of the message that you need to generate to utilise this, since you seem to suggest in this thread using explicit signalling to set L2 state, rather than per-packet choices. > "From transport end point to network" - I think we already have this as a transport option. - not sure I am convinced we need the signal. - I don't understand this signal... it seems to bind a specific TSpec (IPsrc,IPdst, Transport, srcport,dstport)to a L2 identity... How do you differentiate when a new app replaces the previous one with different semantics? > From network to transport end point:"Corruption Forwarding supported (CF)" - Why do we need to know this at the transport layer? - If your end systems (and any L4 middleboxes!) support UDP-Lite and/or DCCP with partial coverage it is FINE to use this irrespective of whether the links do anyrthing special. you don't gain, but you don't loose either. - Can you clarify how the extra signalling helps? Michael Welzl wrote: > On Fri, 2006-09-01 at 16:06, Joe Touch wrote: > >>Michael Welzl wrote: >> >>>Hi all, >>> >>>Here's an idea for a potentially useful message that >>>could be exchanged between end systems and the inner >>>network: >>> >>>>From transport end point to network: >>>"Corruption Acceptable (CA)" (meaning that it would be >>>preferrable to forward packets that are corrupt rather >>>than drop them) >>> >>>>From network to transport end point: "Corruption >>>Forwarding supported (CF)" >>> >>>Purpose: help the end system decide whether to use >>>UDP-Lite, or partial checksums in DCCP, or the >>>Data Checksum option in DCCP. >> >>Why does the _network_ need to know about these? The network doesn't >>check (or shouldn't check) transport checksums. >> >>The only reason the network would think a packet is corrupt: >> >>1) bad net checksum (e.g., IPv4) > > > I agree that, if this checksum is known to be corrupt, the > packet should be dropped. > > > >>2) bad link checksum > > > which normally covers everything, e.g. in 802.11 nets AFAIK. > So that's the one that I'm concerned about. > > > >>In both cases, the destination address is not trusted anymore, so you're >>potentially sending the corrupt packet to the wrong _place_. If you >>can't send it the right place, then why are you sending it? > > > i remember you saying some time ago that sending it to the > wrong destination isn't a big problem for the network, and > therefore the lack of a checksum in ipv6 isn't a big issue. > > chances are that it would reach the right place, so where's > the problem? > > > >>This isn't a new issue; it's one of the reasons for the partial checksum >>in lite/DCCP - but also why it should be only over the _data_ portion. > > > This is at least the only portion the end node is concerned > with, so yep - the precise message from the sender would have > to be "corrupt data portion is okay" (no matter how exactly > the element in the network would handle this message - e.g. by > looking at the data portion, which I consider ugly design, > or by always forwarding corrupt data when at least the IP > checksum is ok, which I'd prefer). > > > >>In those conditions, you might end up with one e2e-pair causing a >>separate endpoint to throttle-back thinking its packets are corrupted. >>That cross-contamination seems like a sufficient reason not to do this. > > > I don't get this - could you go into more details? > > > >>IMO, partial transport checksums are useful only where the header >>checksum is still valid; otherwise, there's no point in interpreting the >>header at all. > > > As I say above, that's an implementation detail in my opinion. > We can make recommendations in either direction - right now, > I'm just suggesting this explicit message between the transport > endpoints and the network. > > Cheers, > Michael > > > From ternli-bounces@ietf.org Mon Sep 04 07:19:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKCUL-0005EX-Tx; Mon, 04 Sep 2006 07:19:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKCUL-0005EK-4a for ternli@ietf.org; Mon, 04 Sep 2006 07:19:37 -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 1GKCUK-0000MN-Hv for ternli@ietf.org; Mon, 04 Sep 2006 07:19:37 -0400 Received: from [192.168.1.100] (p508FDF82.dip.t-dialin.net [80.143.223.130]) by ilsa.franken.de (Postfix) with ESMTP id 19337245C6; Mon, 4 Sep 2006 13:19:30 +0200 (CEST) (KNF account authenticated via SMTP-AUTH) In-Reply-To: <1157356740.3197.57.camel@lap10-c703.uibk.ac.at> 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> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <85C961BE-2B32-4A31-8235-49CCDCF1332D@lurchi.franken.de> Content-Transfer-Encoding: 7bit From: Michael Tuexen Subject: Re: [TERNLI] Forwarding corrupt packets Date: Mon, 4 Sep 2006 13:19:27 +0200 To: Michael Welzl X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Cc: ternli@ietf.org, Joe Touch X-BeenThere: ternli@ietf.org 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: , Errors-To: ternli-bounces@ietf.org 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. >> >> If the transport checks things and silently discards bad packets, >> then >> the only harm is bandwidth, and I figured this wouldn't be >> substantial >> (since errors are presumably somewhat random). > > Agreed. > > >> If the transport reacts to corrupt packets - as would be the case >> with >> UDP-lite and some configs of DCCP - that would be very bad. The >> difference is whether we're talking about corrupted data and >> corrupted >> headers; corrupt data isn't too bad (that's what UDP-lite and DCCP >> are >> designed for). Corrupt headers are VERY bad to forward. > > I still don't get it - no matter how you use them, the > reaction of DCCP and UDP-Lite would always be to silently > discard a packet if the transport header is wrong, so > no harm is being done (except for the potential waste of > bandwidth you mention above, but we agree that this isn't > substantial). > > >>>> The link/net ought not look at the transport layer. If it does, >>>> it's >>>> because it needs to access info at that layer (for app-layer >>>> forwarding). In that case, it's necessary to drop the packet >>>> because >>>> forwarding isn't possible. >>> >>> I'd agree that having it look at the transport layer is not >>> clean design, but that's what we ended up with in the UDP-Lite RFC: >>> >>> For a link that supports >>> partial error detection, the Checksum Coverage field in the >>> UDP-Lite >>> header MAY be used as a hint of where errors do not need to be >>> detected. Lower layers MUST use a strong error detection >>> mechanism >>> [RFC-3819] to detect at least errors that occur in the >>> sensitive part >>> of the packet, and discard damaged packets. The sensitive part >>> consists of the octets between the first octet of the IP >>> header and >>> the last octet identified by the Checksum Coverage field. The >>> sensitive part would thus be treated in exactly the same way >>> as for a >>> UDP packet. >> >> The link isn't looking at the net layer for forwarding here; it's >> looking only for an optimization to detect errors over a subset of >> the >> packet. >> >> For UDP-lite, when the link error is detected (above), the checksum >> coverage field could be wrong, which means that it's inappropriate to >> use that information to limit link error coverage, and that the >> packet >> MUST be discarded (see 'discard' above). > > I see that this is in the specification, but I question that > it would have to be so strict (could also be a SHOULD in my > opinion). The reason is that the checksum coverage field is > itself covered by UDP-Lite's checksum in any case, so the > harm is again just a waste of bandwidth. > > >>> If you're going to do this, it might be better to selectively >>> enable/disable it. >> >> I disagree; once link protection is provided as noted above and the >> UDP-lite checksum fails, there is NO utility in forwarding the >> corrupted >> packet anywhere. So you forward it to the endpoint... to which >> port? The >> port is corrupt, so you can't know you're sending it the right place. > > I agree that UDP-lite detection by links as above eliminates > any need for such explicit signaling. I however question that > this is clean design - now links should detect UDP-Lite, look > at the checksum coverage field, then they should also detect > DCCP and forward corrupt data if it makes sense according > to the DCCP header. What's next? > > This is why I'd prefer an explicit message. This being said, > there are of course also issues with it - for instance, if > the link layer should only do this for the specific flow > which requests it, it must again look at the IP header to > classify flows. This is probably not much "cleaner" than the > scenario I criticize here. Then again, a link could just > forward any corrupt data for a while upon reception of such > a message, and that single state would have to be refreshed. > > I'm guessing that you won't like that - such behavior > of course requires all the receivers to be able to > "survive" the reception of corrupt data. I think > that this should be the case anyway, though - that's > why we have transport checksums. > > >>> What you're saying seems to mean that a link layer must not >>> forward corrupt data unless it has a means to check whether >>> at least its header is correct. >> >> Yes- that's how I read section 4 of the UDP-lite doc, quoted >> above, and >> repeated in specific here: >> >> ---- >> Lower layers MUST use a strong error detection mechanism >> [RFC-3819] to >> detect at least errors that occur in the sensitive part of the >> packet, >> and discard damaged packets. >> ---- > > I say that this is too strict, based on our previous > discussion, where you (convincingly) argued that it was > okay for a link to forward IPv6 packets with errors. > > Now you refer to a much stricter specification - so let's > use TCP over IPV6 as a reference, not UDP-Lite. > > >>> I don't know any link layer >>> technology that can do this - so you're saying that partial >>> and separate checksums as in UDP-Lite and DCCP should not >>> exist, or only be there for the case where you have a link >>> layer that can restrict its checksum to the link layer header. >> >> That's exactly how I read section 4 above. > > Hm, right, both the UDP-Lite and DCCP spec are as strict > as that about this issue, requiring this (in my opinion > ugly) method of communication between the transport and > link layers anyway, perhaps making it pointless to add > additional explicit communication... > > >>> Even that might be a nice feature for a new link layer >>> technology in my opinion, but in any case you're >>> contradicting existing language in the UDP-Lite and >>> DCCP RFCs, where it is assumed that link layers can >>> in fact forward corrupt data. >> >> Yup. Further in sec 4 of the same doc: >> --- >> Link layers that do not support partial error detection >> suitable for >> UDP-Lite, as described above, MUST detect errors in the entire >> UDP- >> Lite packet, and MUST discard damaged packets [RFC-3819]. >> --- > > *sigh* ... I just forgot how strict all that text was. > I wish it wasn't. > > >>> Let's pick DCCP as an example protocol. If C throttles its >>> connection because of corruption, it means that the Data >>> Checksum option is in place - which will detect a failure >>> in the header and therefore drop the packet. This feature >>> ("option" - one has to be careful what one calls a feature >>> in DCCP) is there to prevent exactly this type of problem >>> from occurring. >> >> That assumes: >> >> a) partial coverage of the packet by a strong link >> layer >> >> b) correct checksum of the packet at the DCCP-partial >> layer >> >> I.e., IMO, the same requirements as for UDP-lite (I haven't checked >> DCCP, which is a longer spec, but I'll assume it has similar >> requirements, or -should- ;-) > > This would also work without a), and that's exactly why > I think that the specifications (indeed, both of them > have these statements you quote here) are too strict in > this aspect. > > But that's just the way they are, so I guess there's > no point in debating them right now. > > >>> Again, you seem to contradict your original statement from 2005. >>> If you changed your mind, why? >> >> See above; header vs. data. I've never presumed that forwarding or >> signalling based on a corrupt header is appropriate. > > Well yes, you said it's appropriate to forward an IPv6 packet > with a broken IPv6 header, or at least that it doesn't cause > harm. This type of forwarding just isn't happening for DCCP > and UDP-Lite because their specs are so strict about this matter. > > Cheers, > Michael > > > From ternli-bounces@ietf.org Mon Sep 04 07:28:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKCd5-00031b-UC; Mon, 04 Sep 2006 07:28:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKCd3-00031W-TH for ternli@ietf.org; Mon, 04 Sep 2006 07:28:37 -0400 Received: from gibson.q2s.ntnu.no ([129.241.205.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKCd2-0001fA-De for ternli@ietf.org; Mon, 04 Sep 2006 07:28:37 -0400 Received: from dhcp103.q2s.ntnu.no (dhcp103.q2s.ntnu.no [129.241.205.103]) by gibson.q2s.ntnu.no (Postfix) with ESMTP id 6C7C22DD329; Mon, 4 Sep 2006 13:28:35 +0200 (CEST) Subject: Re: [TERNLI] Forwarding corrupt packets From: Michael Welzl To: gorry@erg.abdn.ac.uk In-Reply-To: <44FC0790.6010200@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> <44FC0790.6010200@erg.abdn.ac.uk> Content-Type: text/plain Organization: University of Innsbruck Message-Id: <1157369310.3197.140.camel@lap10-c703.uibk.ac.at> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 04 Sep 2006 13:28:30 +0200 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: ternli@ietf.org, Joe Touch X-BeenThere: ternli@ietf.org 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: , Errors-To: ternli-bounces@ietf.org On Mon, 2006-09-04 at 13:01, Gorry Fairhurst wrote: > A) On which link layers support this? Thanks for all the interesting details! > B) On whether this extra signalling is useful? At this point, I should perhaps mention that I'm not making a very concrete proposal here which I try to defend - the way I understood it, TERNLI is still in its defining stage and people are just tossing ideas around. So I thought I'd add an idea and see what the reaction would be - and the reactions are surely interesting, thanks a lot to both of you for the feedback you gave so far! > What I don't understand is the "essence" of the message that you need to > generate to utilise this, since you seem to suggest in this thread using > explicit signalling to set L2 state, rather than per-packet choices. at least in the "From transport end point to network" case, yes. > > > "From transport end point to network" > - I think we already have this as a transport option. > - not sure I am convinced we need the signal. > - I don't understand this signal... it seems to bind a specific TSpec > (IPsrc,IPdst, Transport, srcport,dstport)to a L2 identity... How do you > differentiate when a new app replaces the previous one with different > semantics? When I proposed this, I didn't think of the parts of the UDP-Lite and DCCP specs that Joe pointed me to, which require link layers to detect that forwarding corrupt packets is desired. The "beauty" of this design notwithstanding, that signal is therefore already existent on a per-packet basis, so I would now agree that the message isn't useful anymore in this direction. > > From network to transport end point:"Corruption Forwarding supported > (CF)" > - Why do we need to know this at the transport layer? > - If your end systems (and any L4 middleboxes!) support UDP-Lite and/or > DCCP with partial coverage it is FINE to use this irrespective of > whether the links do anyrthing special. you don't gain, but you don't > loose either. > > - Can you clarify how the extra signalling helps? In DCCP, the data checksum option is extra overhead, but it is useless unless you have a link which delivers known-corrupt data. Here I'd say that it would help. As for UDP-Lite, a reason not to use it is (as with any new protocol) the fact that it might not pass through firewalls. Thus, my application could first use UDP => extra signaling tells me to try UDP-Lite, so I do. Theoretically, it might be preferrable to always try UDP-Lite first, and switch back to UDP in case of failure. But will application programmers do this? I imagine that the outlook of receiving a message which tells an application to use UDP-Lite might be a more convincing argument for application programmers to support the protocol at all. Then again, maybe not - I'm really just guessing here. Cheers, Michael From ternli-bounces@ietf.org Mon Sep 04 09:05:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKE8c-0005QJ-Ic; Mon, 04 Sep 2006 09:05:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKE8b-0005PG-Mo for ternli@ietf.org; Mon, 04 Sep 2006 09:05:17 -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 1GKE8a-00065W-8n for ternli@ietf.org; Mon, 04 Sep 2006 09:05:17 -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 k84D570S018983; Mon, 4 Sep 2006 14:05:07 +0100 (BST) Message-ID: <44FC2484.50201@erg.abdn.ac.uk> Date: Mon, 04 Sep 2006 14:05:08 +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: <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> In-Reply-To: <85C961BE-2B32-4A31-8235-49CCDCF1332D@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: 0ddefe323dd869ab027dbfff7eff0465 Cc: ternli@ietf.org, Joe Touch 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ternli-bounces@ietf.org 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? 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)? * 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? * 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). * 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? 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. > > > From ternli-bounces@ietf.org Mon Sep 04 09:13:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKEGw-00022I-KM; Mon, 04 Sep 2006 09:13:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKEGv-00022D-65 for ternli@ietf.org; Mon, 04 Sep 2006 09:13:53 -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 1GKEGu-0007VY-KW for ternli@ietf.org; Mon, 04 Sep 2006 09:13:53 -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 k84DDgic019477; Mon, 4 Sep 2006 14:13:42 +0100 (BST) Message-ID: <44FC2687.1030302@erg.abdn.ac.uk> Date: Mon, 04 Sep 2006 14:13:43 +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 Welzl 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> <44FC0790.6010200@erg.abdn.ac.uk> <1157369310.3197.140.camel@lap10-c703.uibk.ac.at> In-Reply-To: <1157369310.3197.140.camel@lap10-c703.uibk.ac.at> 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: 944ecb6e61f753561f559a497458fb4f Cc: ternli@ietf.org, Joe Touch 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ternli-bounces@ietf.org I think it was a reasonable strawman, and is a form of cross-layer signalling. I suggest any L2 signalling has to demonstrate it is necessary, safe, etc. Not sure the case for DCCP is much stronger, but would could think on this. My take is that links have to work hard to get UDP-Lite-style L2 processing working effectively. Links that do this can get benefit (if desigend that way). Peeking into the header may also be reasonable for DCCP. Your deployment note at the end on UDP-Lite is a good point. If some signal could help address this issue, this would be a great step towards real deployment, however at the moment, I'm not yet persauded this is the right way to do this. Thanks, Gorry Michael Welzl wrote: > On Mon, 2006-09-04 at 13:01, Gorry Fairhurst wrote: > >>A) On which link layers support this? > > > Thanks for all the interesting details! > > > >>B) On whether this extra signalling is useful? > > > At this point, I should perhaps mention that I'm not > making a very concrete proposal here which I try to > defend - the way I understood it, TERNLI is still in > its defining stage and people are just tossing ideas > around. So I thought I'd add an idea and see what the > reaction would be - and the reactions are surely > interesting, thanks a lot to both of you for the > feedback you gave so far! > > > >>What I don't understand is the "essence" of the message that you need to >>generate to utilise this, since you seem to suggest in this thread using >>explicit signalling to set L2 state, rather than per-packet choices. > > > at least in the "From transport end point to network" case, yes. > > >> > "From transport end point to network" >>- I think we already have this as a transport option. >>- not sure I am convinced we need the signal. >>- I don't understand this signal... it seems to bind a specific TSpec >>(IPsrc,IPdst, Transport, srcport,dstport)to a L2 identity... How do you >>differentiate when a new app replaces the previous one with different >>semantics? > > > When I proposed this, I didn't think of the parts of > the UDP-Lite and DCCP specs that Joe pointed me to, > which require link layers to detect that forwarding > corrupt packets is desired. > > The "beauty" of this design notwithstanding, that signal > is therefore already existent on a per-packet basis, > so I would now agree that the message isn't useful anymore > in this direction. > > > >> > From network to transport end point:"Corruption Forwarding supported >>(CF)" >>- Why do we need to know this at the transport layer? >>- If your end systems (and any L4 middleboxes!) support UDP-Lite and/or >>DCCP with partial coverage it is FINE to use this irrespective of >>whether the links do anyrthing special. you don't gain, but you don't >>loose either. >> >>- Can you clarify how the extra signalling helps? > > > In DCCP, the data checksum option is extra overhead, but it is > useless unless you have a link which delivers known-corrupt > data. Here I'd say that it would help. > > As for UDP-Lite, a reason not to use it is (as with any > new protocol) the fact that it might not pass through > firewalls. Thus, my application could first use UDP => > extra signaling tells me to try UDP-Lite, so I do. > > Theoretically, it might be preferrable to always try > UDP-Lite first, and switch back to UDP in case of failure. > But will application programmers do this? I imagine that > the outlook of receiving a message which tells an application > to use UDP-Lite might be a more convincing argument for > application programmers to support the protocol at all. > Then again, maybe not - I'm really just guessing here. > > Cheers, > Michael > > From ternli-bounces@ietf.org Mon Sep 04 09:38:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKEeJ-0002FN-C7; Mon, 04 Sep 2006 09:38:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKEe7-0001tM-Aa for ternli@ietf.org; Mon, 04 Sep 2006 09:37:51 -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 1GKERw-00017w-53 for ternli@ietf.org; Mon, 04 Sep 2006 09:25:17 -0400 Received: from [192.168.1.100] (p508FDF82.dip.t-dialin.net [80.143.223.130]) by ilsa.franken.de (Postfix) with ESMTP id 7AB5B245CA; Mon, 4 Sep 2006 15:25:14 +0200 (CEST) (KNF account authenticated via SMTP-AUTH) In-Reply-To: <44FC2484.50201@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> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Michael Tuexen Subject: Re: [TERNLI] Forwarding corrupt packets Date: Mon, 4 Sep 2006 15:25:12 +0200 To: gorry@erg.abdn.ac.uk X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: ternli@ietf.org, Joe Touch X-BeenThere: ternli@ietf.org 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: , Errors-To: ternli-bounces@ietf.org 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. > > 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), 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. > > * 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. > > * 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. > > 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. >> > > > > From ternli-bounces@ietf.org Mon Sep 04 09:40:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKEgF-00031J-5M; Mon, 04 Sep 2006 09:40:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKEgD-00031D-Rc for ternli@ietf.org; Mon, 04 Sep 2006 09:40:01 -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 1GKEgD-0003mC-8e for ternli@ietf.org; Mon, 04 Sep 2006 09:40:01 -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 k84Ddpw3021472; Mon, 4 Sep 2006 14:39:52 +0100 (BST) Message-ID: <44FC2CA7.90602@erg.abdn.ac.uk> Date: Mon, 04 Sep 2006 14:39:51 +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: <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> In-Reply-To: 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: b132cb3ed2d4be2017585bf6859e1ede Cc: ternli@ietf.org, Joe Touch 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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. >> >> 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. > 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). >> * 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???? 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. >> >> 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. >>> >>> >> >> >> >> > > From ternli-bounces@ietf.org Mon Sep 04 10:32:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKFUV-0005XY-Nz; Mon, 04 Sep 2006 10:31:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKFUV-0005XT-4m for ternli@ietf.org; Mon, 04 Sep 2006 10:31:59 -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 1GKFUS-00047d-JM for ternli@ietf.org; Mon, 04 Sep 2006 10:31:59 -0400 Received: from [192.168.1.100] (p508FDF82.dip.t-dialin.net [80.143.223.130]) by ilsa.franken.de (Postfix) with ESMTP id 8E977245C9; Mon, 4 Sep 2006 16:31:52 +0200 (CEST) (KNF account authenticated via SMTP-AUTH) In-Reply-To: <44FC2CA7.90602@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> <44FC2CA7.90602@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: <57784F3E-B93A-4D49-AEBA-F1124D952302@lurchi.franken.de> Content-Transfer-Encoding: 7bit From: Michael Tuexen Subject: Re: [TERNLI] Forwarding corrupt packets Date: Mon, 4 Sep 2006 16:31:50 +0200 To: gorry@erg.abdn.ac.uk X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: ternli@ietf.org, Joe Touch X-BeenThere: ternli@ietf.org 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: , Errors-To: ternli-bounces@ietf.org 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. > >> 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. > >>> * 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. > > 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... >>> >>> 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. >>>> >>>> >>> >>> >>> >>> > > From ternli-bounces@ietf.org Mon Sep 04 12:02:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKGtv-00081X-Uy; Mon, 04 Sep 2006 12:02:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKGtu-0007zo-2v for ternli@ietf.org; Mon, 04 Sep 2006 12:02:18 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKGts-0000aJ-NI for ternli@ietf.org; Mon, 04 Sep 2006 12:02:18 -0400 Received: from [192.168.1.42] (pool-71-106-94-15.lsanca.dsl-w.verizon.net [71.106.94.15]) by vapor.isi.edu (8.13.8/8.13.6) with ESMTP id k84G1vGo023429; Mon, 4 Sep 2006 09:01:57 -0700 (PDT) Message-ID: <44FC4DF4.8090004@isi.edu> Date: Mon, 04 Sep 2006 09:01:56 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Michael Welzl 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> In-Reply-To: <1157356740.3197.57.camel@lap10-c703.uibk.ac.at> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5EAA8E7D0EAE85CFB4290C91" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: ternli@ietf.org X-BeenThere: ternli@ietf.org 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: , Errors-To: ternli-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5EAA8E7D0EAE85CFB4290C91 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Michael Welzl wrote: >> The question is the impact of the bad packet. =2E.. >> If the transport reacts to corrupt packets - as would be the case with= >> UDP-lite and some configs of DCCP - that would be very bad. The >> difference is whether we're talking about corrupted data and corrupted= >> headers; corrupt data isn't too bad (that's what UDP-lite and DCCP are= >> designed for). Corrupt headers are VERY bad to forward. >=20 > I still don't get it - no matter how you use them, the > reaction of DCCP and UDP-Lite would always be to silently > discard a packet if the transport header is wrong, so > no harm is being done (except for the potential waste of > bandwidth you mention above, but we agree that this isn't > substantial). Bad body, good header: the harm is the bandwidth to the correct endpoint; the benefit is that this endpoint knows something legitimate, and the packet serves as its own corruption signal Bad header: the harm is the signal is sent to the WRONG endpoint. I reviewed the Feb 2005 discussion on this issue from End2end-interest. Here's the summary: - IPv6 does NOT, in RFC2640, require link checksums (as UDP-Lite does). The relevant text is: ------------------------------- > Although IPv6 (at=20 > least as I recall) omits the IP checksum because of sufficient link=20 > checksums to detect corrupted packets, there's no requirement that link= =20 > layers have such checksums (as hinted in the UDP-Lite RFC) - at least=20 > not in 2460 (anyone else know anywhere else a body is buried in this=20 > regard?) ------------------------------- I saw no followup to that question. - I said that UDP-Lite's requirement of link checksums was an ugly layer violation. I still think that's the case. As far as I can tell, UDP-Lite is relaxing a requirement in IPv6 - allowing partial link checksums rather than full, but I can't locate that requirement, as per above. --- I don't have a problem with forwarding the information to the wrong place; I have a problem with the wrong place acting on it. You're assuming that the UDP-Lite partial checksum is sufficient to avoid that; for some reason, the UDP-Lite authors and WG clearly did not. It'd be useful to review the UDP-lite discussions as to why that text was required so prominently. Joe --------------enig5EAA8E7D0EAE85CFB4290C91 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE/E30E5f5cImnZrsRAhcpAJ9jcIGuyP4UNrGIDdDfxgOf71ALVACfQluV H6MyjlqYiQJiuPlN95S2MVc= =g6Ju -----END PGP SIGNATURE----- --------------enig5EAA8E7D0EAE85CFB4290C91-- From ternli-bounces@ietf.org Mon Sep 04 12:57:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKHlg-0004bm-R1; Mon, 04 Sep 2006 12:57:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKHlf-0004bh-Pc for ternli@ietf.org; Mon, 04 Sep 2006 12:57:51 -0400 Received: from gibson.q2s.ntnu.no ([129.241.205.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKHle-00004v-Aa for ternli@ietf.org; Mon, 04 Sep 2006 12:57:51 -0400 Received: from dhcp103.q2s.ntnu.no (dhcp103.q2s.ntnu.no [129.241.205.103]) by gibson.q2s.ntnu.no (Postfix) with ESMTP id B78532DD32D; Mon, 4 Sep 2006 18:57:48 +0200 (CEST) Subject: Re: [TERNLI] Forwarding corrupt packets From: Michael Welzl To: Joe Touch In-Reply-To: <44FC4DF4.8090004@isi.edu> 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> <44FC4DF4.8090004@isi.edu> Content-Type: text/plain Organization: University of Innsbruck Message-Id: <1157389064.3291.26.camel@lap10-c703.uibk.ac.at> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 04 Sep 2006 18:57:44 +0200 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: ternli@ietf.org X-BeenThere: ternli@ietf.org 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: , Errors-To: ternli-bounces@ietf.org Joe, I couldn't agree more with everything you say here. Cheers, Michael On Mon, 2006-09-04 at 18:01, Joe Touch wrote: > Michael Welzl wrote: > >> The question is the impact of the bad packet. > ... > >> If the transport reacts to corrupt packets - as would be the case with > >> UDP-lite and some configs of DCCP - that would be very bad. The > >> difference is whether we're talking about corrupted data and corrupted > >> headers; corrupt data isn't too bad (that's what UDP-lite and DCCP are > >> designed for). Corrupt headers are VERY bad to forward. > > > > I still don't get it - no matter how you use them, the > > reaction of DCCP and UDP-Lite would always be to silently > > discard a packet if the transport header is wrong, so > > no harm is being done (except for the potential waste of > > bandwidth you mention above, but we agree that this isn't > > substantial). > > Bad body, good header: the harm is the bandwidth to the correct > endpoint; the benefit is that this endpoint knows something legitimate, > and the packet serves as its own corruption signal > > Bad header: the harm is the signal is sent to the WRONG endpoint. > > I reviewed the Feb 2005 discussion on this issue from End2end-interest. > > Here's the summary: > > - IPv6 does NOT, in RFC2640, require link checksums (as UDP-Lite does). > > The relevant text is: > > ------------------------------- > > Although IPv6 (at > > least as I recall) omits the IP checksum because of sufficient link > > checksums to detect corrupted packets, there's no requirement that link > > layers have such checksums (as hinted in the UDP-Lite RFC) - at least > > not in 2460 (anyone else know anywhere else a body is buried in this > > regard?) > ------------------------------- > > I saw no followup to that question. > > - I said that UDP-Lite's requirement of link checksums was an ugly layer > violation. I still think that's the case. > > As far as I can tell, UDP-Lite is relaxing a requirement in IPv6 - > allowing partial link checksums rather than full, but I can't locate > that requirement, as per above. > > --- > > I don't have a problem with forwarding the information to the wrong > place; I have a problem with the wrong place acting on it. You're > assuming that the UDP-Lite partial checksum is sufficient to avoid that; > for some reason, the UDP-Lite authors and WG clearly did not. > > It'd be useful to review the UDP-lite discussions as to why that text > was required so prominently. > > Joe -- Michael Welzl University of Innsbruck From ternli-bounces@ietf.org Mon Sep 04 13:15:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKI2m-0008Dz-QA; Mon, 04 Sep 2006 13:15:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKI2l-0008Du-RC for ternli@ietf.org; Mon, 04 Sep 2006 13:15:31 -0400 Received: from gibson.q2s.ntnu.no ([129.241.205.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKI2k-0004LE-CI for ternli@ietf.org; Mon, 04 Sep 2006 13:15:31 -0400 Received: from dhcp103.q2s.ntnu.no (dhcp103.q2s.ntnu.no [129.241.205.103]) by gibson.q2s.ntnu.no (Postfix) with ESMTP id B27702DD329; Mon, 4 Sep 2006 19:15:29 +0200 (CEST) Subject: Re: [TERNLI] Forwarding corrupt packets From: Michael Welzl To: Michael Tuexen In-Reply-To: <57784F3E-B93A-4D49-AEBA-F1124D952302@lurchi.franken.de> 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> <44FC2CA7.90602@erg.abdn.ac.uk> <57784F3E-B93A-4D49-AEBA-F1124D952302@lurchi.franken.de> Content-Type: text/plain Organization: University of Innsbruck Message-Id: <1157390125.3291.43.camel@lap10-c703.uibk.ac.at> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 04 Sep 2006 19:15:25 +0200 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: ternli@ietf.org, Joe Touch X-BeenThere: ternli@ietf.org 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: , Errors-To: ternli-bounces@ietf.org Hi, I think that this SCTP proposal is very interesting - especially because it doesn't use another checksum but just assumes that everything is right because it's improbable to hit the right association anyway. I'm not yet quite sure whether I like or dislike the idea, though. I guess I dislike it: > >>> * 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. unlikely enough? does this enable an attacker to do bad things, or doesn't it? I'm thinking of a very recent email by Joe, where he explained that bad things can happen if a receiver tells a sender to slow down because the receiver has received a (corrupt) packet which it should never have received in the fist place. My argument was that this would never happen - in DCCP as well as UDP-Lite, the transport header is always checked. All of a sudden, your proposal seems to change this matter. In this context, "we just try" just doesn't have a good sound to it... > 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. and how does a sender react? In the discussions for the DCCP Data Checksum, there was agreement that we don't know enough about the right sender reaction to corruption yet - but simply sending at the same rate without reducing it at all would not be the right thing to do. This seems to contradict the following part of your draft: The DATA chunk should be treated just as if it had been marked for fast retransmit with the exception that no adjustment should be made to the value of cwnd (providing that the receiver can validate a portion of the packet as being what was sent). Cheers, Michael From ternli-bounces@ietf.org Mon Sep 04 13:24:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKIBV-0005Eu-3F; Mon, 04 Sep 2006 13:24:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKIBU-0005Ep-55 for ternli@ietf.org; Mon, 04 Sep 2006 13:24:32 -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 1GKIBS-0005h5-OT for ternli@ietf.org; Mon, 04 Sep 2006 13:24:32 -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 k84HOK8S007315; Mon, 4 Sep 2006 18:24:20 +0100 (BST) Message-ID: <44FC6144.7000701@erg.abdn.ac.uk> Date: Mon, 04 Sep 2006 18:24:20 +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: Joe Touch 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> <44FC4DF4.8090004@isi.edu> In-Reply-To: <44FC4DF4.8090004@isi.edu> 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: ea4ac80f790299f943f0a53be7e1a21a Cc: ternli@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ternli-bounces@ietf.org So, from a quick look: The first place I looked was the book on IPNG by Bradner and Mankin, and this say (p193, from Craig Partridge) and I found: "IP Header Checksum. There has been discussion indicating that the IP[v4] Checksum does not provide enough error protection to warrant its performance impact. The argument states that there is almost always a stronger datalink level CRC, and that end-to-end protection is provided by the TCP Checksum. Therefore, an IPng checksum is not reqiuired." This was the basis of what I understood, when working with UDP-Lite, and also what was finally was expressed in RFC3819: " Any new subnetwork designed to carry IP should therefore provide error detection at least as strong as the 32-bit CRC specified in [ISO3309]." Section 8.3 said: "Errors in other IPv6 header fields may go undetected within the network; this was considered a reasonable price to pay for a considerable reduction in the processing required by each router, and it was assumed that subnetworks would use a strong link CRC." It would be good to uncover more IETF History. Gorry From ternli-bounces@ietf.org Mon Sep 04 14:02:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKIm5-0006k3-Rm; Mon, 04 Sep 2006 14:02:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKIm4-0006fH-AP for ternli@ietf.org; Mon, 04 Sep 2006 14:02:20 -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 1GKIm2-0003NX-Um for ternli@ietf.org; Mon, 04 Sep 2006 14:02:20 -0400 Received: from [192.168.1.100] (p508FCA94.dip.t-dialin.net [80.143.202.148]) by ilsa.franken.de (Postfix) with ESMTP id 405F4245CA; Mon, 4 Sep 2006 20:02:14 +0200 (CEST) (KNF account authenticated via SMTP-AUTH) In-Reply-To: <1157390125.3291.43.camel@lap10-c703.uibk.ac.at> 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> <44FC2CA7.90602@erg.abdn.ac.uk> <57784F3E-B93A-4D49-AEBA-F1124D952302@lurchi.franken.de> <1157390125.3291.43.camel@lap10-c703.uibk.ac.at> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4E862E2A-DF85-47C1-98A1-991F3CB58B27@lurchi.franken.de> Content-Transfer-Encoding: 7bit From: Michael Tuexen Subject: Re: [TERNLI] Forwarding corrupt packets Date: Mon, 4 Sep 2006 20:02:11 +0200 To: Michael Welzl X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: Randall Stewart , ternli@ietf.org, Joe Touch X-BeenThere: ternli@ietf.org 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: , Errors-To: ternli-bounces@ietf.org Hi Michael, see my comments in-line. I'll not respond the next week, because I'll be on vacation :-) I'm CCing Randall Stewart, he is definitely also interest in this subject and should be available next week. Best regards Michael On Sep 4, 2006, at 7:15 PM, Michael Welzl wrote: > Hi, > > I think that this SCTP proposal is very interesting - > especially because it doesn't use another checksum but > just assumes that everything is right because it's > improbable to hit the right association anyway. I'm > not yet quite sure whether I like or dislike the > idea, though. > > I guess I dislike it: Hmmmm. > >>>>> * 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. > > unlikely enough? does this enable an attacker to do bad things, > or doesn't it? I think we have to consider two cases: - An on path attacker. He can do everything, SCTP, as any other transport layer (UDP, TCP, DCCP) does not provide any way of protection. You could use SCTP-AUTH to prevent this, but this would need a shared secret and SCTP-AUTH is an extension, not part of "plain SCTP". - An off path attacker. SCTP uses a 32 bit random number (the verification tag) to protect against bind attackers. We also recommend that one side uses a random port number (ephemeral) which would give another 14 bit randomness to guess. So it is 48 bit of randomness an attacker has to guess. The probability is 1/2^48 which is pretty small. So I do not think that this adds an additional threat to SCTP. But if you have an attack in mind, I would be very interested to think about it. We (the authors of the ID) do NOT want to make SCTP with that extension weaker than without. > > I'm thinking of a very recent email by Joe, where he explained > that bad things can happen if a receiver tells a sender to > slow down because the receiver has received a (corrupt) packet > which it should never have received in the fist place. My > argument was that this would never happen - in DCCP as well > as UDP-Lite, the transport header is always checked. > > All of a sudden, your proposal seems to change this matter. > In this context, "we just try" just doesn't have a good > sound to it... Do not get me wrong: This "we just try" means that we try to lookup the TCB. And I think if there is an error in the port number V-tag combination, then we will not find a TCB. Everything has to match. > > >> 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. > > and how does a sender react? In the discussions for the > DCCP Data Checksum, there was agreement that we don't know > enough about the right sender reaction to corruption yet - > but simply sending at the same rate without reducing it > at all would not be the right thing to do. > > This seems to contradict the following part of your draft: > > The DATA > chunk should be treated just as if it had been marked for fast > retransmit with the exception that no adjustment should be > made to > the value of cwnd (providing that the receiver can validate a > portion of the packet as being what was sent). What we know is: - the payload was corrupted (the SCTP common header was intact) - the receiver proofed that he got the packet. So it is not in the network anymore We assume that this is NOT an indication of congestion. So we can fast retransmit it... > > > Cheers, > Michael > > From ternli-bounces@ietf.org Mon Sep 04 16:01:29 2006 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 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: <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> <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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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. >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >> >> > > From ternli-bounces@ietf.org Mon Sep 04 16:32:32 2006 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> <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 Subject: Re: [TERNLI] Forwarding corrupt packets Date: Mon, 4 Sep 2006 22:32:15 +0200 To: gorry@erg.abdn.ac.uk, Randall Stewart X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 Cc: ternli@ietf.org, Joe Touch X-BeenThere: ternli@ietf.org 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: , 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. >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>> >>> > > From ternli-bounces@ietf.org Mon Sep 04 18:50:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKNGw-0007dd-9T; Mon, 04 Sep 2006 18:50:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKNGv-0007dY-GQ for ternli@ietf.org; Mon, 04 Sep 2006 18:50:29 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKNGt-0005gI-2c for ternli@ietf.org; Mon, 04 Sep 2006 18:50:29 -0400 Received: from [192.168.1.42] (pool-71-106-94-15.lsanca.dsl-w.verizon.net [71.106.94.15]) by vapor.isi.edu (8.13.8/8.13.6) with ESMTP id k84MoFGt004103; Mon, 4 Sep 2006 15:50:15 -0700 (PDT) Message-ID: <44FCADA1.5040202@isi.edu> Date: Mon, 04 Sep 2006 15:50:09 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Michael Tuexen 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> <44FC2CA7.90602@erg.abdn.ac.uk> <57784F3E-B93A-4D49-AEBA-F1124D952302@lurchi.franken.de> <1157390125.3291.43.camel@lap10-c703.uibk.ac.at> <4E862E2A-DF85-47C1-98A1-991F3CB58B27@lurchi.franken.de> In-Reply-To: <4E862E2A-DF85-47C1-98A1-991F3CB58B27@lurchi.franken.de> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF6910BACCCDA1522EC2B4B46" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Randall Stewart , ternli@ietf.org X-BeenThere: ternli@ietf.org 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: , Errors-To: ternli-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF6910BACCCDA1522EC2B4B46 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Michael Tuexen wrote: > Hi Michael, >=20 > see my comments in-line. =2E.. > I think we have to consider two cases: > - An on path attacker.... > - An off path attacker. ... Checksums are not protection from attacks. Joe --------------enigF6910BACCCDA1522EC2B4B46 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE/K2lE5f5cImnZrsRAsUeAKCmsICGfAZHpuz8ltRuXCgn3KE0mwCcCzRv yWQPp3AUAw8Gu+SrtQPNJcA= =44c5 -----END PGP SIGNATURE----- --------------enigF6910BACCCDA1522EC2B4B46-- From ternli-bounces@ietf.org Mon Sep 04 18:59:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKNPV-0003QG-Cs; Mon, 04 Sep 2006 18:59:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKNPU-0003QB-U2 for ternli@ietf.org; Mon, 04 Sep 2006 18:59:20 -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 1GKNPT-0007ar-Hj for ternli@ietf.org; Mon, 04 Sep 2006 18:59:20 -0400 Received: from [192.168.1.50] (p508FCA94.dip.t-dialin.net [80.143.202.148]) by ilsa.franken.de (Postfix) with ESMTP id 48A27245D6; Tue, 5 Sep 2006 00:59:14 +0200 (CEST) (KNF account authenticated via SMTP-AUTH) In-Reply-To: <44FCADA1.5040202@isi.edu> 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> <44FC2CA7.90602@erg.abdn.ac.uk> <57784F3E-B93A-4D49-AEBA-F1124D952302@lurchi.franken.de> <1157390125.3291.43.camel@lap10-c703.uibk.ac.at> <4E862E2A-DF85-47C1-98A1-991F3CB58B27@lurchi.franken.de> <44FCADA1.5040202@isi.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <45186152-9613-4C22-92FF-53BCD2B22337@lurchi.franken.de> Content-Transfer-Encoding: 7bit From: Michael Tuexen Subject: Re: [TERNLI] Forwarding corrupt packets Date: Tue, 5 Sep 2006 00:59:09 +0200 To: Joe Touch X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Randall Stewart , ternli@ietf.org X-BeenThere: ternli@ietf.org 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: , Errors-To: ternli-bounces@ietf.org Hi Joe, comments in-line. Best regards Michael On Sep 5, 2006, at 12:50 AM, Joe Touch wrote: > > > Michael Tuexen wrote: >> Hi Michael, >> >> see my comments in-line. > ... >> I think we have to consider two cases: >> - An on path attacker.... >> - An off path attacker. ... > > Checksums are not protection from attacks. Correct. But the question was could the PKTDRP report be used for an attack. What I wanted to make clear is the an on path attacker can use it, but he can do this even without PKTDRP. An off path attacker has the same problem as for basic SCTP without PKTDRP. > > Joe > From ternli-bounces@ietf.org Mon Sep 04 20:25:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKOkt-0006Fx-7w; Mon, 04 Sep 2006 20:25:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKOks-0006Fr-4F for ternli@ietf.org; Mon, 04 Sep 2006 20:25:30 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKOkq-0001aS-Pn for ternli@ietf.org; Mon, 04 Sep 2006 20:25:30 -0400 Received: from [192.168.1.42] (pool-71-106-94-15.lsanca.dsl-w.verizon.net [71.106.94.15]) by vapor.isi.edu (8.13.8/8.13.6) with ESMTP id k850OsdQ018630; Mon, 4 Sep 2006 17:24:54 -0700 (PDT) Message-ID: <44FCC3D5.4020403@isi.edu> Date: Mon, 04 Sep 2006 17:24:53 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Michael Tuexen 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> <44FC2CA7.90602@erg.abdn.ac.uk> <57784F3E-B93A-4D49-AEBA-F1124D952302@lurchi.franken.de> <1157390125.3291.43.camel@lap10-c703.uibk.ac.at> <4E862E2A-DF85-47C1-98A1-991F3CB58B27@lurchi.franken.de> <44FCADA1.5040202@isi.edu> <45186152-9613-4C22-92FF-53BCD2B22337@lurchi.franken.de> In-Reply-To: <45186152-9613-4C22-92FF-53BCD2B22337@lurchi.franken.de> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEDEE2F912D83B18A000866DB" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: Randall Stewart , ternli@ietf.org X-BeenThere: ternli@ietf.org 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: , Errors-To: ternli-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEDEE2F912D83B18A000866DB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Michael Tuexen wrote: > Hi Joe, >=20 > comments in-line. >=20 > Best regards > Michael >=20 > On Sep 5, 2006, at 12:50 AM, Joe Touch wrote: >=20 >> >> >> Michael Tuexen wrote: >>> Hi Michael, >>> >>> see my comments in-line. >> ... >>> I think we have to consider two cases: >>> - An on path attacker.... >>> - An off path attacker. ... >> >> Checksums are not protection from attacks. > Correct. > But the question was could the PKTDRP report be used for an attack.=20 If it isn't signed, then yes. But that holds for any message. > What > I wanted to > make clear is the an on path attacker can use it, but he can do this > even without PKTDRP. > An off path attacker has the same problem as for basic SCTP without PKT= DRP. Aren't these statements true for any unsigned SCTP message? Joe --------------enigEDEE2F912D83B18A000866DB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE/MPVE5f5cImnZrsRAhpSAKCYRxoQunOn4DrAiJs+EsaQ3JUcBACg6ptt DpGcDrONeiJMzwiyw2kb2aU= =7/qp -----END PGP SIGNATURE----- --------------enigEDEE2F912D83B18A000866DB-- From ternli-bounces@ietf.org Tue Sep 05 01:50:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKToo-0005o6-87; Tue, 05 Sep 2006 01:49:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKTom-0005o1-TU for ternli@ietf.org; Tue, 05 Sep 2006 01:49:52 -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 1GKTol-0004lQ-K0 for ternli@ietf.org; Tue, 05 Sep 2006 01:49:52 -0400 Received: from [192.168.1.50] (p508FCA94.dip.t-dialin.net [80.143.202.148]) by ilsa.franken.de (Postfix) with ESMTP id 68C5C245E3; Tue, 5 Sep 2006 07:49:43 +0200 (CEST) (KNF account authenticated via SMTP-AUTH) In-Reply-To: <44FCC3D5.4020403@isi.edu> 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> <44FC2CA7.90602@erg.abdn.ac.uk> <57784F3E-B93A-4D49-AEBA-F1124D952302@lurchi.franken.de> <1157390125.3291.43.camel@lap10-c703.uibk.ac.at> <4E862E2A-DF85-47C1-98A1-991F3CB58B27@lurchi.franken.de> <44FCADA1.5040202@isi.edu> <45186152-9613-4C22-92FF-53BCD2B22337@lurchi.franken.de> <44FCC3D5.4020403@isi.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Michael Tuexen Subject: Re: [TERNLI] Forwarding corrupt packets Date: Tue, 5 Sep 2006 07:49:40 +0200 To: Joe Touch X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Randall Stewart , ternli@ietf.org X-BeenThere: ternli@ietf.org 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: , Errors-To: ternli-bounces@ietf.org Hi Joe, comments in-line. Best regards Michael On Sep 5, 2006, at 2:24 AM, Joe Touch wrote: > > > Michael Tuexen wrote: >> Hi Joe, >> >> comments in-line. >> >> Best regards >> Michael >> >> On Sep 5, 2006, at 12:50 AM, Joe Touch wrote: >> >>> >>> >>> Michael Tuexen wrote: >>>> Hi Michael, >>>> >>>> see my comments in-line. >>> ... >>>> I think we have to consider two cases: >>>> - An on path attacker.... >>>> - An off path attacker. ... >>> >>> Checksums are not protection from attacks. >> Correct. >> But the question was could the PKTDRP report be used for an attack. > > If it isn't signed, then yes. But that holds for any message. Correct. > >> What >> I wanted to >> make clear is the an on path attacker can use it, but he can do this >> even without PKTDRP. >> An off path attacker has the same problem as for basic SCTP >> without PKTDRP. > > Aren't these statements true for any unsigned SCTP message? Correct. That was my point. SCTP with PKTDRP is not less safe than pure SCTP. > > Joe > From ternli-bounces@ietf.org Tue Sep 05 03:16:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKVA9-0005EI-R6; Tue, 05 Sep 2006 03:16:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKVA8-0005EC-DI for ternli@ietf.org; Tue, 05 Sep 2006 03:16:00 -0400 Received: from gibson.q2s.ntnu.no ([129.241.205.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKVA6-00076V-2r for ternli@ietf.org; Tue, 05 Sep 2006 03:16:00 -0400 Received: from dhcp103.q2s.ntnu.no (dhcp103.q2s.ntnu.no [129.241.205.103]) by gibson.q2s.ntnu.no (Postfix) with ESMTP id 852AA2DD32E; Tue, 5 Sep 2006 09:15:56 +0200 (CEST) Subject: Re: [TERNLI] Forwarding corrupt packets From: Michael Welzl To: Michael Tuexen In-Reply-To: <4E862E2A-DF85-47C1-98A1-991F3CB58B27@lurchi.franken.de> 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> <44FC2CA7.90602@erg.abdn.ac.uk> <57784F3E-B93A-4D49-AEBA-F1124D952302@lurchi.franken.de> <1157390125.3291.43.camel@lap10-c703.uibk.ac.at> <4E862E2A-DF85-47C1-98A1-991F3CB58B27@lurchi.franken.de> Content-Type: text/plain Organization: University of Innsbruck Message-Id: <1157440551.3195.3.camel@lap10-c703.uibk.ac.at> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 05 Sep 2006 09:15:52 +0200 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Randall Stewart , ternli@ietf.org, Joe Touch X-BeenThere: ternli@ietf.org 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: , Errors-To: ternli-bounces@ietf.org > I'll not respond the next week, because I'll be on vacation :-) there's still quite a bit of this week left :-) > So I do not think that this adds an additional threat to SCTP. > But if you have an attack in mind, I would be very interested > to think about it. We (the authors of the ID) do NOT want to > make SCTP with that extension weaker than without. I don't have a particular attack in mind, and what you said sounds convincing. I just shared my initial feelings... I'd like to leave the security check to Joe who certainly knows a lot more about these things (security is one particular weakness of mine, so I should probably just shut up). > > The DATA > > chunk should be treated just as if it had been marked for fast > > retransmit with the exception that no adjustment should be > > made to > > the value of cwnd (providing that the receiver can validate a > > portion of the packet as being what was sent). > What we know is: > - the payload was corrupted (the SCTP common header was intact) > - the receiver proofed that he got the packet. So it is not in the > network anymore > We assume that this is NOT an indication of congestion. So we can > fast retransmit > it... I fully agree about fast retransmitting. It's the "no adjustment should be made to the value of cwnd" part that worries me. Cheers, Michael From ternli-bounces@ietf.org Tue Sep 05 07:07:39 2006 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 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 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> <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 |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 X-BeenThere: ternli@ietf.org 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: , 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. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >> >> > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 815-342-5222 (cell) From ternli-bounces@ietf.org Tue Sep 05 07:08:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKYn4-0006yr-Pi; Tue, 05 Sep 2006 07:08:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKYn3-0006yl-0V for ternli@ietf.org; Tue, 05 Sep 2006 07:08:25 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKYn0-0008V1-LE for ternli@ietf.org; Tue, 05 Sep 2006 07:08:24 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 05 Sep 2006 04:08:22 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k85B8Mve031934; Tue, 5 Sep 2006 04:08:22 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k85B8L1E008910; Tue, 5 Sep 2006 04:08:21 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Sep 2006 04:08:21 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Sep 2006 04:08:19 -0700 Message-ID: <44FD5A83.7020702@cisco.com> Date: Tue, 05 Sep 2006 07:07:47 -0400 From: Randall Stewart 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 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> <44FC2CA7.90602@erg.abdn.ac.uk> <57784F3E-B93A-4D49-AEBA-F1124D952302@lurchi.franken.de> <1157390125.3291.43.camel@lap10-c703.uibk.ac.at> <4E862E2A-DF85-47C1-98A1-991F3CB58B27@lurchi.franken.de> <44FCADA1.5040202@isi.edu> <45186152-9613-4C22-92FF-53BCD2B22337@lurchi.franken.de> <44FCC3D5.4020403@isi.edu> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Sep 2006 11:08:20.0111 (UTC) FILETIME=[9878D9F0:01C6D0DB] DKIM-Signature: a=rsa-sha1; q=dns; l=1408; t=1157454502; x=1158318502; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:Randall=20Stewart=20 |Subject:Re=3A=20[TERNLI]=20Forwarding=20corrupt=20packets; X=v=3Dcisco.com=3B=20h=3DFhAEj61I/6Kdz9a6+810YG65OJE=3D; b=qBgDI3kHPtg3JBvQ4oqdl8UlcxLD1a1c/bM5TxHpqIh6ae6Oct6J6ylKKIfn0jo4pAktSwVC 6xMLYv/e6rCugwmoMjYWJ4OMSFS/5YHtfnVqvUKhuvP+f5d8xlyAK2zX; Authentication-Results: sj-dkim-3.cisco.com; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: ternli@ietf.org, Joe Touch X-BeenThere: ternli@ietf.org 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: , Errors-To: ternli-bounces@ietf.org Michael Tuexen wrote: > Hi Joe, > > comments in-line. > > Best regards > Michael > > On Sep 5, 2006, at 2:24 AM, Joe Touch wrote: > >> >> >> Michael Tuexen wrote: >> >>> Hi Joe, >>> >>> comments in-line. >>> >>> Best regards >>> Michael >>> >>> On Sep 5, 2006, at 12:50 AM, Joe Touch wrote: >>> >>>> >>>> >>>> Michael Tuexen wrote: >>>> >>>>> Hi Michael, >>>>> >>>>> see my comments in-line. >>>> >>>> ... >>>> >>>>> I think we have to consider two cases: >>>>> - An on path attacker.... >>>>> - An off path attacker. ... >>>> >>>> >>>> Checksums are not protection from attacks. >>> >>> Correct. >>> But the question was could the PKTDRP report be used for an attack. >> >> >> If it isn't signed, then yes. But that holds for any message. > > Correct. > >> >>> What >>> I wanted to >>> make clear is the an on path attacker can use it, but he can do this >>> even without PKTDRP. >>> An off path attacker has the same problem as for basic SCTP without >>> PKTDRP. >> >> >> Aren't these statements true for any unsigned SCTP message? > > Correct. That was my point. SCTP with PKTDRP is not less safe than pure > SCTP. Exactly its no different then TCP/UDP/DCCP.. anything that is not signed has this danger... R > >> >> Joe >> > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 815-342-5222 (cell) From ternli-bounces@ietf.org Tue Sep 05 11:48:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKdA1-0001Md-9a; Tue, 05 Sep 2006 11:48:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKd9z-0001MQ-T4 for ternli@ietf.org; Tue, 05 Sep 2006 11:48:23 -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 1GKd9z-00051J-AH for ternli@ietf.org; Tue, 05 Sep 2006 11:48:23 -0400 Received: from [10.0.1.28] (maxp19.dialup.abdn.ac.uk [139.133.201.178]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k85Fk2C4013119 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Tue, 5 Sep 2006 16:47:30 +0100 (BST) User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Tue, 05 Sep 2006 16:43:20 +0100 Subject: Re: [TERNLI] Forwarding corrupt packets From: Gorry Fairhurst To: Michael Tuexen , Randall Stewart Message-ID: Thread-Topic: [TERNLI] Forwarding corrupt packets Thread-Index: AcbRAgMsQdjhIjz1Edu/HwAKlc/qXg== In-Reply-To: <7B1D0EF8-91DE-4D6A-AE4F-51776BF53F4D@lurchi.franken.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" 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: a3f7094ccc62748c06b21fcf44c073ee Cc: ternli@ietf.org, Joe Touch X-BeenThere: ternli@ietf.org 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: , Errors-To: ternli-bounces@ietf.org So, now I am much clearer about the method. For me, I am pleased we had the discussion. I have a lingering query about how applicable these methods are to other link types and hence how important this is as an IETF transport activity (but that not an issue for TERNLI). Thanks, Gorry On 4/9/06 21:32, "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. >> >>>> >>>> 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. >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >> >> > From ternli-bounces@ietf.org Tue Sep 05 11:48:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKdA1-0001Ml-CU; Tue, 05 Sep 2006 11:48:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKd9z-0001MS-TY for ternli@ietf.org; Tue, 05 Sep 2006 11:48:23 -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 1GKd9y-00051g-DO for ternli@ietf.org; Tue, 05 Sep 2006 11:48:23 -0400 Received: from [10.0.1.28] (maxp19.dialup.abdn.ac.uk [139.133.201.178]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k85Fk2C5013119 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Tue, 5 Sep 2006 16:47:36 +0100 (BST) User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Tue, 05 Sep 2006 16:44:06 +0100 Subject: Re: [TERNLI] Forwarding corrupt packets From: Gorry Fairhurst To: Michael Tuexen , Joe Touch Message-ID: Thread-Topic: [TERNLI] Forwarding corrupt packets Thread-Index: AcbRAh6XXPg7kjz1Edu/HwAKlc/qXg== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" 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: 082a9cbf4d599f360ac7f815372a6a15 Cc: ternli@ietf.org X-BeenThere: ternli@ietf.org 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: , Errors-To: ternli-bounces@ietf.org This seems fine, the "risk" is only from on-path devices, same as for TCP,etc. Gorry On 5/9/06 06:49, "Michael Tuexen" wrote: > Hi Joe, > > comments in-line. > > Best regards > Michael > > On Sep 5, 2006, at 2:24 AM, Joe Touch wrote: > >> >> >> Michael Tuexen wrote: >>> Hi Joe, >>> >>> comments in-line. >>> >>> Best regards >>> Michael >>> >>> On Sep 5, 2006, at 12:50 AM, Joe Touch wrote: >>> >>>> >>>> >>>> Michael Tuexen wrote: >>>>> Hi Michael, >>>>> >>>>> see my comments in-line. >>>> ... >>>>> I think we have to consider two cases: >>>>> - An on path attacker.... >>>>> - An off path attacker. ... >>>> >>>> Checksums are not protection from attacks. >>> Correct. >>> But the question was could the PKTDRP report be used for an attack. >> >> If it isn't signed, then yes. But that holds for any message. > Correct. >> >>> What >>> I wanted to >>> make clear is the an on path attacker can use it, but he can do this >>> even without PKTDRP. >>> An off path attacker has the same problem as for basic SCTP >>> without PKTDRP. >> >> Aren't these statements true for any unsigned SCTP message? > Correct. That was my point. SCTP with PKTDRP is not less safe than > pure SCTP. >> >> Joe >> > From ternli-bounces@ietf.org Thu Sep 21 09:39:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQOlW-0008EI-Su; Thu, 21 Sep 2006 09:38:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQOlV-0008EC-Jt for ternli@ietf.org; Thu, 21 Sep 2006 09:38:57 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQOFY-0007py-E5 for ternli@ietf.org; Thu, 21 Sep 2006 09:05:56 -0400 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GQO0x-0001n2-14 for ternli@ietf.org; Thu, 21 Sep 2006 08:50:53 -0400 Received: from localhost (localhost.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 1C8CB200C987 for ; Thu, 21 Sep 2006 14:51:17 +0200 (CEST) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30135-03 for ; Thu, 21 Sep 2006 14:51:16 +0200 (CEST) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id F0EAE200C985 for ; Thu, 21 Sep 2006 14:51:16 +0200 (CEST) Received: from n-eggert.office ([10.1.1.112]) by mx1.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Sep 2006 14:50:49 +0200 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n-eggert.office (Postfix) with ESMTP id 3F42E22AED6 for ; Thu, 21 Sep 2006 14:50:49 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.2) References: Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-56-147221008; protocol="application/pkcs7-signature" Message-Id: Jabber-Id: lars.eggert@jabber.netlab.nec.de From: Lars Eggert Date: Thu, 21 Sep 2006 14:50:46 +0200 To: ternli@ietf.org X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 21 Sep 2006 12:50:49.0540 (UTC) FILETIME=[906D4040:01C6DD7C] X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) X-Spam-Score: -2.5 (--) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Subject: [TERNLI] Fwd: [Mobopts] L2 abstractions draft X-BeenThere: ternli@ietf.org 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: , Errors-To: ternli-bounces@ietf.org --Apple-Mail-56-147221008 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Wes Eddy has pointed out that this draft is doing something similar to what TERNLI is discussing one level lower in the stack. Begin forwarded message: > From: > Date: September 20, 2006 10:26:56 PM GMT+02:00 > To: > Subject: [Mobopts] L2 abstractions draft > > > Hello folks, > > we have had this work on "L2 abstractions for L3 handovers" > (draft-irtf-mobopts-l2-abstractions-00.txt) > for quite a while now > (under the name draft-koki-mobopts-l2-abstractions-04.txt). > > It has looked at how to provide abstractions at L2 that are necessary > for L3 handovers, which is quite crucial especially for real-time > applications I think. The work is available as a FreeBSD testbed, and > the > authors have compared their work with the IAB link indications draft. > > I think it is time to move this ID forward. > > I am looking for reviewers. You will be acknowledged as a reviewer. > It can also be anonymous if you so wish :-) > > Could you please let me know if you would like to be a reviewer > of this ID? > > The URL for this ID is > > http://tools.ietf.org/group/irtf/draft-irtf-mobopts-l2- > abstractions-00.t > xt > > > Thanks, > > -Rajeev > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts Lars -- Lars Eggert NEC Network Laboratories --Apple-Mail-56-147221008 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKZDCCAwEw ggJqoAMCAQICEBCR/semQl5bz/x3jtiU02YwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgxNjA5MTU0NloXDTA3MDgxNjA5MTU0 NlowYDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAL/+LXyqufw8ApYnCU24cnZ/H9S7ro4zZYeCqcyFqhwJpTcM8/yX 6Ms+16d2EtIceQS8Bas3GAUR+xfq0QI5dt8uIKM1Uy4trk8AAO0dh23+QTLw7toloArVngGIhUhC OTpVRR1bYfJTwPVpSAY43mbGhSGhwiu5035yKdYJezNWOXmuIO+lvXcD36hc5cU6AzRJkj0LYaFd WHjbfwzGmT7MO60p/7hT+aTv5xvTl/mcwslvm+KhKmJjoMYfSOF99xvuJE/rB7Ho3g6wDoeB2Tip 44Qq8CPmOHtCXzh/tF/bYo+OHStkPTzgPfOuNDMxa0/gAPEyELNL0Eh1/hC2TeMCAwEAAaM2MDQw JAYDVR0RBB0wG4EZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBQUAA4GBAHdaTI5TM5wV+LG2WW+CMEmxEyNhaRu3oca9T31HjbfHzvhVJe2fzKt1xBSo +hhCg0qKVFuE7yKxDH975Csq9jVvJJj3oL29RQjPnc3CgQqlMFJKHdJgterPQ+ZiCp05S9rbMhRl 1zxB/x+GvnDFHsXu19gA2dlynrdWN/G1BVWJMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBU b3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSsw KQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAw MFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7s vc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV 84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGR MBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUu Y29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCk HjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oL LswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoL gnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzCCBBgwggOBoAMCAQICAQAwDQYJKoZIhvcNAQEFBQAwgb8xCzAJBgNVBAYTAkRFMRww GgYDVQQIFBNCYWRlbi1Xw3VlcnR0ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQK Ew5ORUMgRXVyb3BlIEx0ZDEdMBsGA1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMT EmtvYmUubmV0bGFiLm5lYy5kZTEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5l Yy5kZTAeFw0wNDA2MTgxMTUzMDhaFw0wOTA2MTcxMTUzMDhaMIG/MQswCQYDVQQGEwJERTEcMBoG A1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMO TkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJr b2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMu ZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALQ5DCwTzpGu3RmzQY4KxiaQak/BwIW9Wk6K Mg+/V0aiWvlrz7uFdICBGVTKhyWr3F+GxRPCVTWqS9VEPf9A59DI9TFCS3FtraSx+w8ApQei8idb J0Lqu8tTz2O1gYR2dELID5wQH9dxIANt3bP39crgDZzGYxCJilcimFhADEgHAgMBAAGjggEgMIIB HDAdBgNVHQ4EFgQU6Hsv16oYecCFsl07g9gtjPEJo00wgewGA1UdIwSB5DCB4YAU6Hsv16oYecCF sl07g9gtjPEJo02hgcWkgcIwgb8xCzAJBgNVBAYTAkRFMRwwGgYDVQQIFBNCYWRlbi1Xw3VlcnR0 ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQKEw5ORUMgRXVyb3BlIEx0ZDEdMBsG A1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMTEmtvYmUubmV0bGFiLm5lYy5kZTEo MCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZYIBADAMBgNVHRMEBTADAQH/ MA0GCSqGSIb3DQEBBQUAA4GBAJfoil3cAX3cUPMFrDdlW9DPMK/+QY8EHPOsnefm77h5CmmY6J+G 5Ydl9vyHxL76Opyg8cZWOOU/k9oVv7AvQ1GmIFqVFyWKQPfEhj+EWjEnUAcI7QDN8XER+U7XRvj6 yYysFgm2Tl30QCGvmESCgYIztCKMG2cLBkEosj2kWBbXMYIDsjCCA64CAQEwdjBiMQswCQYDVQQG EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBCR/semQl5bz/x3jtiU02YwCQYFKw4D AhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwOTIx MTI1MDQ3WjAjBgkqhkiG9w0BCQQxFgQUi6y2VJRPAXbxaGAK6+Iz6Xl4l0owgdYGCSsGAQQBgjcQ BDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzAR BgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3 b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsqhkiG9w0BCRACCzGByKCBxTCB vzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhl aWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9y YXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJz LmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUABIIBADcrjH9zm6XkEJZC3+bw RDVCT9bR5NlhuJ2pnEJTt4lHI+9UoRejungyehhkjjOaw7mgv9RIoX1/pkr94R+D7K5l3rKlJ0jQ j1hDW9uPM1KZuz96XloMluwBaiPceVphNVkHvdh0l/91y2N5ZOX6xP++HOtr9aVAJHpyHKNfDuzS JPUKB9vX2/+tECg0wPf74mKv1FZSQ5zD0UealoihOnXJvgLOWPO8mL3+YcH73WIW8X842iusW/DT +Ijhksum/185LxL0bumQj1D9lz7jz7gb+8313MEkZRjaEr9M8CmufMwVMkPD1oXuEdurtwNOuy9q kQGmbqzyGflNCSZul7sAAAAAAAA= --Apple-Mail-56-147221008--