From tcpm-bounces@ietf.org Thu Feb 01 05:44:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCZQA-0006pF-E3; Thu, 01 Feb 2007 05:44:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCZQ9-0006op-0T for tcpm@ietf.org; Thu, 01 Feb 2007 05:44:01 -0500 Received: from mail.uniroma1.it ([151.100.101.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCZQ7-0000r1-Kz for tcpm@ietf.org; Thu, 01 Feb 2007 05:44:00 -0500 Received: from unknown (HELO [192.168.205.109]) ([151.100.101.4]) by mail.uniroma1.it with ESMTP; 01 Feb 2007 11:43:56 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAANTwUWXZGUE/2dsb2JhbAANnkcBAQEB X-IronPort-AV: i="4.13,266,1167606000"; d="scan'208"; a="11323882:sNHT20377133" Message-ID: <45C1C474.4090606@net.infocom.uniroma1.it> Date: Thu, 01 Feb 2007 11:44:04 +0100 From: Francesco Vacirca User-Agent: Thunderbird 1.5.0.7 (X11/20060921) MIME-Version: 1.0 To: Michael Welzl Subject: Re: [tcpm] Separate header checksums and WiFi References: <1170256423.4805.611.camel@lap10-c703.uibk.ac.at> <20070131164323.GD16985@elb.elitists.net> <45C0CE79.4040303@isi.edu> <1170263821.4805.684.camel@lap10-c703.uibk.ac.at> In-Reply-To: <1170263821.4805.684.camel@lap10-c703.uibk.ac.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: tcpm@ietf.org, iccrg@cs.ucl.ac.uk X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Some link layers use a strongest FEC to protect header. E.g. in some UMTS coding scheme the link layer employs a 1/3 codification for RLC header, whereas the payload can use a different scheme (e.g. from 4/5 to 1/3)... Maybe it could be applied also to TCP. Note that this can decrease the goodput in case of non lossy links... obviously it depends on the ratio between useful bits and transmitted bits. In the 802.11 standard some part of the packet (MAC header) is sent with a different rate to be more protected against channel impairments and also for compatibility purposes. A cross layer approach could adopt low rate also for TCP header (also IP obviously)... but I do not think that the benefits are more than disadvantages. One more thing... in case of Michael experiments, are the packet losses on the channel due to SNR fluctuations or due to MAC collisions? In the second case, it is quite normal that the whole packet (header+payload) is corrupted. Francesco Michael Welzl wrote: > I agree, and am happy to contribute what I have!!!!! > > (which is: the results, but not the time) > > > On Wed, 2007-01-31 at 18:14, Joe Touch wrote: >> Beyond what Ethan is suggesting, this is useful to write up more fully >> and publish, e.g., at Globecom or ICC. Negative results, as Ethan notes, >> are critical to the community as a whole. >> >> Joe >> >> Ethan Blanton wrote: >>> Michael Welzl spake unto us the following wisdom: >>>> I figured that the only convincing way to prove him >>>> wrong is to actually do a real-life test. I did, and >>>> proved him right :) that is, disabling checksums for >>>> parts of packets doesn't yield much of a benefit in >>>> WiFi networks, where it seems that frames are delivered >>>> in an all-or-nothing fashion. >>> I have to applaud this move. All too often we only talk about the >>> things we did that *worked*, and the same questions about things that >>> any number of people would tell you doesn't work come up over and >>> over. For this particular topic, there is now a citation, so the next >>> guy won't have to go try it himself. Thank you. >>> >>> Ethan >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www1.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Feb 01 05:45:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCZR9-00079M-Gl; Thu, 01 Feb 2007 05:45:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCZR7-00079C-Sg for tcpm@ietf.org; Thu, 01 Feb 2007 05:45:01 -0500 Received: from mail.uniroma1.it ([151.100.101.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCZR3-0000yt-I6 for tcpm@ietf.org; Thu, 01 Feb 2007 05:45:01 -0500 Received: from unknown (HELO [192.168.205.109]) ([151.100.101.4]) by mail.uniroma1.it with ESMTP; 01 Feb 2007 11:44:56 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAANTwUWXZGUE/2dsb2JhbAANnkcBAQEB X-IronPort-AV: i="4.13,266,1167606000"; d="scan'208"; a="11324126:sNHT18779173" Message-ID: <45C1C4B1.6050504@net.infocom.uniroma1.it> Date: Thu, 01 Feb 2007 11:45:05 +0100 From: Francesco Vacirca User-Agent: Thunderbird 1.5.0.7 (X11/20060921) MIME-Version: 1.0 To: tcpm@ietf.org, iccrg@cs.ucl.ac.uk Subject: Re: [tcpm] Separate header checksums and WiFi Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Michael Welzl X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org below the answer from Michael: On Thu, 2007-02-01 at 11:24, Francesco Vacirca wrote: > Some link layers use a strongest FEC to protect header. E.g. in some > UMTS coding scheme the link layer employs a 1/3 codification for RLC > header, whereas the payload can use a different scheme (e.g. from 4/5 to > 1/3)... Maybe it could be applied also to TCP. Note that this can > decrease the goodput in case of non lossy links... obviously it depends > on the ratio between useful bits and transmitted bits. > > In the 802.11 standard some part of the packet (MAC header) is sent with > a different rate to be more protected against channel impairments and > also for compatibility purposes. A cross layer approach could adopt low > rate also for TCP header (also IP obviously)... but I do not think that > the benefits are more than disadvantages. > > One more thing... in case of Michael experiments, are the packet losses > on the channel due to SNR fluctuations or due to MAC collisions? > In the second case, it is quite normal that the whole packet > (header+payload) is corrupted. They are generally due to SNR fluctuations, by transmitting between two notebooks in ad hoc mode (the only way that disabling the CRC worked for us). I remember that Mattia also did a quick check with one more notebook, to see if MAC influences the result, but it didn't seem to play a role (I don't remember if this test made it into the document in the end... I think not). It would be interesting to know why errors occur in the fashion that we saw; we measured, but don't really have an explanation. Perhaps it's the PHY coding. Anyway, for those of you in who didn't see my previous email and are confused, this link should explain it: http://www.welzl.at/research/projects/corruption/index.html Cheers, Michael _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Feb 02 13:56:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD3Yq-0004bd-4j; Fri, 02 Feb 2007 13:55:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD3Yo-0004WA-0J for tcpm@ietf.org; Fri, 02 Feb 2007 13:54:58 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD3Yk-0002EW-H5 for tcpm@ietf.org; Fri, 02 Feb 2007 13:54:57 -0500 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l12IsF6F004234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 2 Feb 2007 10:54:16 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.13.8/8.13.8/Submit) id l12IsFrY038319 for tcpm@ietf.org; Fri, 2 Feb 2007 10:54:15 -0800 (PST) (envelope-from faber) Date: Fri, 2 Feb 2007 10:54:15 -0800 From: Ted Faber To: tcpm@ietf.org Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-tcp-antispoof-05.txt (Ends 2 Feb 2007) Message-ID: <20070202185415.GC35900@hut.isi.edu> References: <20070118012440.GC1540@hut.isi.edu> <20070126174742.GF44355@hut.isi.edu> Mime-Version: 1.0 In-Reply-To: <20070126174742.GF44355@hut.isi.edu> User-Agent: Mutt/1.4.2.2i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2069991569==" Errors-To: tcpm-bounces@ietf.org --===============2069991569== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NKoe5XOeduwbEQHU" Content-Disposition: inline --NKoe5XOeduwbEQHU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 26, 2007 at 09:47:42AM -0800, Ted Faber wrote: > On Wed, Jan 17, 2007 at 05:24:41PM -0800, Ted Faber wrote: > > Hi. > >=20 > > As we mentioned in San Diego, the anti-spoof document is ready for a > > second last call. We're primarily checking to see that issues brought > > up in the first WGLC have been addressed. You can find much of that > > discussion starting here: > >=20 > > http://www1.ietf.org/mail-archive/web/tcpm/current/msg01890.html > >=20 > > The draft is available from=20 > >=20 > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-antispoof-05.txt > >=20 > > Comments (including positive ones, please) to the list. > >=20 > > This WGLC will end 2 Feb 2007 - a little more than 2 weeks from now. >=20 > Just a reminder: this WGLC has one week left. I've only seen one > message about the draft. Passing a WGLC requires some reaction from the > group. If you're interested in seeing this work done and believe that > this document represents a reasonable consensus, please speak up. And, > of course, if you see problems with the draft, also speak up. One more heads up. Today (2 Feb 2007) is the last day of this WGLC. If you've been thinking hard or meaning to get to this, please send something today. Thanks. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --NKoe5XOeduwbEQHU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.1 (FreeBSD) iD8DBQFFw4jWaUz3f+Zf+XsRAvcGAKDW2v16Q6ifyOWa5OSzQN5AccER/gCg7f+S Ra0okQROnH2Ymkjh/NPuDsI= =1yPt -----END PGP SIGNATURE----- --NKoe5XOeduwbEQHU-- --===============2069991569== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============2069991569==-- From tcpm-bounces@ietf.org Fri Feb 02 14:50:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD4P9-0000KX-It; Fri, 02 Feb 2007 14:49:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD4P7-0000JH-S3 for tcpm@ietf.org; Fri, 02 Feb 2007 14:49:01 -0500 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD4P7-0001pq-7m for tcpm@ietf.org; Fri, 02 Feb 2007 14:49:01 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id l12JmuSF019790; Fri, 2 Feb 2007 21:48:56 +0200 Date: Fri, 2 Feb 2007 21:48:56 +0200 (EET) From: Pekka Savola To: Ted Faber Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-tcp-antispoof-05.txt (Ends 2 Feb 2007) In-Reply-To: <20070202185415.GC35900@hut.isi.edu> Message-ID: References: <20070118012440.GC1540@hut.isi.edu> <20070126174742.GF44355@hut.isi.edu> <20070202185415.GC35900@hut.isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.7/2514/Thu Feb 1 23:50:10 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL, BAYES_40, NO_RELAYS, TW_GW autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Fri, 2 Feb 2007, Ted Faber wrote: >>> This WGLC will end 2 Feb 2007 - a little more than 2 weeks from now. >> >> Just a reminder: this WGLC has one week left. I've only seen one >> message about the draft. Passing a WGLC requires some reaction from the >> group. If you're interested in seeing this work done and believe that >> this document represents a reasonable consensus, please speak up. And, >> of course, if you see problems with the draft, also speak up. > > One more heads up. Today (2 Feb 2007) is the last day of this WGLC. > If you've been thinking hard or meaning to get to this, please send > something today. (As I already said earlier, I believe this is a document that should be IETF Last Called even if doing so is not required by RFC2026.) I've had some comments on earlier versions of the draft. I've now checked those. The document isn't as explicit as I'd have liked particularly in section 3.2.1, but I find it mostly acceptable. I object to the conclusion of section 3.2.1 which was not updated based on the latest discussion: As a result, address filtering is not a local solution that can be deployed to protect communicating pairs, but rather relies on a distributed infrastructure of trusted gateways filtering forged traffic where it enters the network. It is not feasible for local, incremental deployment, and relies heavily on distributed cooperation. Although useful to reduce the load of spoofed traffic, it is insufficient to protect particular connections from attack [29]. Specifically the second sentence seems somewhat assumptive of the communication patterns and usefulness thereof for the endpoints, and the resulting conclusion in the third sentence is also assumptive. Anyone will agree that address filtering is not a _complete_ solution for every communication a random host might want to do, but whether it protects some particular connections from attack depends on how those connections are situated related to the address filtering border(s) [and what filtering has been configured there] and where the attacker is (as is now slightly expanded in the 2nd paragraph). Earlier, I suggested the following replacement text (for -02): As a result, address filtering can be deployed locally but it only protects communications where both parties are local. Therefore, the larger the address filtering border is, the more extensive the protection is. This is a particularly useful means of protection for specific kinds of sessions which are known to be local. However, as address filtering is performed in the network by trusted gateways, the users not know whether the filtering exists or not. Hence, the users cannot rely on it in general and other mechanisms for protection must be used as well. Still, address filtering is very useful to protect specific kinds of communications (e.g., network management, most router-to-router communication, etc.). But a smaller delta to the current text might also be OK even if it is less explicit, for example: As a result, address filtering is not a local solution that can be deployed to protect communicating pairs, but rather relies on a distributed infrastructure of trusted gateways filtering forged traffic where it enters the network. It is not feasible as a general solution due to the lack universal deployment, but may be applicable to connections among those inside the protected border in some scenarios. Applying filtering also reduces the load of spoofed traffic [29]. As another comment, Section 3.2.1 also refers to RFC3682 section 5.1 for TTL-security discussion, and also mentions BITW tunnels. draft-ietf-rtgwg-rfc3682bis would be a better reference here as the security properties of TTL-based security and particularly use with tunnels has been greatly expanded. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Feb 03 01:43:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDEay-0007KM-Af; Sat, 03 Feb 2007 01:41:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDEaw-0007K3-Cz for tcpm@ietf.org; Sat, 03 Feb 2007 01:41:54 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDEat-0003DD-Rf for tcpm@ietf.org; Sat, 03 Feb 2007 01:41:54 -0500 Received: from [127.0.0.1] ([128.9.176.73]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l136fZNR012814; Fri, 2 Feb 2007 22:41:36 -0800 (PST) Message-ID: <45C42E9F.3000107@isi.edu> Date: Fri, 02 Feb 2007 22:41:35 -0800 From: Joe Touch User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Pekka Savola Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-tcp-antispoof-05.txt (Ends 2 Feb 2007) References: <20070118012440.GC1540@hut.isi.edu> <20070126174742.GF44355@hut.isi.edu> <20070202185415.GC35900@hut.isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: tcpm@ietf.org, Ted Faber X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Hi, all, Pekka Savola wrote: > On Fri, 2 Feb 2007, Ted Faber wrote: >>>> This WGLC will end 2 Feb 2007 - a little more than 2 weeks from now. >>> >>> Just a reminder: this WGLC has one week left. I've only seen one >>> message about the draft. Passing a WGLC requires some reaction from the >>> group. If you're interested in seeing this work done and believe that >>> this document represents a reasonable consensus, please speak up. And, >>> of course, if you see problems with the draft, also speak up. >> >> One more heads up. Today (2 Feb 2007) is the last day of this WGLC. >> If you've been thinking hard or meaning to get to this, please send >> something today. > > (As I already said earlier, I believe this is a document that should be > IETF Last Called even if doing so is not required by RFC2026.) I'm not sure every document wouldn't fall into that category; I disagree that this particular document should be treated uniquely. > I've had some comments on earlier versions of the draft. I've now > checked those. The document isn't as explicit as I'd have liked > particularly in section 3.2.1, but I find it mostly acceptable. I > object to the conclusion of section 3.2.1 which was not updated based on > the latest discussion: > > As a result, address filtering is not a local solution that can be > deployed to protect communicating pairs, but rather relies on a > distributed infrastructure of trusted gateways filtering forged > traffic where it enters the network. It is not feasible for local, > incremental deployment, and relies heavily on distributed > cooperation. Although useful to reduce the load of spoofed traffic, > it is insufficient to protect particular connections from attack > [29]. > > Specifically the second sentence seems somewhat assumptive of the > communication patterns and usefulness thereof for the endpoints, and the > resulting conclusion in the third sentence is also assumptive. Anyone > will agree that address filtering is not a _complete_ solution for every > communication a random host might want to do, but whether it protects > some particular connections from attack depends on how those connections > are situated related to the address filtering border(s) [and what > filtering has been configured there] and where the attacker is (as is > now slightly expanded in the 2nd paragraph). I entirely agree that filtering works in some cases, depending on the specifics of where it is deployed and what the nature of the attack is. For example, if you're in control of all the distributed locations where you depend on filtering, or the topology is such that they're not very distributed, things get simpler. However, that doesn't seem a useful nuance to point out, IMO. > Earlier, I suggested the following replacement text (for -02): > > As a result, address filtering can be deployed locally but it only > protects communications where both parties are local. Therefore, the > larger the address filtering border is, the more extensive the > protection > is. This is a particularly useful means of protection for specific > kinds > of sessions which are known to be local. However, as address filtering > is performed in the network by trusted gateways, the users not know > whether the filtering exists or not. Hence, the users cannot rely on it > in general and other mechanisms for protection must be used as well. > Still, address filtering is very useful to protect specific kinds of > communications (e.g., network management, most router-to-router > communication, etc.). > > But a smaller delta to the current text might also be OK even if it is > less explicit, for example: > > As a result, address filtering is not a local solution that can be > deployed to protect communicating pairs, but rather relies on a > distributed infrastructure of trusted gateways filtering forged > traffic where it enters the network. It is not feasible as a > general solution due to the lack universal deployment, but > may be applicable to connections among those inside the protected > border in some scenarios. Applying filtering also reduces > the load of spoofed traffic [29]. I agree with the second sentence, which might be useful to include. As to the last sentence, this document focuses on endpoint mechanisms for defense, and doesn't address upstream load reduction. > As another comment, Section 3.2.1 also refers to RFC3682 section 5.1 for > TTL-security discussion, and also mentions BITW tunnels. > draft-ietf-rtgwg-rfc3682bis would be a better reference here as the > security properties of TTL-based security and particularly use with > tunnels has been greatly expanded. Thanks for pointing that out. Since the ID hasn't been published yet, it's probably useful to cite both documents on that point. Joe -- ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Feb 03 01:50:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDEj8-0001wF-2n; Sat, 03 Feb 2007 01:50:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDEj7-0001wA-3I for tcpm@ietf.org; Sat, 03 Feb 2007 01:50:21 -0500 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDEj5-00072z-Is for tcpm@ietf.org; Sat, 03 Feb 2007 01:50:21 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id l136o9jV031839; Sat, 3 Feb 2007 08:50:10 +0200 Date: Sat, 3 Feb 2007 08:50:09 +0200 (EET) From: Pekka Savola To: Joe Touch Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-tcp-antispoof-05.txt (Ends 2 Feb 2007) In-Reply-To: <45C42E9F.3000107@isi.edu> Message-ID: References: <20070118012440.GC1540@hut.isi.edu> <20070126174742.GF44355@hut.isi.edu> <20070202185415.GC35900@hut.isi.edu> <45C42E9F.3000107@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.7/2517/Fri Feb 2 18:47:59 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, NO_RELAYS autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: tcpm@ietf.org, Ted Faber X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Fri, 2 Feb 2007, Joe Touch wrote: >> As a result, address filtering is not a local solution that can be >> deployed to protect communicating pairs, but rather relies on a >> distributed infrastructure of trusted gateways filtering forged >> traffic where it enters the network. It is not feasible for local, >> incremental deployment, and relies heavily on distributed >> cooperation. Although useful to reduce the load of spoofed traffic, >> it is insufficient to protect particular connections from attack >> [29]. ... >> But a smaller delta to the current text might also be OK even if it is >> less explicit, for example: >> >> As a result, address filtering is not a local solution that can be >> deployed to protect communicating pairs, but rather relies on a >> distributed infrastructure of trusted gateways filtering forged >> traffic where it enters the network. It is not feasible as a >> general solution due to the lack universal deployment, but >> may be applicable to connections among those inside the protected >> border in some scenarios. Applying filtering also reduces >> the load of spoofed traffic [29]. > > I agree with the second sentence, which might be useful to include. As to the > last sentence, this document focuses on endpoint mechanisms for defense, and > doesn't address upstream load reduction. I don't care about the last sentence, and it could be removed or reworded. It was just an attempt to rephrase the last sentence in the original (above) so that reference [29] is preserved. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Feb 03 01:53:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDEly-0003CC-Qg; Sat, 03 Feb 2007 01:53:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDElx-0003B0-VT for tcpm@ietf.org; Sat, 03 Feb 2007 01:53:17 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDElw-0007hj-JD for tcpm@ietf.org; Sat, 03 Feb 2007 01:53:17 -0500 Received: from [127.0.0.1] ([128.9.176.73]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l136qwVG015124; Fri, 2 Feb 2007 22:52:59 -0800 (PST) Message-ID: <45C43145.2050401@isi.edu> Date: Fri, 02 Feb 2007 22:52:53 -0800 From: Joe Touch User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Pekka Savola Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-tcp-antispoof-05.txt (Ends 2 Feb 2007) References: <20070118012440.GC1540@hut.isi.edu> <20070126174742.GF44355@hut.isi.edu> <20070202185415.GC35900@hut.isi.edu> <45C42E9F.3000107@isi.edu> In-Reply-To: X-Enigmail-Version: 0.94.1.2.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: tcpm@ietf.org, Ted Faber X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1562792022==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1562792022== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig73D4A8F59F1E9600403B8797" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig73D4A8F59F1E9600403B8797 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable OK - I think we have converged on this, right? Pekka Savola wrote: > On Fri, 2 Feb 2007, Joe Touch wrote: >>> As a result, address filtering is not a local solution that can be= >>> deployed to protect communicating pairs, but rather relies on a >>> distributed infrastructure of trusted gateways filtering forged >>> traffic where it enters the network. It is not feasible for loca= l, >>> incremental deployment, and relies heavily on distributed >>> cooperation. Although useful to reduce the load of spoofed traff= ic, >>> it is insufficient to protect particular connections from attack >>> [29]. > ... >>> But a smaller delta to the current text might also be OK even if it = is >>> less explicit, for example: >>> >>> As a result, address filtering is not a local solution that can b= e >>> deployed to protect communicating pairs, but rather relies on a >>> distributed infrastructure of trusted gateways filtering forged >>> traffic where it enters the network. It is not feasible as a >>> general solution due to the lack universal deployment, but >>> may be applicable to connections among those inside the protected= >>> border in some scenarios. Applying filtering also reduces >>> the load of spoofed traffic [29]. >> >> I agree with the second sentence, which might be useful to include. As= >> to the last sentence, this document focuses on endpoint mechanisms for= >> defense, and doesn't address upstream load reduction. >=20 > I don't care about the last sentence, and it could be removed or > reworded. It was just an attempt to rephrase the last sentence in the > original (above) so that reference [29] is preserved. >=20 --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enig73D4A8F59F1E9600403B8797 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 iD8DBQFFxDFKE5f5cImnZrsRAhiMAJ0Wve5tZFFYexUaQUQKkBe5gGK5PQCgnijS ghG45HMkRBNkdC5zvOZqjqg= =FYqn -----END PGP SIGNATURE----- --------------enig73D4A8F59F1E9600403B8797-- --===============1562792022== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1562792022==-- From tcpm-bounces@ietf.org Sat Feb 03 04:33:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDHFW-0004qW-V8; Sat, 03 Feb 2007 04:31:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDHFV-0004qR-JD for tcpm@ietf.org; Sat, 03 Feb 2007 04:31:57 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDHFU-00058P-5l for tcpm@ietf.org; Sat, 03 Feb 2007 04:31:57 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l139SiPj025821; Sat, 3 Feb 2007 11:28:56 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 3 Feb 2007 11:31:28 +0200 Received: from [192.168.1.33] ([10.162.253.6]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sat, 3 Feb 2007 11:31:25 +0200 In-Reply-To: <45C42E9F.3000107@isi.edu> References: <20070118012440.GC1540@hut.isi.edu> <20070126174742.GF44355@hut.isi.edu> <20070202185415.GC35900@hut.isi.edu> <45C42E9F.3000107@isi.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Lars Eggert Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-tcp-antispoof-05.txt (Ends 2 Feb 2007) Date: Sat, 3 Feb 2007 11:31:40 +0200 To: ext Joe Touch X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 03 Feb 2007 09:31:25.0698 (UTC) FILETIME=[13301620:01C74776] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: tcpm@ietf.org, Ted Faber X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1300125611==" Errors-To: tcpm-bounces@ietf.org --===============1300125611== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-35-1061855930; protocol="application/pkcs7-signature" --Apple-Mail-35-1061855930 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-2-3, at 8:41, ext Joe Touch wrote: > Pekka Savola wrote: >> (As I already said earlier, I believe this is a document that >> should be IETF Last Called even if doing so is not required by >> RFC2026.) > > I'm not sure every document wouldn't fall into that category; I > disagree that this particular document should be treated uniquely. IETF Last Calls for non-standards-track docs are common, especially when a document should be brought to the attention to the wider community due to its importance or impact. (For example, we IETF-last- called QuickStart and the fragmentation-harmful documents in the recent past.) I agree with Pekka that antispoof is sufficiently important that the wider community should be notified of its availability for review. Lars --Apple-Mail-35-1061855930 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAyMDMwOTMxNDBaMCMGCSqGSIb3DQEJBDEWBBRwQFWcksS2zGG6 h43banIGZ5ceiTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAJBploVLR9krjG1ILE/xe9/MJLOSvXTHIyE/Fk/EL01hVozOb3Z0T qbLB3pQiiKU8D7ZTmwPYEurp5AN4WIjdNpu6mo299u1MrKYHmHTsbtWPorufM0NwE9bj+IJN5wc2 PNoE/uz32B3UXN8M5jsdo6qffEiGjUjfMM7+TPHn3ZTfyVDO2iOhEbguhSKDvnGYzCIWSmTLcj7k coE2AefRK0YuUAB99DpSKfzekj/b4kYAmY3gmQDle1xSCymadqwrI7R8u9c4ssd8PCb29pyEjWeS lxn83Tkv5Fa5HZ20rJ9KbHRxLYlWcVmjpuPJ1xOBSwGaWF1yt+yrBshIZ88IowAAAAAAAA== --Apple-Mail-35-1061855930-- --===============1300125611== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1300125611==-- From tcpm-bounces@ietf.org Mon Feb 05 09:26:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE4mw-0006lN-99; Mon, 05 Feb 2007 09:25:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE4mr-0006eK-GL for tcpm@ietf.org; Mon, 05 Feb 2007 09:25:41 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE4ls-0004mL-0A for tcpm@ietf.org; Mon, 05 Feb 2007 09:24:41 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l15EOaPO008799 for ; Mon, 5 Feb 2007 06:24:37 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 5B7EA773385 for ; Mon, 5 Feb 2007 09:24:24 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 893CF17421E for ; Mon, 5 Feb 2007 09:24:25 -0500 (EST) To: tcpm@ietf.org From: Mark Allman Subject: Re: [tcpm] DoS attack from misbehaving receivers In-Reply-To: <20070113161808.GX2944@loompa.cs.umd.edu> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Mr. Jones MIME-Version: 1.0 Date: Mon, 05 Feb 2007 09:24:25 -0500 Message-Id: <20070205142425.893CF17421E@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0428385539==" Errors-To: tcpm-bounces@ietf.org --===============0428385539== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline I have thought abou this attack and had some spirited discussion with Rob on the topic. I am not greatly worried about it myself. + It is pretty easy to detect this attack (in fact there is a footnote in the paper that says the author's experiments were detected by their network provider!). It is fairly easy to see that more data is being ACKed than is being actually received. + Slammer was a one packet UDP fire and forget situation. It sourced traffic as fast as the attached link could support---no control of any kind. (Other worms have had this property, as well.) We did not see a melting core. So, I am not quite sure I am worried about a botnet of optack-ing boxes coaxing something to happen that has not already happened. + If we think this is a problem that needs a solution, we should think about how to do so without hacking things like changing the sending order. (E.g., a generalized nonce (a la Savage) or something. My two bits ... allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFxz4YWyrrWs4yIs4RAtkwAKCM5TnReFJssIlXjtA1AL7GprihxQCfUdV4 JPZC1Wc9lqyKAGgo8Zv1O5o= =YlxH -----END PGP SIGNATURE----- --=_bOundary-- --===============0428385539== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0428385539==-- From tcpm-bounces@ietf.org Mon Feb 05 13:39:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE8jO-0002iK-QZ; Mon, 05 Feb 2007 13:38:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE8jN-0002g7-Ik for tcpm@ietf.org; Mon, 05 Feb 2007 13:38:21 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE8jL-0003p5-RT for tcpm@ietf.org; Mon, 05 Feb 2007 13:38:21 -0500 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l15Ic9IS021497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 5 Feb 2007 10:38:09 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.13.8/8.13.8/Submit) id l15Ic9uq005029 for tcpm@ietf.org; Mon, 5 Feb 2007 10:38:09 -0800 (PST) (envelope-from faber) Date: Mon, 5 Feb 2007 10:38:09 -0800 From: Ted Faber To: tcpm@ietf.org Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-tcp-antispoof-05.txt (Ends 2 Feb 2007) Message-ID: <20070205183809.GA1243@hut.isi.edu> References: <20070118012440.GC1540@hut.isi.edu> Mime-Version: 1.0 In-Reply-To: <20070118012440.GC1540@hut.isi.edu> User-Agent: Mutt/1.4.2.2i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0853568701==" Errors-To: tcpm-bounces@ietf.org --===============0853568701== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ikeVEW9yuYc//A+q" Content-Disposition: inline --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 17, 2007 at 05:24:41PM -0800, Ted Faber wrote: > As we mentioned in San Diego, the anti-spoof document is ready for a > second last call. We're primarily checking to see that issues brought > up in the first WGLC have been addressed.=20 After looking over the discussion, the chairs feel that (assuming Pekka's issues have been suitably addressed) this document has passed WGLC. We'll plan to make the revisions that address Pekka's comments and then advance this to the IESG. Given Pekka's interest and Lars's support for an IETF last call, I believe we'll request one. Thanks again for your input. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --ikeVEW9yuYc//A+q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.1 (FreeBSD) iD8DBQFFx3mQaUz3f+Zf+XsRAun1AKDws8X3J1fTQIzuPIuIFykEsRz2RgCfWwbA 0Qgf6sijvtzYt18warJsVHY= =Z7Bc -----END PGP SIGNATURE----- --ikeVEW9yuYc//A+q-- --===============0853568701== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0853568701==-- From tcpm-bounces@ietf.org Mon Feb 05 14:14:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE9HP-00031z-51; Mon, 05 Feb 2007 14:13:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE9HN-00031u-VP for tcpm@ietf.org; Mon, 05 Feb 2007 14:13:29 -0500 Received: from mail.globalsuite.net ([69.46.103.200]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HE9HM-0001wc-Ie for tcpm@ietf.org; Mon, 05 Feb 2007 14:13:29 -0500 Received: from mail.globalsuite.net (unknown [127.0.0.1]) by mail.globalsuite.net (Symantec Mail Security) with ESMTP id 515DA30DEA; Mon, 5 Feb 2007 12:11:53 -0700 (MST) X-AuditID: c0a8013c-adab3bb0000055da-70-45c7814dd83b Received: from [127.0.0.1] (unknown [66.251.77.226]) by mail.globalsuite.net (Symantec Mail Security) with ESMTP id 55E7630E01; Mon, 5 Feb 2007 12:11:08 -0700 (MST) Message-ID: <45C78147.1060507@isi.edu> Date: Mon, 05 Feb 2007 11:11:03 -0800 From: Joe Touch User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Ted Faber Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-tcp-antispoof-05.txt (Ends 2 Feb 2007) References: <20070118012440.GC1540@hut.isi.edu> <20070205183809.GA1243@hut.isi.edu> In-Reply-To: <20070205183809.GA1243@hut.isi.edu> X-Enigmail-Version: 0.94.1.2.0 X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1699248077==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1699248077== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig01C1296AEF74D74ACAB4EBD5" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig01C1296AEF74D74ACAB4EBD5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ted Faber wrote: > On Wed, Jan 17, 2007 at 05:24:41PM -0800, Ted Faber wrote: >> As we mentioned in San Diego, the anti-spoof document is ready for a >> second last call. We're primarily checking to see that issues brought= >> up in the first WGLC have been addressed.=20 >=20 > After looking over the discussion, the chairs feel that (assuming > Pekka's issues have been suitably addressed) this document has passed > WGLC. We'll plan to make the revisions that address Pekka's comments Also Afred Hoenes, who pointed out a number of editorial errors I can catch at this point, and a nominal tech issue as well. I'll post a summary of changes to the list as soon as I get confirmation of acceptance from them. > and then advance this to the IESG. >=20 > Given Pekka's interest and Lars's support for an IETF last call, I > believe we'll request one. >=20 > Thanks again for your input. >=20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enig01C1296AEF74D74ACAB4EBD5 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 iD8DBQFFx4FIE5f5cImnZrsRAjOdAKDJ8QGUYoA8+XyDUR12MzGN1NlTRwCgvMkQ CDJREUVNMoP4TWaKCr0X+bM= =+FMm -----END PGP SIGNATURE----- --------------enig01C1296AEF74D74ACAB4EBD5-- --===============1699248077== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1699248077==-- From tcpm-bounces@ietf.org Mon Feb 05 16:42:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEBb2-0001Mo-HT; Mon, 05 Feb 2007 16:41:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEBb1-0001Mh-G6 for tcpm@ietf.org; Mon, 05 Feb 2007 16:41:55 -0500 Received: from circular.cs.umd.edu ([128.8.128.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEBb0-0008W9-6o for tcpm@ietf.org; Mon, 05 Feb 2007 16:41:55 -0500 Received: from loompa.cs.umd.edu (loompa.cs.umd.edu [128.8.128.63]) by circular.cs.umd.edu (8.12.11.20060308/8.12.5) with ESMTP id l15Lff7L002681; Mon, 5 Feb 2007 16:41:41 -0500 Received: (from capveg@localhost) by loompa.cs.umd.edu (8.12.10/8.12.5) id l15Lff5t016724; Mon, 5 Feb 2007 16:41:41 -0500 (EST) Date: Mon, 5 Feb 2007 16:41:41 -0500 From: Rob Sherwood To: Mark Allman Subject: Re: [tcpm] DoS attack from misbehaving receivers Message-ID: <20070205214141.GA11207@loompa.cs.umd.edu> References: <20070113161808.GX2944@loompa.cs.umd.edu> <20070205142425.893CF17421E@lawyers.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070205142425.893CF17421E@lawyers.icir.org> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Hi Mark, On Mon, Feb 05, 2007 at 09:24:25AM -0500, Mark Allman wrote: > I have thought abou this attack and had some spirited discussion with > Rob on the topic. I am not greatly worried about it myself. > > + It is pretty easy to detect this attack (in fact there is a footnote > in the paper that says the author's experiments were detected by > their network provider!). It is fairly easy to see that more data > is being ACKed than is being actually received. If I recall correctly, the majority of the previous spirited discussions surrounded this point :-) To summarize my end of that discussion, the attacker's ACK rate creates a trade-off between the detectability of the attack versus the attack's amplification factor. The paper focuses on the theoretic maximum attack rate, i.e., sending one ACK per window, without concern of detection. I believe that an intelligent attacker can construct ACKs with reduced amplification that exactly mimic the ACK stream of a valid connection, making this attack impossible to detect in general given only the sender's local information. However, even with the amplification rate reduced to avoid detection, the amount of traffic generated is still significant. For example from RFC2581: Sec 4.2, the attacker could generate ACKs for every other segment, and space each ACK 100ms apart, in effect emulating a slow connection (2 segments/100ms=~ 3000bytes/100ms=~ 29KB/s). It is not clear to me that there exists any method for the sender to locally, passively differentiate this malicious connection from a completely valid one because the ACK streams are identical. While a single connection at this speed is uninteresting for DDoS, the attacker could repeat this, in parallel, across many hosts, resulting with a large aggregate amount of traffic, only limited by the attacker's ability to produce ACKs. Sending ACKs for every other segment produces an amplification factor of 3000/40 or 75x the attacker's bandwidth, implying that a single attacker on a 100Mb/s link (for example, at a University) could in theory generate 7500Mb/s of traffic, which is more than a OC-96 link (4976.64 Mb/s) and most of the capacity of an OC-192 link (9953.28 Mbit/s ). So, this is a variant on the attack that is both difficult to detect and has potential to be dangerous. Further, the footnote is somewhat misleading. The point of that particular experiment was to maximize the amount of traffic induced from a single host, not to avoid detection. Had the experiment tried to avoid detection, for example, by using the ACK rates described above, it is highly unlikely the attack would have been detected. Operators simply cannot have alerts generated for every ~30KB/s stream on their network. > + Slammer was a one packet UDP fire and forget situation. It sourced > traffic as fast as the attached link could support---no control of > any kind. (Other worms have had this property, as well.) We did > not see a melting core. So, I am not quite sure I am worried about > a botnet of optack-ing boxes coaxing something to happen that has > not already happened. But the set of hosts susceptible to the optack attack (i.e., everything that implements TCP) is orders of magnitude larger then the set of hosts susceptible to the Slammer attack (i.e., everything that ran Microsoft's SQL server). I assume someone will correct me if I'm wrong, but I do not believe we have seen a worm attack that caused even the majority of access links to saturate, which is exactly what I contend optack+botnets can do. > + If we think this is a problem that needs a solution, we should think > about how to do so without hacking things like changing the sending > order. (E.g., a generalized nonce (a la Savage) or something. I agree that the generalized nonce solution (particularly, the cumulative nonce solution proposed by Savage et al.) is a more elegant solution. However, it requires both sender and receiver code to change, limiting its incremental deployability. If the deployability issues could be addressed, this is clearly the right way to go, IMHO. - Rob . _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Feb 05 21:16:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEFrS-000815-Ql; Mon, 05 Feb 2007 21:15:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEFrR-00080g-V5 for tcpm@ietf.org; Mon, 05 Feb 2007 21:15:09 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEFrQ-0001xC-H0 for tcpm@ietf.org; Mon, 05 Feb 2007 21:15:09 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l162Ex7w006831; Mon, 5 Feb 2007 18:15:00 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 515047779A9; Mon, 5 Feb 2007 21:14:46 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id A2B0A174A87; Mon, 5 Feb 2007 21:14:46 -0500 (EST) To: Rob Sherwood From: Mark Allman Subject: Re: [tcpm] DoS attack from misbehaving receivers In-Reply-To: <20070205214141.GA11207@loompa.cs.umd.edu> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Mr. Jones MIME-Version: 1.0 Date: Mon, 05 Feb 2007 21:14:46 -0500 Message-Id: <20070206021446.A2B0A174A87@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2067807313==" Errors-To: tcpm-bounces@ietf.org --===============2067807313== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Rob- > > + It is pretty easy to detect this attack (in fact there is a footnote > > in the paper that says the author's experiments were detected by > > their network provider!). It is fairly easy to see that more data > > is being ACKed than is being actually received. > > [...] > > I believe that an intelligent attacker can construct ACKs with reduced > amplification that exactly mimic the ACK stream of a valid connection, > making this attack impossible to detect in general given only the > sender's local information. However, even with the amplification rate > reduced to avoid detection, the amount of traffic generated is still > significant. Maybe I was not clear enough above. I think I agree with you that detection on the sender-side is hard---although, a sender that is continuously pounding is actually quite noisy and getting only ACKs that acknowledge large amounts of sequence space is suggestive. What I meant was that at the receiver side you can detect this attack pretty readily. If X bytes are received and 10X bytes are ACKed (regardless of how many ACKs are used or how they are spaced) then something is wrong. Basically, in terms of sequence space you cannot mimic the flow normal flow of ACKs and get any amplification. If you want to amplify then you have to change things and those changes can be observed. > Further, the footnote is somewhat misleading. The point of that > particular experiment was to maximize the amount of traffic induced > from a single host, not to avoid detection. Had the experiment tried > to avoid detection, for example, by using the ACK rates described > above, it is highly unlikely the attack would have been detected. I understand. I found the footnote to be illustrative in that conceivably nobody was looking for your 'attack' traffic and yet they found it and took action anyway. To me this says that if you want to amplify and maximize things then people will find you. > Operators simply cannot have alerts generated for every ~30KB/s stream > on their network. I agree. However, I can't believe you are actually suggesting using optacks to get 30KB/sec flows. You don't need optack at that point. Further, for some detection methods (i.e., more being ACKed than received) you don't need an alert---you just need to send a RST to the server and kill the connection because it isn't doing any useful work. > > + Slammer was a one packet UDP fire and forget situation. It sourced > > traffic as fast as the attached link could support---no control of > > any kind. (Other worms have had this property, as well.) We did > > not see a melting core. So, I am not quite sure I am worried about > > a botnet of optack-ing boxes coaxing something to happen that has > > not already happened. > > But the set of hosts susceptible to the optack attack (i.e., everything > that implements TCP) is orders of magnitude larger then the set of hosts > susceptible to the Slammer attack (i.e., everything that ran Microsoft's > SQL server). Three things ... + Optack is a secondary attack. That is, a host will only do optimistic ACKing once it has been compromised in some other fashion. So, saying that Slammer is somehow a bad example because it is "small" is not quite right, IMO. + I understand that one compromised machine can optack against somewhat arbitrary servers. (Although, note that you need to find places to slurp from that actually have a reasonable amount of data such that they could in fact impose a load on the network.) But, you are still going to be somewhat limited by the number of compromised hosts you can bring to bear on the DDoS. + My point in bringing up Slammer is not that it is precisely the same as what you are suggesting. My point is that this was a case where 75K hosts were pounding the network as hard as they possibly could and the core did not melt and there was no congestion collapse. I understand that you could theoretically bring more firepower to bear on the network, but I am not sure that in practical terms you could ever really do it. > I agree that the generalized nonce solution (particularly, the > cumulative nonce solution proposed by Savage et al.) is a more elegant > solution. However, it requires both sender and receiver code to > change, limiting its incremental deployability. If the deployability > issues could be addressed, this is clearly the right way to go, IMHO. What is the "deployability" issue? That it cannot happen as quickly as a sender-only hack? This all comes down to (1) do we think this is a problem that really needs to be addressed and, if so then (2) do we think this needs to be addressed immediately or would a cleaner approach that took a bit longer to engineer and deploy be fine? I am not sure I even think this is a huge problem we are facing and so I am not in favor of short term hacks when we know how to do better. I understand that we disagree on this point (which is fine). allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFx+SWWyrrWs4yIs4RApdgAKCQaZqKcKCTX4MymmNmK7ntSY8PigCeNZeY CUgaTTsI61qBl1wAG9d4WNU= =3mn0 -----END PGP SIGNATURE----- --=_bOundary-- --===============2067807313== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============2067807313==-- From tcpm-bounces@ietf.org Tue Feb 06 18:21:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEZbW-0007XE-DY; Tue, 06 Feb 2007 18:20:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEZbV-0007Wv-5j for tcpm@ietf.org; Tue, 06 Feb 2007 18:20:01 -0500 Received: from flyer.cs.umd.edu ([128.8.128.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEZbT-0002ZT-Q9 for tcpm@ietf.org; Tue, 06 Feb 2007 18:20:01 -0500 Received: from loompa.cs.umd.edu (loompa.cs.umd.edu [128.8.128.63]) by flyer.cs.umd.edu (8.12.11.20060308/8.12.5) with ESMTP id l16NJrg6003105; Tue, 6 Feb 2007 18:19:53 -0500 Received: (from capveg@localhost) by loompa.cs.umd.edu (8.12.10/8.12.5) id l16NJr0N026429; Tue, 6 Feb 2007 18:19:53 -0500 (EST) Date: Tue, 6 Feb 2007 18:19:52 -0500 From: Rob Sherwood To: Mark Allman Subject: Re: [tcpm] DoS attack from misbehaving receivers Message-ID: <20070206231952.GE11207@loompa.cs.umd.edu> References: <20070205214141.GA11207@loompa.cs.umd.edu> <20070206021446.A2B0A174A87@lawyers.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070206021446.A2B0A174A87@lawyers.icir.org> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Mon, Feb 05, 2007 at 09:14:46PM -0500, Mark Allman wrote: > Maybe I was not clear enough above. I think I agree with you that > detection on the sender-side is hard---although, a sender that is > continuously pounding is actually quite noisy and getting only ACKs that > acknowledge large amounts of sequence space is suggestive. My confusion - I thought you were referring to detecting this on the sender's side. I agree that detecting the attack on the receiving end is more straight forward, but it's not clear to me that relying on receiver-side network operators to solve this problem is always practical/desirable. While this is a more philosophical argument, it is a well established one in the DDoS literature: if your network is under attack, you want to solve the problem locally, not depend on operators at the source of the attack to solve it for you. I consider the issues with IP spoofing and the lack of pervasive egress filtering a reasonable data point of why source-side solutions are not practical. However, if this group feels that source-based prevention techniques are sufficient, then I guess I should stop bugging you :-) > I agree. However, I can't believe you are actually suggesting using > optacks to get 30KB/sec flows. You don't need optack at that point. I was suggesting that you need optack to get *many* 30KB/s flows, where the total aggregate traffic is larger than possible without optack. > Three things ... > > + Optack is a secondary attack. That is, a host will only do > optimistic ACKing once it has been compromised in some other > fashion. So, saying that Slammer is somehow a bad example because > it is "small" is not quite right, IMO. > > + I understand that one compromised machine can optack against > somewhat arbitrary servers. (Although, note that you need to find > places to slurp from that actually have a reasonable amount of data > such that they could in fact impose a load on the network.) But, > you are still going to be somewhat limited by the number of > compromised hosts you can bring to bear on the DDoS. I think I've been unclear. So if an attacker compromises K machines, and uses them to optack attack N hosts, then you are saying that the attack is limited because an attacker cannot make K big enough? I think I'm missing something, but my assumption was that this the attacker would be launching this from a botnet, which there are studies that show the existence of botnets on the order of 10K+ hosts and larger. Having a K in the 10K range with any sort of amplification factor would seem to be a significant threat to me. Additionally, I'm assuming the reason this issue was brought back up (and to this list) was that Michal Zalewski recently found a vulnerability in deployed versions of Apache and IIS that allows for a malicious client to request arbitrary data from a web server. While this is not terribly interesting in general, it means that every web server, not just those with large files, are now potential optack targets. http://www.securityfocus.com/archive/1/455833/100/0/threaded > + My point in bringing up Slammer is not that it is precisely the same > as what you are suggesting. My point is that this was a case where > 75K hosts were pounding the network as hard as they possibly could > and the core did not melt and there was no congestion collapse. I > understand that you could theoretically bring more firepower to bear > on the network, but I am not sure that in practical terms you could > ever really do it. Well, the short story is that I'm not 100% certain that the attack is practical either. My current research involves trying to decide the attack's practicality without actually running it. This includes some network topology mapping to evaluate the Internet's vulnerability to optack and non-optack bandwidth flooding attacks, and simulations to ensure that the attack is not self-limiting. However, I think it is safe to say that even if it is not practical to cause collapse in the core, there is still danger to access links such that it is still worth while spending time discussing possible solutions. > What is the "deployability" issue? That it cannot happen as quickly as > a sender-only hack? This all comes down to (1) do we think this is a > problem that really needs to be addressed and, if so then (2) do we > think this needs to be addressed immediately or would a cleaner approach > that took a bit longer to engineer and deploy be fine? I am not sure I > even think this is a huge problem we are facing and so I am not in favor > of short term hacks when we know how to do better. I understand that we > disagree on this point (which is fine). So I have backed off of my original stance w.r.t (2) since our previous conversation about this: the paper has been out for over a year now and people are not exploiting this attack in the wild, so clearly there is time to engineer a better solution if one is available. That said, I maintain that any proper solution should only modify the sender, where existing cleaner solutions modify both sender and receiver. Because the change affects security, any New Solution should not be optional or negotiated at connection time - both ends of the connection need to support it, else the attack vector persists and the solution accomplishes nothing. It does no good to have a solution where the client can just pretend to not support it. If we require that all senders and receivers implement New Solution, then it creates interoperability issues with TCP implementations that do and do not yet support New Solution. This is what I mean by the deployability issue. - Rob . _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Feb 06 22:34:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEdYK-0006Bh-Uq; Tue, 06 Feb 2007 22:33:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEdYK-0006Bc-1I for tcpm@ietf.org; Tue, 06 Feb 2007 22:33:00 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HEdYH-0003QS-Ej for tcpm@ietf.org; Tue, 06 Feb 2007 22:32:59 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l173WigL028417; Tue, 6 Feb 2007 19:32:44 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id D660077EECE; Tue, 6 Feb 2007 22:32:29 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 53DDF175AAD; Tue, 6 Feb 2007 22:32:30 -0500 (EST) To: Rob Sherwood From: Mark Allman Subject: Re: [tcpm] DoS attack from misbehaving receivers In-Reply-To: <20070206231952.GE11207@loompa.cs.umd.edu> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Mr. Jones MIME-Version: 1.0 Date: Tue, 06 Feb 2007 22:32:30 -0500 Message-Id: <20070207033230.53DDF175AAD@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0540749973==" Errors-To: tcpm-bounces@ietf.org --===============0540749973== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > My confusion - I thought you were referring to detecting this on the > sender's side. I agree that detecting the attack on the receiving end > is more straight forward, but it's not clear to me that relying on > receiver-side network operators to solve this problem is always > practical/desirable. While this is a more philosophical argument, it > is a well established one in the DDoS literature: if your network is > under attack, you want to solve the problem locally, not depend on > operators at the source of the attack to solve it for you. I consider > the issues with IP spoofing and the lack of pervasive egress filtering > a reasonable data point of why source-side solutions are not > practical. However, if this group feels that source-based prevention > techniques are sufficient, then I guess I should stop bugging you :-) But, your line of thinking here is that it is the *network* that is under attack, right? I.e., the compromised machine (the sink) and the machine it is coaxing into a higher-than-usual sending rate are merely pawns and there may be no big effects on either of these hosts or their networks, right? So, I am not sure the experience you cite above is germane. Also, in thinking about this more I think you could detect *something weird* on the sender side of the attack (i.e., the side receiving the optacks). One could think in terms of the symmetry work that Kreibich, et.al. presented at hotnets a couple years ago. The sender-side would certainly see a much larger ACK ratio than one ACK / two data packets, right? (If not then there is no amplification.) This is not as good of a test as the receiver-side test of ACKing more data than arrives in that it is not iron clad. > Additionally, I'm assuming the reason this issue was brought back up > (and to this list) was that Michal Zalewski recently found a > vulnerability in deployed versions of Apache and IIS that allows for a > malicious client to request arbitrary data from a web server. While > this is not terribly interesting in general, it means that every web > server, not just those with large files, are now potential optack > targets. > > http://www.securityfocus.com/archive/1/455833/100/0/threaded Oh, ugh. (With or without optack.) > Well, the short story is that I'm not 100% certain that the attack is > practical either. My current research involves trying to decide the > attack's practicality without actually running it. This includes some > network topology mapping to evaluate the Internet's vulnerability to > optack and non-optack bandwidth flooding attacks, and simulations to > ensure that the attack is not self-limiting. However, I think it is > safe to say that even if it is not practical to cause collapse in the > core, there is still danger to access links such that it is still > worth while spending time discussing possible solutions. I look forward to seeing this work. > So I have backed off of my original stance w.r.t (2) since our > previous conversation about this: the paper has been out for over a > year now and people are not exploiting this attack in the wild, so > clearly there is time to engineer a better solution if one is > available. (And, the attack was made public by others before your paper in an I-D. Even presented at a TCPM meeting, I believe. (Or, maybe tsvwg.)) > That said, I maintain that any proper solution should only modify the > sender, where existing cleaner solutions modify both sender and > receiver. Because the change affects security, any New Solution > should not be optional or negotiated at connection time - both ends of > the connection need to support it, else the attack vector persists and > the solution accomplishes nothing. It does no good to have a solution > where the client can just pretend to not support it. If we require > that all senders and receivers implement New Solution, then it creates > interoperability issues with TCP implementations that do and do not > yet support New Solution. This is what I mean by the deployability > issue. I understand this take. Certainly there is logic in here. But, let me come at it from a different angle. Security is all bout policy. So, maybe big web servers that don't want to be attacked just rate limit connections unless they use the new mechanism. Say, they allow some number of bytes to be sent without restriction, but if something big is being transmitted (i.e., we're in the heavy tail) then some client is not going to get good performance unless they turn on New Solution. If they don't then they will get suboptimal performance. Of course, if we're looking at things in this detail a policy could also be to limit bandwidth when connections are sending lots of data, seeing no loss and seeing big stretch ACKs and we don't need a mechanism at all. The other thing that is still rolling around my head is that this is claimed (rightly, IMO) as an attack on the *network*. Further, you are saying that a jillion tiny flows can make up the attack. Fine. So, it is not clear to me why any end host has much incentive to do something to help this problem much. It is not going to be an issue at the edges of the networks, only when things aggregate up. Of course, then also everyone has an incentive to keep the shared part of the network working well---which would then argue that a scheme that involved both endpoints might work out OK. I am still not convinced that we need to mess with the protocols at all here, however. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFyUhOWyrrWs4yIs4RAi52AJ4pxSo9YxKV00+05zYgLUzpcI0q+ACeP646 lQuDd/U8M9QYZbLoHmIixRI= =ON9L -----END PGP SIGNATURE----- --=_bOundary-- --===============0540749973== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0540749973==-- From tcpm-bounces@ietf.org Fri Feb 09 16:23:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFdCA-0007L9-Qi; Fri, 09 Feb 2007 16:22:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFdC9-0007Ku-5d; Fri, 09 Feb 2007 16:22:13 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFdC7-0002Ba-HN; Fri, 09 Feb 2007 16:22:13 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 09 Feb 2007 13:22:10 -0800 X-IronPort-AV: i="4.13,308,1167638400"; d="scan'208"; a="387569367:sNHT63232630" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l19LMAYB029818; Fri, 9 Feb 2007 13:22:10 -0800 Received: from dwingwxp ([10.32.240.194]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l19LM8ho003638; Fri, 9 Feb 2007 13:22:09 -0800 (PST) From: "Dan Wing" To: , Date: Fri, 9 Feb 2007 13:22:08 -0800 Message-ID: <015d01c74c90$5b79a990$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: Acc/7+pIYyPyXe++QkyaABxXjX3fXAMoDzcw DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7638; t=1171056130; x=1171920130; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20WGLC=20draft-ietf-behave-tcp-04=20completed |Sender:=20; bh=EqmZd2UjtCAWT8Li4D2QctAWh09jlHRzaz43ES2eI8s=; b=IQmZ4TLI7U7hdGQ6amXXG63Ky7R00pbTD+dp9FdtGZ/hmxkhOP8+h8yeUQhOGV+7PtUeufDf gKHAA8ywxnGVFrPPCqh5cM2KsRVdMVb+9rlsu66jsjevhE9JpnuU3isP; Authentication-Results: sj-dkim-5; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: baford@mit.edu, "'Kaushik Biswas \(kbiswas\)'" , 'Pyda Srisuresh' , "'Senthil Sivakumar \(ssenthil\)'" Subject: [tcpm] WGLC draft-ietf-behave-tcp-04 completed X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org The WGLC of draft-ietf-behave-tcp-04 has completed, with no comments received. The document will be sent to IESG for their review. PROTO writeup is below. -d ----- PROTO (draft-ietf-proto-wgchair-doc-shepherding-09) writeup for: "NAT Behavioral Requirements for TCP", http://www.ietf.org/internet-drafts/draft-ietf-behave-tcp-04.txt (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Dan Wing The document has been reviewed and is ready for forwarding to IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? During its development, the document has received input from members of the TCPM working group (especially Joe Touch and Fernando Gont), and that input was integrated into this document. The document had a two-week WGLC in both TCPM and BEHAVE working groups. There were no comments during this last call. The Document Shepherd has no concerns about the depth or breadth of the reviews. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? Additional review is not necessary. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. There have been a little concern that the TCP document normatively references the UDP document (draft-ietf-behave-nat-udp, soon to be published as RFC4787), because this requires reading both documents. WG consensus was to normatively reference UDP, as is done in the document. There is no IPR on this document. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document has strong WG consensus. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) None indicated. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? The document hsa pre-Feb-2007 copyright, per idnits 1.124: - This document has ISOC Copyright according to RFC 3978, instead of the newer IETF Trust Copyright according to RFC 4748. You should consider updating it; the new Copyright statement will be required from February 1st, 2007 - This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. You should consider updating it; the new disclaimer will be required from February 1st, 2007 (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes, the document has split its references. There are two I-Ds cited as normative: * draft-ietf-behave-nat-icmp, which is not yet ready for advancement (it has not been WGLC'd). It is expected to be WGLC'd later this year. * draft-ietf-behave-nat-udp is in the RFC Editor's queue. There are no downward references. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? There are no IANA considerations for this specification; the document does not describe an Expert Review process. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? This document does not contain any such formal language. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document defines a set of requirements for NATs that handle TCP that would allow many applications, such as peer-to-peer applications and on-line games, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. Working Group Summary This document was a product of the BEHAVE working group. Document Quality This document describes recommended practices for NATs. Most existing NATs already conform to these requirements. Personnel Dan Wing is the Document Shepherd, and Magnus Westerlund is the Responsible Area Director. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Feb 10 17:41:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HG0sp-0006Te-40; Sat, 10 Feb 2007 17:39:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HG0sn-0006TL-OE for tcpm@ietf.org; Sat, 10 Feb 2007 17:39:49 -0500 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HG0sk-0006hv-WF for tcpm@ietf.org; Sat, 10 Feb 2007 17:39:49 -0500 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id BA03D115BAB4 for ; Sat, 10 Feb 2007 19:39:33 -0300 (ART) Received: from fgont.gont.com.ar (157-184-231-201.fibertel.com.ar [201.231.184.157]) (authenticated bits=0) by venus.xmundo.net (8.12.11.20060308/8.12.11) with ESMTP id l1AMdRSb012723 for ; Sat, 10 Feb 2007 19:39:31 -0300 Message-Id: <7.0.1.0.0.20070210172217.0a209320@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 10 Feb 2007 17:23:43 -0300 To: tcpm@ietf.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Sat, 10 Feb 2007 19:39:33 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: ebd5ffc455fd7bcccba963126e1cf1f5 Subject: [tcpm] Alfred Hoenes: draft-ietf-tcpm-icmp-attacks-01 (etc.) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Folks, I received this feedback from Alfred Hoenes. I will most my answers soon. >From: Alfred =3D?hp-roman8?B?SM5uZXM=3D?=3D >Subject: draft-ietf-tcpm-icmp-attacks-01 (etc.) >To: fernando@gont.com.ar >Date: Wed, 10 Jan 2007 01:10:02 +0100 (MEZ) > >Hello, >after studying your I-D, draft-ietf-tcpm-icmp-attacks-01, >I would like to send you e few comments pointing out (mostly) >textual issues I found in that draft (and in a related note >you have posted). > >After reading your exposition, I really wonder why these issues, >and the countermeasures against, have not been discovered already >many years ago -- such clear is the threat, und such logical seem >the remedies! > >Here are the textual issues I found in the draft, documented as: > > >--- > > >I use change bars ('|' in column 1) and occasionally >up/down pointing marker lines ('^^^'/'vvv') to emphasize >the location of textual issues and/or proposed corrections. >All snippits are taken preserving the original identation >and formatting; modified text has been re-adjusted to match >I-D / RFC formatting rules, where appropriate. > > >(1) Section 1: > >In the first paragraph: > > ICMP [RFC0792] is a fundamental part of the TCP/IP protocol suite, > and is used mainly for reporting network error conditions. However, > the current specifications do not recommend any kind of validation >| checks on the received ICMP error messages, thus allowing variety of > attacks against TCP [RFC0793] by means of ICMP, which include blind > connection-reset, blind throughput-reduction, and blind performance- > degrading attacks. All of these attacks can be performed even being > off-path, without the need to sniff the packets that correspond to > the attacked TCP connection. >--- > ICMP [RFC0792] is a fundamental part of the TCP/IP protocol suite, > and is used mainly for reporting network error conditions. However, > the current specifications do not recommend any kind of validation >| checks on the received ICMP error messages, thus allowing a variety > of attacks against TCP [RFC0793] by means of ICMP, which include > blind connection-reset, blind throughput-reduction, and blind > performance-degrading attacks. All of these attacks can be performed > even being off-path, without the need to sniff the packets that > correspond to the attacked TCP connection. > >(2) Section 2.2 > >(2a) >In the 4th paragraph, there's the first occurrence of an 'unsatisfied' >reference tag (see marked line below): [Touch-antispoof] >This same tag recurs in the last sentence of Section 4.1, but it does >*not* appear in the References sections. > >I guess (after browsing the I-D index) that it should be: > draft-ietf-tcpm-tcp-antispoof-05 > >Please add the appropriate bibliographic entry to Section 10.2 > >(2b) >In the same paragraph, there's a typo (singular/plural mismatch): > > Generally, the four-tuple required to perform these attacks is not >| known. However, as discussed in [Watson] and [Touch-antispoof], > there are a number of scenarios (notably that of TCP connections > established between two BGP routers), in which an attacker may be > able to know or guess the four-tuple that identifies a TCP > connection. In such a case, if we assume the attacker knows the two > systems involved in the TCP connection to be attacked, both the > client-side and the server-side IP addresses could be known or be > within a reasonable number of possibilities. Furthermore, as most > Internet services use the so-called "well-known" ports, only the >| client port number might need to be guessed. In such a scenario, an > attacker would need to send, in principle, at most 65536 packets to > perform any of the attacks described in this document. However, as > most systems choose the port numbers they use for outgoing > connections from a subset of the whole port number space, the amount > of packets needed to successfully perform any of the attacks > discussed in this document could be further reduced. >--- > Generally, the four-tuple required to perform these attacks is not > known. However, as discussed in [Watson] and [Touch-antispoof], > there are a number of scenarios (notably that of TCP connections > established between two BGP routers), in which an attacker may be > able to know or guess the four-tuple that identifies a TCP > connection. In such a case, if we assume the attacker knows the two > systems involved in the TCP connection to be attacked, both the > client-side and the server-side IP addresses could be known or be > within a reasonable number of possibilities. Furthermore, as most > Internet services use the so-called "well-known" ports, only the >| client port number might needs to be guessed. In such a scenario, an > attacker would need to send, in principle, at most 65536 packets to > perform any of the attacks described in this document. However, as > most systems choose the port numbers they use for outgoing > connections from a subset of the whole port number space, the amount > of packets needed to successfully perform any of the attacks > discussed in this document could be further reduced. > >(3) Section 2.3 > >In the first paragraph, there's a typo (missing "of"), and a sentence >with two verbs. I guess the "receives" should be deleted in favour of >the "is": > >| Section 5.2 of [RFC4301] describes the processing inbound IP Traffic > in the case of "unprotected-to-protected". In the case of ICMP, when > an unprotected ICMP error message is received, it is matched to the > corresponding security association by means of the SPI (Security > Parameters Index) included in the payload of the ICMP error message. > Then, local policy is applied to determine whether to accept or > reject the message and, if accepted, what action to take as a result. > For example, if an ICMP unreachable message is received, the > implementation must decide whether to act on it, reject it, or act on > it with constraints. Section 8 ("Path MTU/DF processing") discusses > the processing of unauthenticated ICMP "fragmentation needed and DF > bit set" (type 3, code 3) and ICMPv6 "Packet Too Big" (type 2, code >| 0) messages when an IPsec implementation receives is configured to > process (vs. ignore) such messages. >--- >| Section 5.2 of [RFC4301] describes the processing of inbound IP > Traffic in the case of "unprotected-to-protected". In the case of > ICMP, when an unprotected ICMP error message is received, it is > matched to the corresponding security association by means of the SPI > (Security Parameters Index) included in the payload of the ICMP error > message. Then, local policy is applied to determine whether to > accept or reject the message and, if accepted, what action to take as > a result. For example, if an ICMP unreachable message is received, > the implementation must decide whether to act on it, reject it, or > act on it with constraints. Section 8 ("Path MTU/DF processing") > discusses the processing of unauthenticated ICMP "fragmentation > needed and DF bit set" (type 3, code 3) and ICMPv6 "Packet Too Big" >| (type 2, code 0) messages when an IPsec implementation is configured > to process (vs. ignore) such messages. > >(4) Section 5.2 > >I did not understand the last sentence in that (single) paragraph >there, until I finally arrived at guesssing that the word "advice" >perhaps should be deleted. > > [...]. Given the > hostile environments in which TCP currently operates in, and that >| advice ICMP provides an attack vector that is easier to exploit than > others (such as those discussed in [I-D.ietf-tcpm-tcpsecure]), we > believe that the improvements in TCP's resistance to these attacks > justify not taking the advice provided by the "SHOULDs" in [RFC1122]. >--- > [...]. Given the > hostile environments in which TCP currently operates in, and that >| ICMP provides an attack vector that is easier to exploit than others > (such as those discussed in [I-D.ietf-tcpm-tcpsecure]), we believe > that the improvements in TCP's resistance to these attacks justify > not taking the advice provided by the "SHOULDs" in [RFC1122]. > >(5) Section 5.2.1 > >(5a) >In the first paragraph, the wording should be improved: > > An analysis of the circumstances in which ICMP messages that indicate >| hard errors may be received can shed some light to eliminate the > impact of ICMP-based blind connection-reset attacks. >--- > An analysis of the circumstances in which ICMP messages that indicate >| hard errors may be received can shed some light on how to eliminate > the impact of ICMP-based blind connection-reset attacks. > >(5b) >In the discussion of the > > ICMPv6 type 1 (Destination Unreachable), code 1 (communication with > destination administratively prohibited) > >there is a sentence that did not make sense to me; maybe it does not >even say what you wanted to say : > > [...] However, there is no reason to think that in > the same way this error condition appeared, it will not get solved > in the near term. [...] > >I guess it was intended to state something like: > > In real life, this error condition will appear > very rarely; if it persists, it will be handled correctly after the > ensuing ACK timeout. > >(5b) >In the paragraph after the five ICMP message type explanations (this is >the 5th-to-last paragraph of the section), there are two sentences with >two verbs each: "is" + "is" , and "are" + "indicate" , respectively: > > Therefore, when following the reasoning explained above, TCPs in > synchronized states would treat all of the above messages as > indicating "soft errors", rather than "hard errors", and thus would >| not abort the corresponding connection upon receipt of them. This is > policy is based on the premise that TCP should be as robust as > possible. Reaction to these messages when they are meant for > connections in non-synchronized states could still remain as adviced > by [RFC1122], as we consider the attack window for connections in the > non-synchronized states is very small, and error messages received in >| these states are more likely indicate that the connection was opened > improperly [RFC0816]. Additionally, for the sake of robustness and > security, those implementations following the reasoning explained in > this section would not extrapolate ICMP errors across TCP > connections. >--- > Therefore, when following the reasoning explained above, TCPs in > synchronized states would treat all of the above messages as > indicating "soft errors", rather than "hard errors", and thus would >| not abort the corresponding connection upon receipt of them. This > policy is based on the premise that TCP should be as robust as > possible. Reaction to these messages when they are meant for > connections in non-synchronized states could still remain as adviced > by [RFC1122], as we consider the attack window for connections in the > non-synchronized states is very small, and error messages received in >| these states more likely indicate that the connection was opened > improperly [RFC0816]. Additionally, for the sake of robustness and > security, those implementations following the reasoning explained in > this section would not extrapolate ICMP errors across TCP > connections. > >(5c) >In the subsequent paragraph, the above 'magic' sentence recurs in >slightly modified form: > > In case the received message were legitimate, it would mean that the > error condition appeared during the life of the corresponding >| connection. However, in many scenarios there is no reason to think >| that in the same way this error condition appeared, it will not get >| solved in the near term. [...] > >"there is no reason to think that ... it will not get solved ..." >just contains too many negations. This sentence might be replaced >in a similar way as proposed above. > >(5d) >Stepping ahead, in the next paragraph (3rd-to-last in the Section), >the wording should preferrably be improved: > >| One scenario in which a host would benefit from treating the so- > called ICMP "hard errors" as "soft errors" would be that in which the > packets that correspond to a given TCP connection are routed along > multiple different paths. [...] >--- >| Another scenario in which a host would benefit from treating the so- > called ICMP "hard errors" as "soft errors" would be that in which the > packets that correspond to a given TCP connection are routed along > multiple different paths. [...] > >(5e) >The next paragraph deals with ignored error messages and out-of-band >signalling of error conditions. Therefore, "received error messages" >should better be replaced by just "error conditions" : > > It is interesting to note that, as ICMP error messages are > unreliable, transport protocols should not depend on them for correct > functioning. In the event one of these messages were legitimate, the > corresponding connection would eventually time out. Also, >| applications may still be notified asynchronously about the received >| error messages, and thus may still abort their connections on their > own if they consider it appropriate. >--- > It is interesting to note that, as ICMP error messages are > unreliable, transport protocols should not depend on them for correct > functioning. In the event one of these messages were legitimate, the > corresponding connection would eventually time out. Also, >| applications may still be notified asynchronously about the error >| conditions, and thus may still abort their connections on their own > if they consider it appropriate. > >[ In place of "error conditions", you might prefer "error condition", > "errors", or "error" . ] > >(6) Section 5.2.3 > >(6a) >As in (5e) above (including the note), in the first paragraph: > > [...]. It should also be noted that applications may >| still be notified asynchronously about the received error messages, > and thus may still abort their connections on their own if they > consider it appropriate. >--- > [...]. It should also be noted that applications may >| still be notified asynchronously about the error conditions, and thus > may still abort their connections on their own if they consider it > appropriate. > >(6b) >And again, in the second paragraph: > > [...]. Additionally, applications may still be notified >| asynchronously about the received error messages, and thus may still > abort their connections on their own if they consider it appropriate. >--- > [...]. Additionally, applications may still be notified >| asynchronously about the error conditions, and thus may still > abort their connections on their own if they consider it appropriate. > >(7) Section 6.1 > >At the end of the (single) paragraph, add the missing article, "an": > >| [...]. The throughput achieved during attack might be a > little higher if a larger initial congestion window is in use > [RFC3390]. >--- >| [...]. The throughput achieved during an attack might be > a little higher if a larger initial congestion window is in use > [RFC3390]. > >(8) Section 7.1 > >I propose a textual enhancement in the 5th paragraph. >IMHO, the referred to "IRQ ... rate" problem is only one face of the >whole story. Below, I substitute "protocol processing time" for that >(you might also add it, as "IRQ ... rate and protocol processing time"). > > [...]. On >| virtually all systems this will lead to an increase in the IRQ >| (Interrrupt ReQuest) rate, thus increasing processor utilization, and > degrading the overall system performance. >--- > [...]. On >| virtually all systems this will lead to an increase in the protocol >| processing time, thus increasing processor utilization, and degrading > the overall system performance. > >(9) Section 7.2 > >(9a) >In the classification performed: > > To achieve both goals, we can divide the traditional PMTUD mechanism > into two stages: Initial Path-MTU Discovery, and Path-MTU Update. > >the latter apparently is intended to deal with PMTU reduction only, >as can be seen from the subsequent discussion. > >IMHO, that has one serious drawback: it does not cover the "probing >for PMTU increase" described in the third paragraph of Section 3 of >RFC 1191, intended to discover effective PMTU introduced by routing >changes. I'm not sure whether this procedure is handled gracefully >by your algorithm -- but I might err here; I just do not have enough >spare time to delve into performing 'mental simulation' for that >scenario now. Please check. > >In any case, I would appreciate an extended discussion clearly >covering this third case, throughout Section 7.2, and perhaps also >an addition to Appendix A showing the behaviour during PMTU probing. > >(9b) >In the 17th paragraph of Section 7.2, perhaps "everytime" should be >replaced by "every time", according to the context. > >(10) References > >(10a) missing entry -- see (2a) above > >(10b) >There's a typo in your own URI [Ouch!] : > > [ICMP-Filtering] > Gont, F., "Filtering of ICMP error messages", http:// > www.gont.com.ar/papers/filtering-icmp-error-messages.pdf. >--- > [ICMP-Filtering] > Gont, F., "Filtering of ICMP error messages", http:// > www.gont.com.ar/papers/filtering-of-icmp-error-messages.pdf. > ^^^ >BTW: >... And in that memo, I found two small typos as well: > >(F1) First bullet on page 1: > "on of" --> "one of" > >(F2) First subordinate bullet of first bullet on page 2: > "intermmediate" --> "intermediate" > >(11) Appendix B > >(11a) >Repeated "far" <--> "for" ; missing punctuation > > maxsizeacked > Variable holding the largest packet size (data, plus headers) that >| has so for been acked far this connection, as explained in >| Section 7.2 >--- > maxsizeacked > Variable holding the largest packet size (data, plus headers) that >| has so far been acked for this connection, as explained in >| Section 7.2. > > maxsizesent > Variable holding the largest packet size (data, plus headers) that >| has so for been sent far this connection, as explained in >| Section 7.2 >--- > maxsizesent > Variable holding the largest packet size (data, plus headers) that >| has so far been sent for this connection, as explained in >| Section 7.2. > > nsegrto > Variable holding the number of times this segment has timed out, >| as explained in Section 7.2 >--- > nsegrto > Variable holding the number of times this segment has timed out, >| as explained in Section 7.2. > > packet_size >| Variable holding the size of the IP datagram being sent >--- > packet_size >| Variable holding the size of the IP datagram being sent. > >(11b) >In the pseudocode for > > EVENT: Segment is received > >correct > if (pending_mesage) >--- > if (pending_message) > >(11c) >The presentation of the pseudocode for > > EVENT: ICMP "Packet Too Big" message is received > >suffers from the deep nesting and varying use of braces. >[Note: That's perfectly o.k. from a syntax point of view (in 'C').] >I propose to streamline the presentation to enhance the readability, >by making it more compact and better show the structure of a single >case switch (exactly one of the code blocks is to be executed in >any case): > > if (claimedtcpseq < SND.UNA || claimed_TCP_SEQ >=3D SND.NXT){ > drop_message(); >| } >| >| else { >| if (claimedmtu >=3D maxsizesent || claimedmtu >=3D= current_mtu) > drop_message(); >| >| else { >| if (claimedmtu > maxsizeacked){ > adjust_mtu(); > current_mtu =3D claimedmtu; > maxsizesent =3D MINIMUM_MTU; >| } >| >| else { > pending_message =3D 1; > save_message(); >| } >| } > } >--- >| if (claimedtcpseq < SND.UNA || claimed_TCP_SEQ >=3D SND.NXT) { >| drop_message(); >| } else if (claimedmtu >=3D maxsizesent || >| claimedmtu >=3D current_mtu) { >| drop_message(); >| } else if (claimedmtu > maxsizeacked) { >| adjust_mtu(); >| current_mtu =3D claimedmtu; >| maxsizesent =3D MINIMUM_MTU; >| } else { >| pending_message =3D 1; >| save_message(); >| } > >[ This time, I also have tagged the lines that only had their > indentation changed, because that's the visual clue intended; I have > removed the redundant braces of type else { if } , > but added (arguably redundant) braces around the second instance of > drop_message(); just for symmetry; the line break after '||' is > introduced only to accomodate for the line length restriction. ] > >(12) Appendix E > >(12a) >Apparently there is something wrong with E.1 and E.2 : > >E.1. Changes from draft-gont-tcpm-icmp-attacks-05 <---+ >E.2. Changes from draft-ietf-tcpm-icmp-attacks-00 <---+ >E.3. Changes from draft-gont-tcpm-icmp-attacks-04 >E.4. Changes from draft-gont-tcpm-icmp-attacks-03 >E.5. Changes from draft-gont-tcpm-icmp-attacks-02 >E.6. Changes from draft-gont-tcpm-icmp-attacks-01 >E.7. Changes from draft-gont-tcpm-icmp-attacks-00 > >Shouldn't the sequence of the subsections correspond to the history, >with the draft-ietf-*-00 being the latest, listed first? > >I do not know whether just the headlines are exchanged, or the full >sub-sections are misoredered. Please check. > >(12b) typo in current E.2 : > >| o Added an specific section on IPsec (Section 2.3) >--- >| o Added a specific section on IPsec (Section 2.3) > >(12b) garbage in E.6 : > >| o Added Section on Acknowledgement number checking"/> >--- >| o Added Section on Acknowledgement number checking > > >Best regards, > Alfred H=CEnes. > >-- > >+------------------------+--------------------------------------------+ >| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | >| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | >| D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | >+------------------------+--------------------------------------------+ -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Feb 11 11:22:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGHRv-0008ET-45; Sun, 11 Feb 2007 11:21:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGHRt-0008E0-8P for tcpm@ietf.org; Sun, 11 Feb 2007 11:21:09 -0500 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGHRr-0001Ih-Rh for tcpm@ietf.org; Sun, 11 Feb 2007 11:21:09 -0500 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id D15D0F0C43A for ; Sun, 11 Feb 2007 13:21:08 -0300 (ART) Received: from fgont.gont.com.ar (157-184-231-201.fibertel.com.ar [201.231.184.157]) (authenticated bits=0) by venus.xmundo.net (8.12.11.20060308/8.12.11) with ESMTP id l1BGL6mw029875 for ; Sun, 11 Feb 2007 13:21:07 -0300 Message-Id: <200702111621.l1BGL6mw029875@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 11 Feb 2007 12:56:07 -0300 To: tcpm@ietf.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Sun, 11 Feb 2007 13:21:08 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [tcpm] Revision of draft-larsen-tsvwg-port-randomization X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Folks, We have published a revision of the port randomization draft (draft-larsen-tsvwg-port-randomization). This version addresses feedback from Alfred Hoenes and Carlos Pignataro, and comments from FreeBSD's Mike Silbersack. The draft is targetted at tsvwg because the same stuff can be applied to other protocols. But most (all?) of the work on this has been done mainly for TCP. The draft is available at http://www.gont.com.ar/drafts/port-randomization/draft-larsen-tsvwg-port-randomization-01.txt , and will soon be available at the usual places. Any feedback will be more than welcome. Thanks! -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Feb 13 10:07:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGzF0-0001Ia-DX; Tue, 13 Feb 2007 10:06:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGzEy-0001Hd-HK for tcpm@ietf.org; Tue, 13 Feb 2007 10:06:44 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGzEv-0002IK-DW for tcpm@ietf.org; Tue, 13 Feb 2007 10:06:44 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l1DF6eMc009110 for ; Tue, 13 Feb 2007 07:06:40 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 54A127B0437 for ; Tue, 13 Feb 2007 10:06:35 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id D150917ABB3 for ; Tue, 13 Feb 2007 10:00:31 -0500 (EST) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Whole Lotta Love MIME-Version: 1.0 Date: Tue, 13 Feb 2007 10:00:31 -0500 Message-Id: <20070213150031.D150917ABB3@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Subject: [tcpm] rfc2581bis [1]: setting ssthresh X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1802312809==" Errors-To: tcpm-bounces@ietf.org --===============1802312809== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Folks- We have just submitted a new rev of 2581bis. We fixed some minor things that folks flagged. In addition, we made two substantive changes, which I am putting into two different emails. The draft should pop out of the usual places soon, but until then you can slurp a copy from: http://www.icir.org/mallman/papers/draft-ietf-tcpm-rfc2581bis-02.txt The first issue we discussed a while back (in Montreal) and I believe the room had decent consensus on this, but it took a while to roll it into the draft and therefore verify it here on the list. The change... On the first retransmission of a segment with sequence number X the ssthresh is set to half the FlightSize as it always has been specified. However, on subsequent retransmissions the same segment ssthresh is held constant. RFC 2581 was ambiguous on this point. However, the intent was that ssthresh be halved on each retransmit. However, the WG seems to have consensus that this is not really required and the upside is that we do not doom connections to linear growth hell for ephemeral network conditions. Why I think this is OK is that if it is a problem that we held ssthresh constant and did not drop it then we will quickly learn of this by taking more loss and therefore collapsing ssthresh further. If folks feel that we have taken the wrong approach in the document, please yell. Thanks, allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFF0dKPWyrrWs4yIs4RAogqAJ9S+yrCoVLuMI/PGTF26GuRYXMG8wCfYnKt XOXGjFbWsuPxRfDG5qbo1Kc= =CXgY -----END PGP SIGNATURE----- --=_bOundary-- --===============1802312809== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-From tcpm-bounces@ietf.org Tue Feb 13 10:07:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGzF0-0001Ia-DX; Tue, 13 Feb 2007 10:06:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGzEy-0001Hd-HK for tcpm@ietf.org; Tue, 13 Feb 2007 10:06:44 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGzEv-0002IK-DW for tcpm@ietf.org; Tue, 13 Feb 2007 10:06:44 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l1DF6eMc009110 for ; Tue, 13 Feb 2007 07:06:40 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 54A127B0437 for ; Tue, 13 Feb 2007 10:06:35 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id D150917ABB3 for ; Tue, 13 Feb 2007 10:00:31 -0500 (EST) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Whole Lotta Love MIME-Version: 1.0 Date: Tue, 13 Feb 2007 10:00:31 -0500 Message-Id: <20070213150031.D150917ABB3@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Subject: [tcpm] rfc2581bis [1]: setting ssthresh X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1802312809==" Errors-To: tcpm-bounces@ietf.org --===============1802312809== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Folks- We have just submitted a new rev of 2581bis. We fixed some minor things that folks flagged. In addition, we made two substantive changes, which I am putting into two different emails. The draft should pop out of the usual places soon, but until then you can slurp a copy from: http://www.icir.org/mallman/papers/draft-ietf-tcpm-rfc2581bis-02.txt The first issue we discussed a while back (in Montreal) and I believe the room had decent consensus on this, but it took a while to roll it into the draft and therefore verify it here on the list. The change... On the first retransmission of a segment with sequence number X the ssthresh is set to half the FlightSize as it always has been specified. However, on subsequent retransmissions the same segment ssthresh is held constant. RFC 2581 was ambiguous on this point. However, the intent was that ssthresh be halved on each retransmit. However, the WG seems to have consensus that this is not really required and the upside is that we do not doom connections to linear growth hell for ephemeral network conditions. Why I think this is OK is that if it is a problem that we held ssthresh constant and did not drop it then we will quickly learn of this by taking more loss and therefore collapsing ssthresh further. If folks feel that we have taken the wrong approach in the document, please yell. Thanks, allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFF0dKPWyrrWs4yIs4RAogqAJ9S+yrCoVLuMI/PGTF26GuRYXMG8wCfYnKt XOXGjFbWsuPxRfDG5qbo1Kc= =CXgY -----END PGP SIGNATURE----- --=_bOundary-- --===============1802312809== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1802312809==-- From tcpm-bounces@ietf.org Tue Feb 13 10:07:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGzF0-0001If-Ji; Tue, 13 Feb 2007 10:06:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGzEz-0001Hn-1l for tcpm@ietf.org; Tue, 13 Feb 2007 10:06:45 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGzEv-0002IL-Ec for tcpm@ietf.org; Tue, 13 Feb 2007 10:06:45 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l1DF6eiL009111 for ; Tue, 13 Feb 2007 07:06:40 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 569107B0438 for ; Tue, 13 Feb 2007 10:06:35 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id D2A7A17ABD4 for ; Tue, 13 Feb 2007 10:03:47 -0500 (EST) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Whole Lotta Love MIME-Version: 1.0 Date: Tue, 13 Feb 2007 10:03:47 -0500 Message-Id: <20070213150347.D2A7A17ABD4@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: [tcpm] rfc2581bis [2]: limiting cwnd inflation X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1749268911==" Errors-To: tcpm-bounces@ietf.org --===============1749268911== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Reminder, the draft should pop out of the usual places soon, but until then you can slurp a copy from: http://www.icir.org/mallman/papers/draft-ietf-tcpm-rfc2581bis-02.txt The second issue ... We added a note to step 4 of the fast retransmit/recovery procedure: 4. For each additional duplicate ACK received (after the third), cwnd MUST be incremented by SMSS. This artificially inflates the congestion window in order to reflect the additional segment that has left the network. Note: [SCWA99] discusses a receiver-based attack whereby many bogus duplicate ACKs are sent to the data sender in order to artificially inflate cwnd and cause a higher than appropriate sending rate to be used. A TCP MAY therefore limit the number of times cwnd is artificially inflated during loss recovery to the number of outstanding segments (or, an approximation thereof). That is, we explicitly allow a TCP to limit the number of dupacks that are acceptable during fast recovery to prevent an attack such as discussed in [SCWA99]. Note that (1) this is more conservative than the algorithm in 2581 and so implicitly allowed already (that is, we are just calling attention to this) and (2) we are not trying to mandate this behavior, just noting that it might be useful. Comments would be appreciated. Thanks, allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DTransfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1802312809==-- From tcpm-bounces@ietf.org Tue Feb 13 10:07:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGzF0-0001If-Ji; Tue, 13 Feb 2007 10:06:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGzEz-0001Hn-1l for tcpm@ietf.org; Tue, 13 Feb 2007 10:06:45 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGzEv-0002IL-Ec for tcpm@ietf.org; Tue, 13 Feb 2007 10:06:45 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l1DF6eiL009111 for ; Tue, 13 Feb 2007 07:06:40 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 569107B0438 for ; Tue, 13 Feb 2007 10:06:35 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id D2A7A17ABD4 for ; Tue, 13 Feb 2007 10:03:47 -0500 (EST) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Whole Lotta Love MIME-Version: 1.0 Date: Tue, 13 Feb 2007 10:03:47 -0500 Message-Id: <20070213150347.D2A7A17ABD4@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: [tcpm] rfc2581bis [2]: limiting cwnd inflation X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1749268911==" Errors-To: tcpm-bounces@ietf.org --===============1749268911== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Reminder, the draft should pop out of the usual places soon, but until then you can slurp a copy from: http://www.icir.org/mallman/papers/draft-ietf-tcpm-rfc2581bis-02.txt The second issue ... We added a note to step 4 of the fast retransmit/recovery procedure: 4. For each additional duplicate ACK received (after the third), cwnd MUST be incremented by SMSS. This artificially inflates the congestion window in order to reflect the additional segment that has left the network. Note: [SCWA99] discusses a receiver-based attack whereby many bogus duplicate ACKs are sent to the data sender in order to artificially inflate cwnd and cause a higher than appropriate sending rate to be used. A TCP MAY therefore limit the number of times cwnd is artificially inflated during loss recovery to the number of outstanding segments (or, an approximation thereof). That is, we explicitly allow a TCP to limit the number of dupacks that are acceptable during fast recovery to prevent an attack such as discussed in [SCWA99]. Note that (1) this is more conservative than the algorithm in 2581 and so implicitly allowed already (that is, we are just calling attention to this) and (2) we are not trying to mandate this behavior, just noting that it might be useful. Comments would be appreciated. Thanks, allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFF0dNTWyrrWs4yIs4RAh34AJ9GVYF6RTq6oKCZUuXIIV1U9GWjHgCggsd5 ndDQ1iokmer7zEPQ6OGjr0w= =GHMV -----END PGP SIGNATURE----- --=_bOundary-- --===============1749268911== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1749268911==-- BQFF0dNTWyrrWs4yIs4RAh34AJ9GVYF6RTq6oKCZUuXIIV1U9GWjHgCggsd5 ndDQ1iokmer7zEPQ6OGjr0w= =GHMV -----END PGP SIGNATURE----- --=_bOundary-- --===============1749268911== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1749268911==-- From tcpm-bounces@ietf.org Tue Feb 13 13:24:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH2KG-0006qh-MV; Tue, 13 Feb 2007 13:24:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH2KF-0006qG-SH for tcpm@ietf.org; Tue, 13 Feb 2007 13:24:23 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HH2KC-0008Hf-8I for tcpm@ietf.org; Tue, 13 Feb 2007 13:24:23 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 13 Feb 2007 10:24:18 -0800 X-IronPort-AV: i="4.14,163,1170662400"; d="scan'208,217,147"; a="388690491:sNHT359305886" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l1DIOJrS007803 for ; Tue, 13 Feb 2007 10:24:19 -0800 Received: from [171.69.156.46] (dhcp-171-69-156-46.cisco.com [171.69.156.46]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l1DIOJnF010799 for ; Tue, 13 Feb 2007 10:24:19 -0800 (PST) Message-ID: <45D20253.70706@cisco.com> Date: Tue, 13 Feb 2007 10:24:19 -0800 From: Mahesh Jethanandani Organization: Cisco Systems Inc. User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: tcpm@ietf.org DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6326; t=1171391059; x=1172255059; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mahesh@cisco.com; z=From:=20Mahesh=20Jethanandani=20 |Subject:=20New=20I-D |Sender:=20; bh=aJaPi4cnP3VA8ueJRiHV7JRLRVkYA+0qh6U0pQRGcvo=; b=ZMvei88kCDXIoj0xOoGjsQ8z7KDgIWDmcHd2XKNRUh6nGazKGexfycH/4FueP38p3owjzSEm +6CKcTQSgNOgZe4fHomxUWRM/wXK8y+MKQXmFT328OBtWwevAelHaEJ2; Authentication-Results: sj-dkim-6; header.From=mahesh@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Subject: [tcpm] New I-D X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1858995068==" Errors-To: tcpm-bounces@ietf.org This is a multi-part message in MIME format. --===============1858995068== Content-Type: multipart/alternative; boundary="------------040001020502050409040401" This is a multi-part message in MIME format. --------------040001020502050409040401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit A new I-D has been posted on the IETF web site. http://www.ietf.org/internet-drafts/draft-mahesh-persist-timeout-00.txt "TCP Maintenance and Minor Extensions", Mahesh Jethanandani, Murali Bashyam, 9-Feb-07, Comments are welcome. -- *Mahesh Jethanandani* *Technical Leader* **Corporate Development* * mahesh@cisco.com Phone :*+1 408 527-8230* Fax :*+1 408 527-6351* ** 170 West Tasman Drive San Jose, CA 95070 United States www.cisco.com This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message. --------------040001020502050409040401 Content-Type: multipart/related; boundary="------------040206000707000403000206" --------------040206000707000403000206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit A new I-D has been posted on the IETF web site.
http://www.ietf.org/internet-drafts/draft-mahesh-persist-timeout-00.txt
"TCP Maintenance and Minor Extensions", Mahesh Jethanandani, Murali Bashyam, 9-Feb-07, <draft-mahesh-persist-timeout-00.txt>
Comments are welcome.
--

Mahesh Jethanandani
Technical Leader
Corporate Development

mahesh@cisco.com
Phone :+1 408 527-8230
Fax :+1 408 527-6351


170 West Tasman Drive
San Jose, CA 95070
United States
www.cisco.com

  
This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message.


--------------040206000707000403000206 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: R0lGODlhBQAFAJEAAAAAAP///////wAAACH5BAEAAAIALAAAAAAFAAUAAAIElI+pWAA7 --------------040206000707000403000206 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: R0lGODlhHwIBAJEAAAAAAP///9bY2v///yH5BAEAAAMALAAAAAAfAgEAAAIVlI+py+0Po5y0 2ouz3rz7D4biSE4FADs= --------------040206000707000403000206 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: R0lGODlhHwIRAMQAAAAAAP////f3+PX19vHx8u7u7+jp6+Tl59/g4tze4Nvd39ja3NfZ29bY 2vHy8+3u7+vs7eTl5ufp6uTm597g4dze3/j5+fHy8v7+/v39/fv7+/n5+f///wAAAAAAAAAA ACH5BAEAABwALAAAAAAfAhEAAAXY4JIFZGmeaKqubOu+cCzPdG3feK7vfO//wKCwlVkkNsOk cslsOp/QqHRKFW4SE0J1y+16v+CweJwkZCfktHrNbrvf7yymMoDb7/i8fp8fKDABFweAfIWG h4iJijIYBxclBhIai5SVlpeYXhoSBicQDA+ZoqOkpaYuBQwQKRsIERcCp7KztLV2Ag4RCBYs DgcUDcHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX2Nna29zd3twUEQ625OXm5+jp6uvs7e7v8PHy 8/T19vf4+fr7/P3+/wADChxIUEYIADs= --------------040206000707000403000206-- --------------040001020502050409040401-- --===============1858995068== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1858995068==-- From tcpm-bounces@ietf.org Tue Feb 13 13:59:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH2ro-0007WO-DR; Tue, 13 Feb 2007 13:59:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH2rn-0007Tw-7R for tcpm@ietf.org; Tue, 13 Feb 2007 13:59:03 -0500 Received: from mx1.grc.nasa.gov ([128.156.11.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HH2rl-0003P3-Rs for tcpm@ietf.org; Tue, 13 Feb 2007 13:59:03 -0500 Received: from lombok-fi.grc.nasa.gov (seraph.grc.nasa.gov [128.156.10.10]) by mx1.grc.nasa.gov (Postfix) with ESMTP id 6F38EC299 for ; Tue, 13 Feb 2007 13:58:54 -0500 (EST) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l1DIwrwE001455; Tue, 13 Feb 2007 13:58:53 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l1DIwrOw009929; Tue, 13 Feb 2007 13:58:53 -0500 (EST) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id hH77a-Fh9uiQ; Tue, 13 Feb 2007 13:58:52 -0500 (EST) Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123])by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l1DIwmJv009878;Tue, 13 Feb 2007 13:58:48 -0500 (EST) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501)id 8C0F64FE1C; Tue, 13 Feb 2007 13:55:52 -0500 (EST) Date: Tue, 13 Feb 2007 13:55:52 -0500 From: Wesley Eddy To: Mahesh Jethanandani Subject: Re: [tcpm] New I-D Message-ID: <20070213185552.GB7252@grc.nasa.gov> References: <45D20253.70706@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45D20253.70706@cisco.com> User-Agent: Mutt/1.5.5.1i X-imss-version: 2.046 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:2 M:2 S:2 R:2 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Tue, Feb 13, 2007 at 10:24:19AM -0800, Mahesh Jethanandani wrote: > A new I-D has been posted on the IETF web site. > > http://www.ietf.org/internet-drafts/draft-mahesh-persist-timeout-00.txt > "TCP Maintenance and Minor Extensions", Mahesh Jethanandani, Murali > Bashyam, 9-Feb-07, > Comments are welcome. It's good to see the description of the problem you observed along with the solution, but it looks to me like this is more of an OS mechanism to manage resources rather than a protocol-based mechanism. Is this correct? -- Wesley M. Eddy Verizon Federal Network Systems _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Feb 13 15:18:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH46S-0005Cp-CC; Tue, 13 Feb 2007 15:18:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH46R-0005Cj-JX for tcpm@ietf.org; Tue, 13 Feb 2007 15:18:15 -0500 Received: from [2001:770:68:ff::1] (helo=kac.cnri.dit.ie) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HH46Q-0003X1-1h for tcpm@ietf.org; Tue, 13 Feb 2007 15:18:15 -0500 Received: from kac.cnri.dit.ie (localhost.cnri.dit.ie [127.0.0.1]) by kac.cnri.dit.ie (8.13.4/8.13.4) with ESMTP id l1DKHl83029125; Tue, 13 Feb 2007 20:17:47 GMT (envelope-from dwmalone@kac.cnri.dit.ie) Message-Id: <200702132017.l1DKHl83029125@kac.cnri.dit.ie> To: Mahesh Jethanandani Subject: Re: [tcpm] New I-D In-Reply-To: Your message of "Tue, 13 Feb 2007 10:24:19 PST." <45D20253.70706@cisco.com> From: David Malone Date: Tue, 13 Feb 2007 20:17:47 +0000 X-Spam-Score: -2.8 (--) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org > A new I-D has been posted on the IETF web site. > http://www.ietf.org/internet-drafts/draft-mahesh-persist-timeout-00.txt > "TCP Maintenance and Minor Extensions", Mahesh Jethanandani, Murali Bashyam, 9 This idea seems quite closely related to TCP keepalives, though it is addressing a different problem. Do you have any suggestions for a sockets API to these persist timers? The draft spends a lot of time showing that the application cannot deal with the problem. I don't buy all the arguments in this section: for example, an application can usually control the sockbuf sizes and then either user non-blocking writes or timeouts to determine if the application at the other end has gone away or not. I'm not sure how often an application cares if the TCP at the other end is still alive! On the other hand, as pointed out, there are situations where there is no longer any application (data has been handed off to TCP and the application has exited/moved on). In these cases it could be quite hard for an administrator to control the resource usage without something like the timeouts that you describe. I know FreeBSD has had to introduce some facilities for dealing with these sort of resource issues (there is a per-process limit on how many sockbufs can be allocated by a process and there is a "tcpdrop" utility to force a TCP connection to be closed). David. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Feb 13 15:28:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH4GA-0007yI-NZ; Tue, 13 Feb 2007 15:28:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH4G9-0007x7-Uu for tcpm@ietf.org; Tue, 13 Feb 2007 15:28:17 -0500 Received: from web31712.mail.mud.yahoo.com ([68.142.201.192]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HH4G4-0004wT-Kp for tcpm@ietf.org; Tue, 13 Feb 2007 15:28:17 -0500 Received: (qmail 39762 invoked by uid 60001); 13 Feb 2007 20:28:12 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=OTM92Mo9H5vBnmGLtdiW1r099tbJ2NsDdBipR0vZxs3SB/97AosaQzT3GIQHD/kjrXjEGklAVSS9i236Lllk/gHB9fz800qtXDWcq9t3Sv+xQRu94W7f1Je/aAZ6SINKb0awDNExGFFX7jEjAnAn8pxAvKWiasGM+xtYKxH7FJA=; X-YMail-OSG: EUMAEvEVM1litOYVhRUPmPtxxcCsOQcpomOOm_hxmrRxp0cX5u6JdYuMkXrb2r5D.9FiNTmbpI5lx0KhwyGViCIzjoZM9vFDdkb6tyX.CAn.V_4ijxGu.MYD2GGkbKXzoAUc3X9JE0s- Received: from [69.28.107.2] by web31712.mail.mud.yahoo.com via HTTP; Tue, 13 Feb 2007 12:28:11 PST Date: Tue, 13 Feb 2007 12:28:11 -0800 (PST) From: MURALI BASHYAM Subject: Re: [tcpm] New I-D To: weddy@grc.nasa.gov, Mahesh Jethanandani In-Reply-To: <20070213185552.GB7252@grc.nasa.gov> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <953935.38966.qm@web31712.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org It's a TCP protocol and connection state specific solution to the infinite persist state issue. The consequences of not hanndling this issue lead to a resource starvation problem, along with other problems, DDOS etc. Murali --- Wesley Eddy wrote: > On Tue, Feb 13, 2007 at 10:24:19AM -0800, Mahesh > Jethanandani wrote: > > A new I-D has been posted on the IETF web site. > > > > > http://www.ietf.org/internet-drafts/draft-mahesh-persist-timeout-00.txt > > "TCP Maintenance and Minor Extensions", Mahesh > Jethanandani, Murali > > Bashyam, 9-Feb-07, > > > Comments are welcome. > > It's good to see the description of the problem you > observed along with > the solution, but it looks to me like this is more > of an OS mechanism to > manage resources rather than a protocol-based > mechanism. Is this > correct? > > -- > Wesley M. Eddy > Verizon Federal Network Systems > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm > ____________________________________________________________________________________ Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Feb 14 00:15:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHCSM-0004gS-3o; Wed, 14 Feb 2007 00:13:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHCSL-0004gN-2z for tcpm@ietf.org; Wed, 14 Feb 2007 00:13:25 -0500 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 1HHCSG-0006sL-K5 for tcpm@ietf.org; Wed, 14 Feb 2007 00:13:25 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 13 Feb 2007 21:13:20 -0800 X-IronPort-AV: i="4.14,167,1170662400"; d="scan'208"; a="762814025:sNHT167929134" 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/8.12.11) with ESMTP id l1E5DJSf004842; Tue, 13 Feb 2007 21:13:19 -0800 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 l1E5DIUw029386; Tue, 13 Feb 2007 21:13:18 -0800 (PST) Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Feb 2007 21:13:18 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] rfc2581bis [2]: limiting cwnd inflation Date: Tue, 13 Feb 2007 21:13:13 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC5802DE65F3@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <20070213150347.D2A7A17ABD4@lawyers.icir.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] rfc2581bis [2]: limiting cwnd inflation thread-index: AcdPgNS5TiMWicdXSxeAhZUi0PBTqAAcTtFg From: "Anantha Ramaiah \(ananth\)" To: , X-OriginalArrivalTime: 14 Feb 2007 05:13:18.0842 (UTC) FILETIME=[D6D8A5A0:01C74FF6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3854; t=1171429999; x=1172293999; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20\(ananth\)=22=20 |Subject:=20RE=3A=20[tcpm]=20rfc2581bis=20[2]=3A=20limiting=20cwnd=20infl ation |Sender:=20; bh=dtKdWnYEYYuo/vgbk8iPcdHWZ6PdTnH3MpgWQz1t1g4=; b=cmK+x9jTwYGZDsIs3bwWMGdKidbyVUJCsmOU1aSmzyF9RPoZsAB3VPmg/FMva6sV/y9J2Z03 kzOCGpqaodu+ML7PBd2YaFdoYF8fQlI4+wOBVtKia/lvoPFEur4e++Zc; Authentication-Results: sj-dkim-3; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org I was having some private email discussions with Mark when the previous version was released, basically talking about limiting the artifical cwnd inflation during fast recovery. Now, the following text which is added in the new version of this draft talks about the mis-behaving receivers only. What I had in mind was about in general (whether or not the receiver is mis-behaving, this applies). To illustrate this :- Assume that flightsize =3D f during fast recovery. Assume f > 2 SMSS When the 3rd duplicate Ack arrives,=20 ssthresh =3D max (FlightSize / 2, 2*SMSS) Ssthresh =3D max ( f/2, 2*smss) =3D f/2. Now cwnd =3D f/2 + 3*SMSS For each duplicate ACK which arrives after that (assuming that the first segment got dropped) *in theory* you could get 6 duplicate ACK's [This is NOT a mis-behaving receiver] Since every out-of-order segment ought to be ACKED immediatley and shouldn't be delayed. So we would have incremented the cwnd by :- Cwnd =3D (f/2 + 3*SMSS) + 6SMSS > f. This can happen since there seems to be no explicit rule to cap the cwnd growth which may cause the higher than appropriate sending rate to be used. To make the above example assuming f =3D 10 before fast recovery entered, we would be in a = situation where cwnd becomes 14!!, which is un-desirable. So I would think the text needs to be more generic something like :-=20 "Note: Since, in theory, the cwnd can get artifically inflated to a value greater than what it was before the fast recovery procedure was entered, a TCP MAY limit the number of times cwnd is artificially inflated during loss recovery to the number of outstanding segments (or, an approximation thereof). Also this helps in dealing with receiver-based attack wherby many bogus duplicate ACKS are sent to the data sender in order to artifically inflate the cwnd and cause higher than appropriate sending rate to be used." Mark suggested that I send this to the wider audience to see if there is some general consensus on this. -Anantha > -----Original Message----- > From: Mark Allman [mailto:mallman@icir.org]=20 > Sent: Tuesday, February 13, 2007 7:04 AM > To: tcpm@ietf.org > Subject: [tcpm] rfc2581bis [2]: limiting cwnd inflation >=20 > =20 > Reminder, the draft should pop out of the usual places soon,=20 > but until then you can slurp a copy from: >=20 > =20 > http://www.icir.org/mallman/papers/draft-ietf-tcpm-rfc2581bis-02.txt >=20 > The second issue ... >=20 > We added a note to step 4 of the fast retransmit/recovery procedure: >=20 > 4. For each additional duplicate ACK received (after the third), > cwnd MUST be incremented by SMSS. This artificially inflates > the congestion window in order to reflect the=20 > additional segment > that has left the network. > =20 > Note: [SCWA99] discusses a receiver-based attack whereby many > bogus duplicate ACKs are sent to the data sender in order to > artificially inflate cwnd and cause a higher than appropriate > sending rate to be used. A TCP MAY therefore limit the number > of times cwnd is artificially inflated during loss recovery > to the number of outstanding segments (or, an approximation > thereof).=20 >=20 > That is, we explicitly allow a TCP to limit the number of=20 > dupacks that are acceptable during fast recovery to prevent=20 > an attack such as discussed in [SCWA99]. >=20 > Note that (1) this is more conservative than the algorithm in=20 > 2581 and so implicitly allowed already (that is, we are just=20 > calling attention to > this) and (2) we are not trying to mandate this behavior,=20 > just noting that it might be useful. >=20 > Comments would be appreciated. >=20 > Thanks, > allman >=20 >=20 >=20 >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Feb 14 00:36:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHCoc-000051-31; Wed, 14 Feb 2007 00:36:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHCoa-00004r-TM for tcpm@ietf.org; Wed, 14 Feb 2007 00:36:24 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHCoZ-00026p-Hp for tcpm@ietf.org; Wed, 14 Feb 2007 00:36:24 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l1E5aMTc030174; Tue, 13 Feb 2007 21:36:22 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id EADEC7B50F8; Wed, 14 Feb 2007 00:36:16 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 3A28317BD87; Wed, 14 Feb 2007 00:36:05 -0500 (EST) To: "Anantha Ramaiah (ananth)" From: Mark Allman Subject: Re: [tcpm] rfc2581bis [2]: limiting cwnd inflation In-Reply-To: <0C53DCFB700D144284A584F54711EC5802DE65F3@xmb-sjc-21c.amer.cisco.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Whole Lotta Love MIME-Version: 1.0 Date: Wed, 14 Feb 2007 00:36:05 -0500 Message-Id: <20070214053605.3A28317BD87@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0420079935==" Errors-To: tcpm-bounces@ietf.org --===============0420079935== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > Cwnd = (f/2 + 3*SMSS) + 6SMSS > f. This can happen since there seems > to be no explicit rule to cap the cwnd growth which may cause the higher > than appropriate sending rate to be used. To make the above example > assuming f = 10 before fast recovery entered, we would be in a situation > where cwnd becomes 14!!, which is un-desirable. It is not. After out iteration earlier today I went through this in more detail in my head. You want cwnd to grow past where it was before recovery. That is how you're able to strobe new segments out. Simple example: FlightSize=40 lose 1 segment; expect 39 dupacks (say none are lost) after the 3rd dupack: cwnd = (FlightSize / 2) + 3 = 23 ssthresh = FlightSize / 2 = 20 retransmit receiver 36 more dupacks, on each: cwnd += 1 if FlightSize < cwnd: transmit FlightSize += 1 receive an ACK for everything cwnd = ssthresh So, basically before the rexmt is ACKed cwnd will be 59 segments---or, 19 more than it was before the loss happened. But, this increase is termed *artificial*. We did not put 59 segments into the network during the last RTT, we put 19 segments into the network (or, half of the FlightSize when the loss occured)---so, we did in fact halve our rate even though the cwnd is larger. Before continuing the cwnd collapses back to what it ought to be (20 segments in this case). What the new text is attempting to do is to allow stacks to protect against malicious receivers that strobe many more dupacks into the stream to boost the sending rate. Regardless of the value of cwnd, I don't think there is a case whereby you'll be actually putting an inappropriate number of segments into the network when things are working properly. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFF0p/EWyrrWs4yIs4RAsgyAJ4vqYjonciG4BalnNgbl/diVsxYTQCfQCj3 Nkpc3B09hGD4TCT/hGXtqc8= =Bk68 -----END PGP SIGNATURE----- --=_bOundary-- --===============0420079935== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0420079935==-- From tcpm-bounces@ietf.org Wed Feb 14 02:37:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHEgs-0002iK-VF; Wed, 14 Feb 2007 02:36:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHEgr-0002Zl-Dw for tcpm@ietf.org; Wed, 14 Feb 2007 02:36:33 -0500 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHEgP-0002ie-JG for tcpm@ietf.org; Wed, 14 Feb 2007 02:36:06 -0500 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id CA326F0C417 for ; Wed, 14 Feb 2007 04:35:27 -0300 (ART) Received: from fgont.gont.com.ar (3-176-231-201.fibertel.com.ar [201.231.176.3]) (authenticated bits=0) by venus.xmundo.net (8.12.11.20060308/8.12.11) with ESMTP id l1E7ZOPZ017707 for ; Wed, 14 Feb 2007 04:35:25 -0300 Message-Id: <200702140735.l1E7ZOPZ017707@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 14 Feb 2007 04:35:19 -0300 To: tcpm@ietf.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Wed, 14 Feb 2007 04:35:26 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [tcpm] Some comments on 2581bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Mark, Some comments on the draft: ** RFC 2581 & SACK Page 3 says: Alternatively, a TCP that utilizes selective acknowledgments [RFC2018,RFC2883] can determine an incoming ACK is a "duplicate" if the ACK contains previously unknown SACK information. And page 7 says: Note that a sender using SACK [RFC2018] MUST NOT send new data unless the incoming duplicate acknowledgment contains new SACK information. IMHO, if you keep the "MUST NOT" in page 7, you'd probably s/can/MUST/ in page 3. Also, maybe it would be worth to clarify that the SACK information should be "in window"? ** Limits on dupacks Would it make sense to limit the number of accepted dupacks to Max_dupacks = (Flight_size_fr - 1) / SMSS ? where Flight_size_fr is the Flight_Size at the point fast retransmit is triggered. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Feb 14 02:50:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHEuW-0002uG-Cg; Wed, 14 Feb 2007 02:50:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHEuV-0002uB-EC for tcpm@ietf.org; Wed, 14 Feb 2007 02:50:39 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHEuS-0005xO-Vi for tcpm@ietf.org; Wed, 14 Feb 2007 02:50:39 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 13 Feb 2007 23:50:36 -0800 X-IronPort-AV: i="4.14,167,1170662400"; d="scan'208"; a="464378019:sNHT51487352" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1E7oaUp008994; Tue, 13 Feb 2007 23:50:36 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l1E7oaGk019793; Tue, 13 Feb 2007 23:50:36 -0800 (PST) Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Feb 2007 23:50:36 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] rfc2581bis [2]: limiting cwnd inflation Date: Tue, 13 Feb 2007 23:50:34 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC5802DE6625@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <20070214053605.3A28317BD87@lawyers.icir.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] rfc2581bis [2]: limiting cwnd inflation thread-index: AcdP+hBSA0XIhBlSR3eM5ft/B17VRAAAIfOg From: "Anantha Ramaiah \(ananth\)" To: X-OriginalArrivalTime: 14 Feb 2007 07:50:36.0040 (UTC) FILETIME=[CFDAC880:01C7500C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3802; t=1171439436; x=1172303436; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20\(ananth\)=22=20 |Subject:=20RE=3A=20[tcpm]=20rfc2581bis=20[2]=3A=20limiting=20cwnd=20infl ation=20 |Sender:=20 |To:=20 |Content-Type:=20text/plain=3B=0A=09charset=3D=22us-ascii=22 |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=uCy89Ks1Mbpupg7tLW8Qwxhb5fMDc2SkcXGSlY/qK1o=; b=DjCc/xXJuUZ0K8V5Ik6phQAOZs1BO1wnPi+HevGb0XGzSKGcsWve9YdQdbWQrzWG7zmow/jm S5r6RL128pyvdsnsW8r98ZIifijuW4qre34GURZ48ruA7pwTplQIXGryE02zFNv0CyLyzaTK7c Gx83nYnqawZLYhwsaUQ03anaA=; Authentication-Results: sj-dkim-1; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org =20 > -----Original Message----- > From: mallman@icir.org [mailto:mallman@icir.org]=20 > Sent: Tuesday, February 13, 2007 9:36 PM > To: Anantha Ramaiah (ananth) > Cc: tcpm@ietf.org > Subject: Re: [tcpm] rfc2581bis [2]: limiting cwnd inflation=20 >=20 > > Cwnd =3D (f/2 + 3*SMSS) + 6SMSS > f. This can happen since=20 > there seems=20 > > to be no explicit rule to cap the cwnd growth which may cause the=20 > > higher than appropriate sending rate to be used. To make the above=20 > > example assuming f =3D 10 before fast recovery entered, we=20 > would be in a=20 > > situation where cwnd becomes 14!!, which is un-desirable. >=20 > It is not. After out iteration earlier today I went through=20 > this in more detail in my head. You want cwnd to grow past=20 > where it was before recovery. That is how you're able to=20 > strobe new segments out. Simple > example: >=20 > FlightSize=3D40 > lose 1 segment; expect 39 dupacks (say none are lost) after=20 > the 3rd dupack: > cwnd =3D (FlightSize / 2) + 3 =3D 23 > ssthresh =3D FlightSize / 2 =3D 20 > retransmit > receiver 36 more dupacks, on each: > cwnd +=3D 1 > if FlightSize < cwnd: > transmit > FlightSize +=3D 1 > receive an ACK for everything > cwnd =3D ssthresh >=20 > So, basically before the rexmt is ACKed cwnd will be 59 segments---or, > 19 more than it was before the loss happened. But, this=20 > increase is termed *artificial*. We did not put 59 segments=20 > into the network during the last RTT, we put 19 segments into=20 > the network (or, half of the FlightSize when the loss=20 > occured)---so, we did in fact halve our rate even though the=20 > cwnd is larger. Before continuing the cwnd collapses back to=20 > what it ought to be (20 segments in this case). Ok, you are right on this, Mark. Basically the cwnd can grow up to a maximum of (3f-2)/2 during fast recovery [ f denotes the flightsize before entering FR]. Due to some interrmitent re-ordering in the network, we could construct scenarios like below :- Assume 40 segments sent out (f =3D 40), 1st segment got dropped. [same example as above] We get, lets say, 11 acks which fills the hole, which makes cwnd =3D 31 (20+11), f =3D 29(40 -11), after we still have remaining 28 acks, which can slide the window one segment at a time [I am assuming that the fast-retransmitted segment "overtook" the 28 segments . Of course I am assuming some genuine networking scenarios like load balancing scenarios/network conditions which causes some irregular ACK pattern which can cause more than needed segments to be sent out. [ "needed segments" =3D f/2 =3D 20 when we entered fast recovery] Anyways, it appears that I may be trying hard to convince you on this, but bottomline is we can construct scenarios. >=20 > What the new text is attempting to do is to allow stacks to=20 > protect against malicious receivers that strobe many more=20 > dupacks into the stream to boost the sending rate. =20 Sure there is no issue with the existing text, but I was trying to make it more generic. Also it is not just mis-behaving receivers, another reason which I can think of is some intermittent packet duplication can cause this as well. > Regardless of the value of cwnd, I don't think there is a=20 > case whereby you'll be actually putting an inappropriate=20 > number of segments into the network when things are working properly. Hmm.. This is what I am not too sure about, my loose example above tries to demonstrate this. But in many real life scenarios partial ack's are common which kicks in New Reno which has protection against window deflation anyways since the cwnd gets reduced further.. May be it isn't as worst as I think, I don't know. -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Feb 14 03:01:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHF5M-0000a4-29; Wed, 14 Feb 2007 03:01:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHF5J-0000Zl-VN for tcpm@ietf.org; Wed, 14 Feb 2007 03:01:49 -0500 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHF5I-000051-Hj for tcpm@ietf.org; Wed, 14 Feb 2007 03:01:49 -0500 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id D8AC9F0C417; Wed, 14 Feb 2007 05:01:47 -0300 (ART) Received: from fgont.gont.com.ar (3-176-231-201.fibertel.com.ar [201.231.176.3]) (authenticated bits=0) by venus.xmundo.net (8.12.11.20060308/8.12.11) with ESMTP id l1E81fPQ019857; Wed, 14 Feb 2007 05:01:45 -0300 Message-Id: <200702140801.l1E81fPQ019857@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 14 Feb 2007 05:01:31 -0300 To: Mahesh Jethanandani From: Fernando Gont Subject: Re: [tcpm] New I-D (draft-mahesh-persist-timeout-00.txt) In-Reply-To: <45D20253.70706@cisco.com> References: <45D20253.70706@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Wed, 14 Feb 2007 05:01:46 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 03:24 p.m. 13/02/2007, you wrote: Comments inline.... >A new I-D has been posted on the IETF web site. > >http://www.ietf.org/internet-drafts/draft-mahesh-persist-timeout-00.txt >"TCP Maintenance and Minor Extensions", Mahesh Jethanandani, Murali >Bashyam, 9-Feb-07, Comments are welcome. What if I advertise a window of 1, instead? Or, what if I advertise a window of zero, then before you abort the connection I advertise a window of a few bytes, and then I go back to advertising a window of zero (and so on)? I think it is interesting to find a workaround for this type of resource exhaustion attack (as well as for Netkill, etc.). However, I think the heuristics will need to be more complex. If not, it will be easy (and cheap) for the attacker to fool the proposed counter-measures. (the examples above are some possible ways to do so). Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Feb 14 03:14:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHFHR-0001QV-FW; Wed, 14 Feb 2007 03:14:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHFHP-0001QG-RE for tcpm@ietf.org; Wed, 14 Feb 2007 03:14:19 -0500 Received: from web31708.mail.mud.yahoo.com ([68.142.201.188]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HHFHO-0003Mc-GI for tcpm@ietf.org; Wed, 14 Feb 2007 03:14:19 -0500 Received: (qmail 1904 invoked by uid 60001); 14 Feb 2007 08:14:17 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=Behm2+s3NJQWc+O6xbsRam522ACq0kQ2RLa7eW7662e7a5R9ZkbSyUirtbSU8mmySHmARAJ6vru7nTcXc26T4mc6rSl2/65MlYXDWAxoFwTBWCDZWRwhgR+owTcpbDJkgF3T55t4b0Zi7R1jtCU6wBKsf7rHyZQxODNMjYkxORY=; X-YMail-OSG: 5VYYax8VM1ly8j65Cl0aZkCdDdEM_X1xldD0K6sulqPcy9pWO.WnAwyabWa4fq5xs4B5wrUK6qJlQ3exw2V8aTAxZZhVnpHudF6SzxP_yya2Lral.jw10Sz01oQB58KteuGSromqY4c- Received: from [24.6.27.26] by web31708.mail.mud.yahoo.com via HTTP; Wed, 14 Feb 2007 00:14:17 PST Date: Wed, 14 Feb 2007 00:14:17 -0800 (PST) From: MURALI BASHYAM Subject: Re: [tcpm] New I-D (draft-mahesh-persist-timeout-00.txt) To: Fernando Gont , Mahesh Jethanandani In-Reply-To: <200702140801.l1E81fPQ019857@venus.xmundo.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <864148.91659.qm@web31708.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Good point. This particular behaviour can be detected quite easily when compared to a well-behaved receiver. A well-behaved TCP receiver will do receive side silly window avoidance, and would only advertise a window increase when at least a MSS worth of buffer space is available (typically). Murali --- Fernando Gont wrote: > At 03:24 p.m. 13/02/2007, you wrote: > > Comments inline.... > > > >A new I-D has been posted on the IETF web site. > > > >http://www.ietf.org/internet-drafts/draft-mahesh-persist-timeout-00.txt > >"TCP Maintenance and Minor Extensions", Mahesh > Jethanandani, Murali > >Bashyam, 9-Feb-07, > Comments are > welcome. > > What if I advertise a window of 1, instead? > > Or, what if I advertise a window of zero, then > before you abort the > connection I advertise a window of a few bytes, and > then I go back to > advertising a window of zero (and so on)? > > I think it is interesting to find a workaround for > this type of > resource exhaustion attack (as well as for Netkill, > etc.). > > However, I think the heuristics will need to be more > complex. If not, > it will be easy (and cheap) for the attacker to fool > the proposed > counter-measures. (the examples above are some > possible ways to do so). > > Kindest regards, > > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE > A9EF D076 FFF1 > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm > ____________________________________________________________________________________ 8:00? 8:25? 8:40? Find a flick in no time with the Yahoo! Search movie showtime shortcut. http://tools.search.yahoo.com/shortcuts/#news _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Feb 14 03:40:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHFfg-0006f7-Bt; Wed, 14 Feb 2007 03:39:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHFfe-0006bz-50 for tcpm@ietf.org; Wed, 14 Feb 2007 03:39:22 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHFcR-0008K2-0d for tcpm@ietf.org; Wed, 14 Feb 2007 03:36:05 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 14 Feb 2007 00:36:02 -0800 X-IronPort-AV: i="4.14,168,1170662400"; d="scan'208"; a="388941333:sNHT50682768" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l1E8a2VW022646; Wed, 14 Feb 2007 00:36:02 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l1E8a2nF017727; Wed, 14 Feb 2007 00:36:02 -0800 (PST) Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Feb 2007 00:36:01 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] New I-D (draft-mahesh-persist-timeout-00.txt) Date: Wed, 14 Feb 2007 00:35:59 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC5802DE662B@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <864148.91659.qm@web31708.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] New I-D (draft-mahesh-persist-timeout-00.txt) thread-index: AcdQEDHPwT2+UHqxSCONUwpnoe6QIQAAhtJg From: "Anantha Ramaiah \(ananth\)" To: "MURALI BASHYAM" , "Fernando Gont" , "Mahesh Jethanandani \(mahesh\)" X-OriginalArrivalTime: 14 Feb 2007 08:36:01.0990 (UTC) FILETIME=[28A5BE60:01C75013] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2885; t=1171442162; x=1172306162; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20\(ananth\)=22=20 |Subject:=20RE=3A=20[tcpm]=20New=20I-D=20(draft-mahesh-persist-timeout-00 .txt) |Sender:=20; bh=7XV89WwsTX/Ozez47pj8jVu8Q88I6YU2alX3hfiX9IY=; b=T/riDaC6gjuNAEsW+bmPh99qV8xtUXDszyd/9Kc1THAkGDJlKdE+SzISq8LpHl1iiazKAkxX tYUdnrj9x6U6yo/6CWsdRR4Z/5ch6ZmQ4sbWyHZbadK3/Hm2oSMaoYr8; Authentication-Results: sj-dkim-6; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Yep, on a related note, some TCP stacks shrink windows, window shrinking is used as a convenience tool in some cases :-) We probably need to deal with such cases as well, since the robustness principle allows it. -Anantha=20 > -----Original Message----- > From: MURALI BASHYAM [mailto:murali_bashyam@yahoo.com]=20 > Sent: Wednesday, February 14, 2007 12:14 AM > To: Fernando Gont; Mahesh Jethanandani (mahesh) > Cc: tcpm@ietf.org > Subject: Re: [tcpm] New I-D (draft-mahesh-persist-timeout-00.txt) >=20 > Good point. >=20 > This particular behaviour can be detected quite easily when=20 > compared to a well-behaved receiver. A well-behaved TCP=20 > receiver will do receive side silly window avoidance, and=20 > would only advertise a window increase when at least a MSS=20 > worth of buffer space is available (typically).=20 >=20 > Murali >=20 > --- Fernando Gont wrote: >=20 > > At 03:24 p.m. 13/02/2007, you wrote: > >=20 > > Comments inline.... > >=20 > >=20 > > >A new I-D has been posted on the IETF web site. > > > > > > > eout-00.tx > >t>http://www.ietf.org/internet-drafts/draft-mahesh-persist-ti > meout-00.t > >xt > > >"TCP Maintenance and Minor Extensions", Mahesh > > Jethanandani, Murali > > >Bashyam, 9-Feb-07, > > Comments are welcome. > >=20 > > What if I advertise a window of 1, instead? > >=20 > > Or, what if I advertise a window of zero, then before you abort the=20 > > connection I advertise a window of a few bytes, and then I=20 > go back to=20 > > advertising a window of zero (and so on)? > >=20 > > I think it is interesting to find a workaround for this type of=20 > > resource exhaustion attack (as well as for Netkill, etc.). > >=20 > > However, I think the heuristics will need to be more=20 > complex. If not,=20 > > it will be easy (and cheap) for the attacker to fool the proposed=20 > > counter-measures. (the examples above are some possible ways to do=20 > > so). > >=20 > > Kindest regards, > >=20 > > -- > > Fernando Gont > > e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809=20 > > 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > >=20 > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www1.ietf.org/mailman/listinfo/tcpm > >=20 >=20 >=20 >=20 > =20 > ______________________________________________________________ > ______________________ > 8:00? 8:25? 8:40? Find a flick in no time with the Yahoo!=20 > Search movie showtime shortcut. > http://tools.search.yahoo.com/shortcuts/#news >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Feb 14 03:59:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHFyg-0003PT-TB; Wed, 14 Feb 2007 03:59:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHFye-0003PJ-Ri for tcpm@ietf.org; Wed, 14 Feb 2007 03:59:00 -0500 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHFyc-00049t-8q for tcpm@ietf.org; Wed, 14 Feb 2007 03:59:00 -0500 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 65352F0C585; Wed, 14 Feb 2007 05:58:29 -0300 (ART) Received: from fgont.gont.com.ar (3-176-231-201.fibertel.com.ar [201.231.176.3]) (authenticated bits=0) by venus.xmundo.net (8.12.11.20060308/8.12.11) with ESMTP id l1E8wPtH031928; Wed, 14 Feb 2007 05:58:27 -0300 Message-Id: <200702140858.l1E8wPtH031928@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 14 Feb 2007 05:58:19 -0300 To: "Anantha Ramaiah \(ananth\)" , "MURALI BASHYAM" , "Mahesh Jethanandani \(mahesh\)" From: Fernando Gont Subject: RE: [tcpm] New I-D (draft-mahesh-persist-timeout-00.txt) In-Reply-To: <0C53DCFB700D144284A584F54711EC5802DE662B@xmb-sjc-21c.amer. cisco.com> References: <864148.91659.qm@web31708.mail.mud.yahoo.com> <0C53DCFB700D144284A584F54711EC5802DE662B@xmb-sjc-21c.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Wed, 14 Feb 2007 05:58:28 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 05:35 a.m. 14/02/2007, Anantha Ramaiah \(ananth\) wrote: >Yep, on a related note, some TCP stacks shrink windows, window shrinking >is used as a convenience tool in some cases :-) We probably need to deal >with such cases as well, since the robustness principle allows it. The amount of data queued for transmission, is another factor worth considering in the heuristics, as for DoS attacks there will usually be a large amount of queued data (send buffer full, or close to). Also, if the corresponding socket has been close()ed by the application running at the TCP sender, the application will usually have no control on the socket anymore (unless the SO_LINGER (?) socket option was set?). This may be worth noting in the doc, too. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Feb 14 09:05:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHKkP-0005fz-5T; Wed, 14 Feb 2007 09:04:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHKkN-0005fn-Dh for tcpm@ietf.org; Wed, 14 Feb 2007 09:04:35 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHKkM-0000NB-1n for tcpm@ietf.org; Wed, 14 Feb 2007 09:04:35 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l1EE4UU9009745; Wed, 14 Feb 2007 06:04:31 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 746A77B8573; Wed, 14 Feb 2007 09:04:25 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 4CDD817BF90; Wed, 14 Feb 2007 09:04:13 -0500 (EST) To: "Anantha Ramaiah (ananth)" From: Mark Allman Subject: Re: [tcpm] rfc2581bis [2]: limiting cwnd inflation In-Reply-To: <0C53DCFB700D144284A584F54711EC5802DE6625@xmb-sjc-21c.amer.cisco.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Whole Lotta Love MIME-Version: 1.0 Date: Wed, 14 Feb 2007 09:04:13 -0500 Message-Id: <20070214140413.4CDD817BF90@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0084866067==" Errors-To: tcpm-bounces@ietf.org --===============0084866067== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > Assume 40 segments sent out (f = 40), 1st segment got dropped. [same > example as above] > We get, lets say, 11 acks which fills the hole, which makes cwnd = 31 > (20+11), f = 29(40 -11), after we still have remaining 28 acks, which > can slide the window one segment at a time [I am assuming that the > fast-retransmitted segment "overtook" the 28 segments . Of course I am > assuming some genuine networking scenarios like load balancing > scenarios/network conditions which causes some irregular ACK pattern > which can cause more than needed segments to be sent out. [ "needed > segments" = f/2 = 20 when we entered fast recovery] I don't understand this. As soon as the window slides we are out of fast recovery, the cwnd collapses back down and we go to congestion avoidance to govern sending instead of the fast recovery rules. How does the above lead us to sending inappropriately. > Also it is not just mis-behaving receivers, another reason which I can > think of is some intermittent packet duplication can cause this as > well. Yep. And, I willing to add a parenthetical or something about this point. But, for this to be a problem you'd have to have a *lot* of duplication (which runs against all the evidence about that phenomenon that I have seen). I.e., I am not worried about a couple extra dupacks throwing us off a little. The concern here is that mis-behavior can cause many times more segments than appropriate to be sent. > > Regardless of the value of cwnd, I don't think there is a case > > whereby you'll be actually putting an inappropriate number of > > segments into the network when things are working properly. > > Hmm.. This is what I am not too sure about, Show us how. (I am not saying there is not a scenario. I just haven't yet seen a scenario that would cause a big problem in the absence of a mis-behaving receiver. (Or, a very very flawed network element that is duplicating packets like nobody's business.)) allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFF0xbdWyrrWs4yIs4RAtk+AJ9pLgEg/mVkE49HP0D0RGf2abtjTgCglW9r aCChk+Gy22+BhNQWSGvYveo= =Axel -----END PGP SIGNATURE----- --=_bOundary-- --===============0084866067== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0084866067==-- From tcpm-bounces@ietf.org Wed Feb 14 10:07:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHLht-0002em-7p; Wed, 14 Feb 2007 10:06:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHLhq-0002ci-52 for tcpm@ietf.org; Wed, 14 Feb 2007 10:06:02 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHLhn-0008Nf-OW for tcpm@ietf.org; Wed, 14 Feb 2007 10:06:02 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l1EF5u6d011143; Wed, 14 Feb 2007 07:05:56 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id BADEE7B89CF; Wed, 14 Feb 2007 10:05:50 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 9C4E217C0F8; Wed, 14 Feb 2007 10:05:38 -0500 (EST) To: Fernando Gont From: Mark Allman Subject: Re: [tcpm] Some comments on 2581bis In-Reply-To: <200702140735.l1E7ZOPZ017707@venus.xmundo.net> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Whole Lotta Love MIME-Version: 1.0 Date: Wed, 14 Feb 2007 10:05:38 -0500 Message-Id: <20070214150538.9C4E217C0F8@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2060293297==" Errors-To: tcpm-bounces@ietf.org --===============2060293297== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > ** RFC 2581 & SACK > Page 3 says: > Alternatively, a TCP that utilizes selective acknowledgments > [RFC2018,RFC2883] can determine an incoming ACK is a "duplicate" > if the ACK contains previously unknown SACK information. > > And page 7 says: > Note that a sender using SACK [RFC2018] > MUST NOT send new data unless the incoming duplicate > acknowledgment contains new SACK information. > > IMHO, if you keep the "MUST NOT" in page 7, you'd probably > s/can/MUST/ in page 3. Also, maybe it would be worth to clarify that > the SACK information should be "in window"? Well, duplicate ACKs in 2581 are not always to send out new data. That said, I am wondering if we should just nuke the sentence you quote above. This document does not deal with SACK-based loss recovery and if you have SACK then you should be doing something smarter than this document. And, so maybe we don't need to really define things about SACK-based loss recovery in here. Certainly, I don't think we want to get into whether SACK blocks that this document doesn't use at all are in window or not. > ** Limits on dupacks > Would it make sense to limit the number of accepted dupacks to > Max_dupacks = (Flight_size_fr - 1) / SMSS ? > where Flight_size_fr is the Flight_Size at the point fast retransmit > is triggered. I'd like to hear what people think on this notion. The intent in putting the new text in was not to tightly specify a mechanism, but to note that there is good reason to put some sort of limit on things. How that is done does not seem important to me. (*If* it is done only seems marginally helpful to me.) I.e., one could envision a cwnd limit or trying (because we don't keep track in some stacks) to track the number of packets vs. dupacks as above or ... I guess I would rather leave it as sort-of fuzzy guidance and not mechanism or just drop it as new functionality that is out of scope for the revision. What do folks think? allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFF0yVCWyrrWs4yIs4RAtvKAJ9Gv6GHLEKN/e4vOna64mufbMn84QCfZLwU LJ+1QssI3jogDvootx+FH8o= =CozI -----END PGP SIGNATURE----- --=_bOundary-- --===============2060293297== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============2060293297==-- From tcpm-bounces@ietf.org Wed Feb 14 11:02:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHMaP-0007xe-Do; Wed, 14 Feb 2007 11:02:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHMaN-0007un-QV for tcpm@ietf.org; Wed, 14 Feb 2007 11:02:23 -0500 Received: from mailer2.psc.edu ([128.182.66.106]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHMaM-0007Jh-It for tcpm@ietf.org; Wed, 14 Feb 2007 11:02:23 -0500 Received: from [192.168.2.101] (pool-72-77-100-169.pitbpa.east.verizon.net [72.77.100.169]) (authenticated bits=0) by mailer2.psc.edu (8.13.8/8.13.3) with ESMTP id l1EG2Fia029635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Feb 2007 11:02:16 -0500 (EST) Message-ID: <45D33281.6000803@psc.edu> Date: Wed, 14 Feb 2007 11:02:09 -0500 From: John Heffner User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: mallman@icir.org Subject: Re: [tcpm] Some comments on 2581bis References: <20070214150538.9C4E217C0F8@lawyers.icir.org> In-Reply-To: <20070214150538.9C4E217C0F8@lawyers.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: tcpm@ietf.org, Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Mark Allman wrote: >> ** RFC 2581 & SACK >> Page 3 says: >> Alternatively, a TCP that utilizes selective acknowledgments >> [RFC2018,RFC2883] can determine an incoming ACK is a "duplicate" >> if the ACK contains previously unknown SACK information. >> >> And page 7 says: >> Note that a sender using SACK [RFC2018] >> MUST NOT send new data unless the incoming duplicate >> acknowledgment contains new SACK information. >> >> IMHO, if you keep the "MUST NOT" in page 7, you'd probably >> s/can/MUST/ in page 3. Also, maybe it would be worth to clarify that >> the SACK information should be "in window"? > > Well, duplicate ACKs in 2581 are not always to send out new data. > > That said, I am wondering if we should just nuke the sentence you quote > above. This document does not deal with SACK-based loss recovery and if > you have SACK then you should be doing something smarter than this > document. And, so maybe we don't need to really define things about > SACK-based loss recovery in here. Certainly, I don't think we want to > get into whether SACK blocks that this document doesn't use at all are > in window or not. The notion of the sender "using" SACK is a bit fuzzy anyway, since some stacks will send the options but not process them in any meaningful way (writing scoreboard code is hard). -John _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Feb 14 11:37:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHN7C-0001Sx-9X; Wed, 14 Feb 2007 11:36:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHN7B-0001Sd-DA for tcpm@ietf.org; Wed, 14 Feb 2007 11:36:17 -0500 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHN79-000448-PI for tcpm@ietf.org; Wed, 14 Feb 2007 11:36:17 -0500 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 55887F0C407; Wed, 14 Feb 2007 13:36:17 -0300 (ART) Received: from fgont.gont.com.ar (3-176-231-201.fibertel.com.ar [201.231.176.3]) (authenticated bits=0) by venus.xmundo.net (8.12.11.20060308/8.12.11) with ESMTP id l1EGaDKS022982; Wed, 14 Feb 2007 13:36:14 -0300 Message-Id: <200702141636.l1EGaDKS022982@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 14 Feb 2007 13:36:04 -0300 To: mallman@icir.org From: Fernando Gont Subject: Re: [tcpm] Some comments on 2581bis In-Reply-To: <20070214150538.9C4E217C0F8@lawyers.icir.org> References: <200702140735.l1E7ZOPZ017707@venus.xmundo.net> <20070214150538.9C4E217C0F8@lawyers.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Wed, 14 Feb 2007 13:36:16 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 12:05 p.m. 14/02/2007, Mark Allman wrote: > > ** RFC 2581 & SACK > > Page 3 says: > > Alternatively, a TCP that utilizes selective acknowledgments > > [RFC2018,RFC2883] can determine an incoming ACK is a "duplicate" > > if the ACK contains previously unknown SACK information. > > > > And page 7 says: > > Note that a sender using SACK [RFC2018] > > MUST NOT send new data unless the incoming duplicate > > acknowledgment contains new SACK information. > > > > IMHO, if you keep the "MUST NOT" in page 7, you'd probably > > s/can/MUST/ in page 3. Also, maybe it would be worth to clarify that > > the SACK information should be "in window"? > >Well, duplicate ACKs in 2581 are not always to send out new data. My point is: if you disregard "dupacks" that don't have new sack information for sending new data, why would you let them trigger loss recovery? >That said, I am wondering if we should just nuke the sentence you quote >above. This document does not deal with SACK-based loss recovery and if >you have SACK then you should be doing something smarter than this >document. And, so maybe we don't need to really define things about >SACK-based loss recovery in here. Certainly, I don't think we want to >get into whether SACK blocks that this document doesn't use at all are >in window or not. I fully agree with this view. > > ** Limits on dupacks > > Would it make sense to limit the number of accepted dupacks to > > Max_dupacks = (Flight_size_fr - 1) / SMSS ? > > where Flight_size_fr is the Flight_Size at the point fast retransmit > > is triggered. > >I'd like to hear what people think on this notion. The intent in >putting the new text in was not to tightly specify a mechanism, but to >note that there is good reason to put some sort of limit on things. How >that is done does not seem important to me. (*If* it is done only seems >marginally helpful to me.) I.e., one could envision a cwnd limit or >trying (because we don't keep track in some stacks) to track the number >of packets vs. dupacks as above or ... > >I guess I would rather leave it as sort-of fuzzy guidance and not >mechanism or just drop it as new functionality that is out of scope for >the revision. I think it would be helpful to describe possible mechanisms (such as the one above). If not, chances are that people is not going to implement it, or they may get the limit wrong. The doc already some includes text about ack-division attacks, so IMHO I don't think describing a mechanism for enforcing limits on dupacks would be out of scope. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Feb 14 12:03:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHNXW-0007uM-Mp; Wed, 14 Feb 2007 12:03:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHNXV-0007u7-3G for tcpm@ietf.org; Wed, 14 Feb 2007 12:03:29 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHNXT-0008Ad-OC for tcpm@ietf.org; Wed, 14 Feb 2007 12:03:29 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l1EH3Iqc013777; Wed, 14 Feb 2007 09:03:19 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 8661C7B9503; Wed, 14 Feb 2007 12:03:13 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 6755B17C3C9; Wed, 14 Feb 2007 12:03:01 -0500 (EST) To: Fernando Gont From: Mark Allman Subject: Re: [tcpm] Some comments on 2581bis In-Reply-To: <200702141636.l1EGaDKS022982@venus.xmundo.net> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Whole Lotta Love MIME-Version: 1.0 Date: Wed, 14 Feb 2007 12:03:01 -0500 Message-Id: <20070214170301.6755B17C3C9@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1935317954==" Errors-To: tcpm-bounces@ietf.org --===============1935317954== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > I think it would be helpful to describe possible mechanisms (such as > the one above). If not, chances are that people is not going to > implement it, or they may get the limit wrong. The doc already some > includes text about ack-division attacks, so IMHO I don't think > describing a mechanism for enforcing limits on dupacks would be out of > scope. The hesitation here is that we're making things up for inclusion in a document that we are trying to progress to draft standard. I am a little uncomfortable with that. The other things in the document have some more long-term understanding and study behind them. I don't mind the document saying "here is a case where you might want to be more conservative than allowed". But, if we translate that into one or more mechanisms we could easily get bit. I have done this "it is such an easy tweak, how could it be wrong?" business enough times over the years to know that the interactions are tricky and subtle and it takes work to understand the implications of these things. And, sometimes the "easy, for sure gotta be right" changes are absolutely wrong. I am just feeling like we don't want to do that in this document. Just my opinion ... allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFF00DFWyrrWs4yIs4RAnL+AJ98ELVytxAskbZnHUPGXUm/OomAmwCgiQn4 t9ci68VVLo2afx/EeGY2Iag= =zzVT -----END PGP SIGNATURE----- --=_bOundary-- --===============1935317954== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1935317954==-- From tcpm-bounces@ietf.org Wed Feb 14 13:08:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHOXm-0001Xp-5b; Wed, 14 Feb 2007 13:07:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHOXk-0001XK-Qg for tcpm@ietf.org; Wed, 14 Feb 2007 13:07:48 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHOXi-0007sq-En for tcpm@ietf.org; Wed, 14 Feb 2007 13:07:48 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l1EI7e8o015270; Wed, 14 Feb 2007 10:07:41 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id A85D57B9B26; Wed, 14 Feb 2007 13:07:35 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 7B76817C4AA; Wed, 14 Feb 2007 13:07:23 -0500 (EST) To: John Heffner From: Mark Allman Subject: Re: [tcpm] Some comments on 2581bis In-Reply-To: <45D33281.6000803@psc.edu> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Whole Lotta Love MIME-Version: 1.0 Date: Wed, 14 Feb 2007 13:07:23 -0500 Message-Id: <20070214180723.7B76817C4AA@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: tcpm@ietf.org, Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0460454297==" Errors-To: tcpm-bounces@ietf.org --===============0460454297== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > The notion of the sender "using" SACK is a bit fuzzy anyway, since > some stacks will send the options but not process them in any > meaningful way (writing scoreboard code is hard). This is getting a little better. Contrast the 2000 and 2004 results on actual SACK usage (not just sending them) in the paper below. Still not stunning in 2004, but at least it was on the rise and hopefully it has continued to be. allman Alberto Medina, Mark Allman, Sally Floyd. Measuring the Evolution of Transport Protocols in the Internet. ACM Computer Communication Review, 35(2), April 2005. http://www.icir.org/mallman/papers/tcp-evo-ccr05.ps --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFF00/bWyrrWs4yIs4RAuqfAJ4+W6cX7U0zN6sja8JmyVMG3qsS3ACfSq/X LGAicSvzvl3duqL9RADqEC8= =dwz7 -----END PGP SIGNATURE----- --=_bOundary-- --===============0460454297== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0460454297==-- From tcpm-bounces@ietf.org Thu Feb 15 11:50:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHjnT-0003Nx-LU; Thu, 15 Feb 2007 11:49:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHjnS-0003Nr-NI for tcpm@ietf.org; Thu, 15 Feb 2007 11:49:26 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHjnO-0001lg-Qb for tcpm@ietf.org; Thu, 15 Feb 2007 11:49:26 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 15 Feb 2007 08:49:22 -0800 X-IronPort-AV: i="4.14,176,1170662400"; d="scan'208"; a="39710315:sNHT92336139" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l1FGnMHq011793 for ; Thu, 15 Feb 2007 08:49:22 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l1FGnMnF029505 for ; Thu, 15 Feb 2007 08:49:22 -0800 (PST) Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Feb 2007 08:49:22 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Feb 2007 08:49:20 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC5802DE6C93@xmb-sjc-21c.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-tcpm-tcpsecure-06 thread-index: Acc6ZMLf0QDtbC/nQ6mEU1rXB2CPaQWu9BGQ From: "Anantha Ramaiah \(ananth\)" To: X-OriginalArrivalTime: 15 Feb 2007 16:49:22.0060 (UTC) FILETIME=[3E13BCC0:01C75121] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=16918; t=1171558162; x=1172422162; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20\(ananth\)=22=20 |Subject:=20FW=3A=20draft-ietf-tcpm-tcpsecure-06 |Sender:=20; bh=SB6W4GREmke6CgGJRpnPsrlzrIZhQ6hl0ZA0TrPaVKc=; b=c41RBBT2tXh1SFluW9BaHIq+jgHeO/JxZDbN0MXoNzKU9QC5aq0hWIjEHCt09i+BayX6RI83 svhHAr7tdNcnD/20gUbffNDXZNhvyu7voIP77VD2GkZ4M/KLka0oAD5m; Authentication-Results: sj-dkim-8; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d437399464e10b52abe9a34ed7e712d0 Subject: [tcpm] FW: draft-ietf-tcpm-tcpsecure-06 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org I am sending the comments which we received from Alfred to the wider = audience. I have gone through that and most of them look acceptable. = Revision 07 which will posted very soon would incoporate these comments = among other things. I'll also broadcast the response which is being sent = to Alfred. Thanks, -Anantha -----Original Message----- From: Alfred H=CEnes [mailto:ah@tr-sys.de]=20 Sent: Wednesday, January 17, 2007 10:22 AM To: Anantha Ramaiah (ananth); Randall Stewart (rrs); Mitesh Dalal = (mdalal) Subject: draft-ietf-tcpm-tcpsecure-06 Hello, after studying the Internet-Draft authored/edited by you, draft-ietf-tcpm-tcpsecure-06, I'd like to submit a few comments, addressing the many textual/editorial = flaws I found in that memo. The items below are presented in textual order. To give more context, sometimes I quote larger blocks of text literally = and show the proposed replacement in the shorthand notation: --- I use change bars ('|' in column 1) and occasionally up/down pointing = marker lines ('^^^'/'vvv') to emphasize the location of textual issues = and/or proposed corrections. Modified text has been re-adjusted to match RFC formatting rules, where = appropriate. I also try to accomodate published RFC-Ed policy on style = and punctuation etc. in my porposals. (0) obsolete Ref. [RFC1771] has been obsoleted, one year ago, by RFC 4271, January 2006. Please update the multiple references. Below, I only include the = appropriate changes for snippits presented for other reasons as well. (1) Abstract, end of 1st paragraph [...]. A combination of | increasing window sizes and applications using a longer term =20 | connections (e.g. H-323 or Border Gateway Protocol [RFC1771]) have left modern TCP implementation more vulnerable to these types of spoofed packet injection attacks. --- [...]. A combination of | increasing window sizes and applications using longer term =20 | connections (e.g., H-323 or Border Gateway Protocol [RFC1771]) have left modern TCP implementation more vulnerable to these types of spoofed packet injection attacks. (2) Section 1, 1st paragraph TCP [RFC0793] is widely deployed and the most common reliable end to end transport protocol used for data communication in todays Internet. Yet when it was defined over 20 years ago the Internet, as we know it, was a different place lacking many of the threats that are now common. TCP spoofing attacks are one such attack that are seen on the Internet today. --- TCP [RFC0793] is widely deployed and the most common reliable end to | end transport protocol used for data communication in today's =20 | Internet. Yet when it was defined over 30 years ago, the Internet, =20 | as we know it, was a different place, lacking many of the threats that are now common. TCP spoofing attacks are one such attack that are seen on the Internet today. [Note: The first TCP Specification published as an RFC was RFC 675, = December 1974, obsoleted by RFC 761 (January 1980), and finally RFC 793 = =3D STD 7 (September 1981). According to Jon Postel, there have been = at 7 earlier editions of the TCP specification not circulated as RFCs. So don't tell a ripe, 32+ years ol' TCP a teenager ! ] (3) Section 1.1=20 In bullet 1): ... number of factors most notably ... --- ... number of factors, most notably ... ^ In the last paragraph: ... much more difficult then ... --- ... much more difficult than ... ^ (4) Section 1.2 Typos in the 5th paragraph: For the purposes of the rest of this discussion we will assume that the attacker knows the 4-tuple values. This assumption will help us | focus on the effects of the window size verses the number of TCP packets an attacker must generate. This assumption will rarely be true in the real Internet since at least the client port number will provide us with some amount of randomness (depending on operating system). --- For the purposes of the rest of this discussion we will assume that the attacker knows the 4-tuple values. This assumption will help us | focus on the effects of the window size versus the number of TCP packets an attacker must generate. This assumption will rarely be true in the real Internet since at least the client port number will | provide us with some amount of randomness (depending on the operating system). In the 6th paragraph, I recommend to replace the uppercase 'X' by a = lowercase 'x' as a multiplication sign, or use '*' instead. Simplification by evaluation of the [constant parts of the] terms = ("constant folding") might be considered as well. At the end of the 8th paragraph: [...]. Resetting the connection can result in medium term unavailability due to the need to rebuild routing tables and route flapping see [NISCC] for further details. --- [...]. Resetting the connection can result in medium term unavailability due to the need to rebuild routing tables and route | flapping; see [NISCC] for further details. ^ 9th paragraph: It also needs to be emphasized that for applications like BGP which use the TCP MD5 option [RFC2385], can make the attacks described in this specification much harder to accomplish. --- | It also needs to be emphasized that, for applications like BGP, use =20 | of the TCP MD5 option [RFC2385] can make the attacks described in this specification much harder to accomplish. or: | It also needs to be emphasized that for applications like BGP using =20 | the TCP MD5 option [RFC2385], the attacks described in this =20 | specification are much harder to accomplish. 10th (=3D last) paragraph: vvvvvvvvvv vv? | It should be noted that there are existing alternative protection against the threats that this document addresses. [...] --- v | It should be noted that there are existing alternative protections against the threats that this document addresses. [...] (5) Section 3.2 -- multiple typos Below bullet '2)' : Instead, this document requires that implementations MUST perform the following steps in place of those specified in [RFC0793](listed above). --- ^^ Instead, this document requires that implementations MUST perform the | following steps in place of those specified in [RFC0793] (as listed above). ^^^^^ [ For = additional clarification, I have added the word "as". ] In bullet 'C)' The previous text,quoted from [RFC0793] ... --- The previous text, quoted from [RFC0793] ... ^ and subsequently: vvvvvvv | [...]. If the the RST arrives and its sequence number field does NOT match the next expected sequence number but is within the window, then the receiver should generate an ACK. --- | [...]. If the RST arrives and its sequence number field does NOT match the next expected sequence number but is within the window, then the receiver should generate an ACK. and finally, at the end of the bullet: [...]. This second RST if it reaches the sender will cause the connection to be aborted since the sequence number would now be an exact match. --- | [...]. This second RST, if it | reaches the sender, will cause the connection to be aborted since the sequence number would now be an exact match. or: | [...]. If this second RST | reaches the sender, it will cause the connection to be aborted since the sequence number would now be an exact match. And at the end of the section, add the missing full stop : [...]. This concern is discussed in Section 9. ^ (6) Section 4.1 vv v Analysis of the reset attack using the RST bit, highlights another possible avenue for a blind attacker using a similar set of sequence number guessing. [...] --- | The Analysis of the reset attack using the RST bit highlights another possible avenue for a blind attacker using a similar set of sequence number guessing. [...] (7) Section 4.2 In the 2nd paragraph after bullet 'A)' : [...]. Upon receipt of a valid RST, the local TCP | endpoint MUST terminate its connection. The local TCP endpoint should then rely on SYN retransmission from the remote end to re- establish the connection. --- [...]. Upon receipt of a valid RST, the local TCP | endpoint MUST terminates its connection. The local TCP endpoint should then rely on SYN retransmission from the remote end to re- establish the connection. In the 4th paragraph after bullet 'A)' , change "non spoofed SYN" --> = "non-spoofed SYN" . And at the end of the section, add the missing full stop : [...]. This concern is discussed in Section 9. ^ (8) Section 5.1 Typos and mismatched parentheses in the 1st paragraph: A third type of attack is also highlighted by both the RST and SYN attacks. It is also possible to inject data into a TCP connection by | simply guessing the a sequence number within the current receive window of the victim. The ACK value of any data segment is considered valid as long as it does not acknowledge data ahead of the next segment to send. In other words an ACK value is acceptable if | it is (SND.UNA-(2^31-1)) <=3D SEG.ACK <=3D SND.NXT). This means that = an attacker has to guess two ACK values with every guessed sequence | number so that the chances successfully injecting data into a connection are 1 in ((2^32 / RCV.WND) * 2). --- A third type of attack is also highlighted by both the RST and SYN attacks. It is also possible to inject data into a TCP connection by | simply guessing a sequence number within the current receive window of the victim. The ACK value of any data segment is considered valid as long as it does not acknowledge data ahead of the next segment to send. In other words an ACK value is acceptable if it is | ((SND.UNA-(2^31-1)) <=3D SEG.ACK <=3D SND.NXT). This means that an attacker has to guess two ACK values with every guessed sequence | number so that the chances of successfully injecting data into a connection are 1 in ((2^32 / RCV.WND) * 2). (9) Section 5.2 Typos, and improved wording, in the 1st paragraph: An additional input check MUST be added to any incoming segment. The ACK value MUST be acceptable only if it is in the range of ((SND.UNA | - MAX.SND.WND) <=3D SEG.ACK <=3D SND.NXT).A new state variable MAX.SND.WND is defined as the largest window that the local sender | has ever received from its peer. This window may be a scaled value =20 | i.e. the value may be larger than 65,535 bytes ([RFC1323]). This small check will reduce the vulnerability to an attacker guessing a valid sequence number since not only must he/she guess the sequence number in window, but must also guess a proper ACK value within a scoped range. This mitigation reduces but does not eliminate the ability to generate false segments. It does however reduce the probability that invalid data will be injected. --- An additional input check MUST be added to any incoming segment. The ACK value MUST be acceptable only if it is in the range of ((SND.UNA | - MAX.SND.WND) <=3D SEG.ACK <=3D SND.NXT). A new state variable MAX.SND.WND is defined as the largest window that the local sender | has ever received from its peer. This window may be scaled to a =20 | value larger than 65,535 bytes ([RFC1323]). This small check will reduce the vulnerability to an attacker guessing a valid sequence | number, since he/she not only must guess the in-window sequence =20 | number, but also a proper ACK value within a scoped range. This =20 | mitigation reduces, but does not eliminate, the ability to generate false segments. It does, however, reduce the probability that invalid data will be injected. And again, at the end of the section, add the missing full stop : [...]. This concern is discussed in Section 9. ^ (10) Section 6 2nd paragraph after the numbered bullets: vvv | An implementation SHOULD include a ACK throttling mechanism to be conservative. [...] --- vvvv | An implementation SHOULD include an ACK throttling mechanism to be conservative. [...] (11) Section 8.1 1st paragraph: Consider a middlebox M-B tracking connection between two TCP endhosts E-A and E-C. If E-C sends a RST with a sequence number that is within the window but not an exact match to reset the connection and M-B does not have the fix recommended in this document, it may clear the connection and forward the RST to E-A saving an incorrect sequence number. [...] --- v | Consider a middlebox M-B tracking connections between two TCP endhosts E-A and E-C. If E-C sends a RST with a sequence number that is within the window but not an exact match to reset the connection and M-B does not have the fix recommended in this document, it may clear the connection and forward the RST to E-A saving an incorrect sequence number. [...] and: vv vv v [...]. This RST, will again, not acceptable and may trigger a challenge ACK. --- v v vv [...]. This RST will again not be acceptable and may trigger a challenge ACK. 2nd paragraph: The above situation may result in a RST/ACK war. However we believe that if such a case exists in the Internet the middle box design does not comply to [RFC0793]. [...] --- | The above situation may result in a RST/ACK war. However, we believe = =20 | that if such a case exists in the Internet, the middle box design does not comply to [RFC0793]. [...] (12) Section 8.2 1st paragraph: [...]. The scenario is the same as the earlier case, but in this case instead of sending the cached RST, the middlebox (M-B) sends a RST that computes its sequence number as a sum of the ack field in the ACK and the window advertised by the ACK that was sent by E-A to challenge the RST as depicted below. [...] --- [...]. The scenario is the same as the earlier case, but in this case instead of sending the cached RST, the | middlebox (M-B) sends a RST that computes its sequence number as the sum of the ack field in the ACK and the window advertised by the ACK that was sent by E-A to challenge the RST as depicted below. [...] (13) Section 9, 5th paragraph Another consideration that should be noted is a reflector attack is possible with the required RST/SYN mitigation techniques. In this attack an off-path attacker can cause a victim to send an ACK segment for each spoofed RST/SYN segment that lies within the current receive window of the victim. [...] --- | Another consideration that should be noted is a reflector attack, =20 | which is possible with the required RST/SYN mitigation techniques. | In this attack, an off-path attacker can cause a victim to send an ACK segment for each spoofed RST/SYN segment that lies within the current receive window of the victim. [...] Best regards, Alfred H=CEnes. --=20 +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Feb 15 18:51:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHqMf-0003k3-LB; Thu, 15 Feb 2007 18:50:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHqMV-0003cc-Ar; Thu, 15 Feb 2007 18:50:03 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHqMU-0003Mb-Tm; Thu, 15 Feb 2007 18:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 584EF26EDE; Thu, 15 Feb 2007 23:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HHqMU-0003h6-42; Thu, 15 Feb 2007 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 15 Feb 2007 18:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-rfc2581bis-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : TCP Congestion Control Author(s) : M. Allman, et al. Filename : draft-ietf-tcpm-rfc2581bis-02.txt Pages : 16 Date : 2007-2-15 This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc2581bis-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tcpm-rfc2581bis-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tcpm-rfc2581bis-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-15153402.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-rfc2581bis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-rfc2581bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-15153402.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --NextPart-- From tcpm-bounces@ietf.org Mon Feb 19 10:46:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJAgy-0002o6-KT; Mon, 19 Feb 2007 10:44:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJAgw-0002j7-LT for tcpm@ietf.org; Mon, 19 Feb 2007 10:44:38 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJAgv-0000xz-BL for tcpm@ietf.org; Mon, 19 Feb 2007 10:44:38 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l1JFiYxl014228 for ; Mon, 19 Feb 2007 07:44:34 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 16EBC7E5DFD for ; Mon, 19 Feb 2007 10:44:29 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id AC968180855 for ; Mon, 19 Feb 2007 10:44:08 -0500 (EST) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Cocaine MIME-Version: 1.0 Date: Mon, 19 Feb 2007 10:44:08 -0500 Message-Id: <20070219154408.AC968180855@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [tcpm] implementation experience X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1370621220==" Errors-To: tcpm-bounces@ietf.org --===============1370621220== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Hi folks! I am looking for a little bit of implementation experience on 2581. I should really keep better track of this sort of thing, but if anyone out there is a TCP implementer and could contact me off-list, I'd appreciate it. Thanks, allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFF2cXIWyrrWs4yIs4RAvLeAJ0R5szWTp7ux185v1gh3HAzz7FV8gCdFGSl L4BpRXUbFvV4jYtDrHjl7TU= =qbFa -----END PGP SIGNATURE----- --=_bOundary-- --===============1370621220== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1370621220==-- From tcpm-bounces@ietf.org Tue Feb 20 12:34:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJYrX-0004YI-3e; Tue, 20 Feb 2007 12:33:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJYrW-0004XE-5e for tcpm@ietf.org; Tue, 20 Feb 2007 12:33:10 -0500 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJYrQ-0001pA-MH for tcpm@ietf.org; Tue, 20 Feb 2007 12:33:10 -0500 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Feb 2007 17:33:01 +0000 Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.64]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Feb 2007 17:27:02 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Feb 2007 17:27:03 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New I-D posted : draft-moncaster-tcpm-rcv-cheat-00 Thread-Index: AcdUM1p48JkJlkW1QDC5NeLHuwq6tgAABe+wADfFPnA= From: To: X-OriginalArrivalTime: 20 Feb 2007 17:27:02.0726 (UTC) FILETIME=[559ABE60:01C75514] X-Spam-Score: 0.2 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Subject: [tcpm] New I-D posted : draft-moncaster-tcpm-rcv-cheat-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org All,=20 As you will shortly see we have just posted a new ID called "A TCP Test To Allow Senders to Identify Receiver Cheating" draft-moncaster-tcpm-rcv-cheat-00. This draft was written as a result of a request made to Bob Briscoe at IETF 67. There he mentioned to TVWG that we would be happy to produce a transport layer nonce to protect against receivers concealing lost packets. This suggestion was broadly welcomed by the WG and this draft is our response. Initially we intended to submit this to TSVWG as they requested it. However after checking with the co-chairs of both TCPM and TSVWG it was agreed that TCPM would be the best forum for the draft. The draft is available in various formats at http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html#tcp-rcv-cheat. After some background research we decided that an actual nonce would probably be impractical since it would require modifications to both sender and receiver. This would make it very hard to enforce as the receiver could simply pretend to be a legacy one that didn't support the new nonce. We were keen that our system should be robust and should require the receiver simply to behave as mandated by the existing TCP protocols. Indeed the idea was that the solution should actually leverage the existing TCP behaviours in order to test the honesty of the receiver. We decided to base our new solution on a solution by Rob Sherwood et al presented in "Misbehaving TCP receivers can cause Internet-wide congestion collapse". Their solution, called the randomly skipped segments solution, suggests purposely removing a segment from the transmitted data stream and only transmitting it after the receiver sends a NACK for that segment. If in the meantime the receiver sends an ACK for a later segment then they are deemed to be behaving dishonestly. A recent thread on the TCPM mailing list (starting 11th January 2007 "DoS attack from misbehaving receivers") has been discussing the randomly skipped segments solution in some detail and reveals that there is a lot of unease about such a test. Our solution is hopefully more palatable and consists of 2 stages. In the first stage we probabilistically test the honesty of a receiver. To do this we select a segment N and a displacement D. Instead of transmitting segments N-1, N, N+1, N+2, etc we transmit N-1, N+1, N+2, ..., N+D, N, ... An honest TCP receiver should respond to this missing data by generating a stream of duplicate ACKs for segment N-1. Any receiver that doesn't do so is probably behaving dishonestly but, because TCP doesn't guarantee reliable delivery of ACKs we can't state this for certain. We therefore state that any receiver that fails this test should be subjected to a further test that is essentially the same as the Sherwood test. It is felt that the first test causes minimal damage to an honest receiver and is essentially compliant with the TCP protocol. The second test is then reserved for those receivers that we are pretty certain are behaving dishonestly. We have currently left it up to the community to decide how to sanction any receiver that fails the second test. We suggest the appropriate response might be to terminate the connection but others might instead feel that other sanctions such as reducing the congestion window and slow start threshold to 1 would be more appropriate. Both our tests force accurate reporting of losses which was our initial aim. They also both make it much harder for a receiver to optimistically ACK data which is an added benefit given the possible harm such optimistic ACKs might cause. We will be presenting this at IETF 68 in Prague and would welcome any comments from people as to the utility of our solution and any improvements that could be made. Toby Moncaster=20 Future Communications Architecture Networks Research Centre BT Group Chief Technology Office _________________________________________________ t: (+44) (0) 1473 648734 m: (+44) (0) 7764 185416=20 ________________________________________________________________________ ___ Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of BT plc. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Feb 20 13:11:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJZSF-0006qQ-Oc; Tue, 20 Feb 2007 13:11:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJZSE-0006oo-63 for tcpm@ietf.org; Tue, 20 Feb 2007 13:11:06 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJZSA-0001TH-P5 for tcpm@ietf.org; Tue, 20 Feb 2007 13:11:06 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l1KIAoKp019480; Tue, 20 Feb 2007 10:10:51 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 5658D7F0A87; Tue, 20 Feb 2007 13:10:45 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 9EAFC181B80; Tue, 20 Feb 2007 13:10:23 -0500 (EST) To: weddy@grc.nasa.gov From: Mark Allman Subject: Re: [tcpm] New I-D In-Reply-To: <20070213185552.GB7252@grc.nasa.gov> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Cocaine MIME-Version: 1.0 Date: Tue, 20 Feb 2007 13:10:23 -0500 Message-Id: <20070220181023.9EAFC181B80@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1324962680==" Errors-To: tcpm-bounces@ietf.org --===============1324962680== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Regarding: http://www.ietf.org/internet-drafts/draft-mahesh-persist-timeout-00.txt Wes: > [...] but it looks to me like this is more of an OS mechanism to > manage resources rather than a protocol-based mechanism. Is this > correct? I'm with Wes here. I just took a spin through the draft and am left with three thoughts ... + You say apps don't have a good role to play even after citing apps that 'pause' as the culprit. I can't make these things agree in my head. Even in the absence of TCP-specific information it seems that these apps could time themselves out if no progress is being made (i.e. data getting exchanged). (Further, things like HTTP sends after which the app goes away and then getting wedged into persist don't worry me much. That sounds like a once in a blue moon sort of situation to me.) + This seems fundamentally like an operating system resource issue to me and not something for a networking standards body. OSes deal with all sorts of resource contention issues without standards. Why does this problem need to be solved the same way by each OS? + In particular, I think you have solved the problem wrong. Don't get me wrong ... maybe it is perfectly OK for your purposes and it is fine with me if you want to use it. However, I would want something a little smarter to really avoid the mythical attacks you describe. All you did was to cap the length of connections. So, conceivably a periodic attack could still keep all your resources busy. It seems to me that you'd want to use some sort of scheme that actually took into account contention and resource exhaustion. E.g., some sort of LRU what-has-been-in-persist longest when you need new resources and they are not available sort of culling scheme? Or, when you have exhausted X% of your resources to keep some in reserve. That might be wrong and busted itself (it is quickly off the top of my head), but it at least takes into account the resource contention unlike a naive timeout. Just my two bits ... allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFF2zmPWyrrWs4yIs4RAs2HAJ4nAA9BXx4DNF5IinNy5Jejnp9XWwCcD2df 79uc7cNIE1vdtwQzo65Tk1Q= =eIL2 -----END PGP SIGNATURE----- --=_bOundary-- --===============1324962680== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1324962680==-- From tcpm-bounces@ietf.org Tue Feb 20 14:37:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJanP-0000Tl-Hx; Tue, 20 Feb 2007 14:37:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJanO-0000TS-A1 for tcpm@ietf.org; Tue, 20 Feb 2007 14:37:02 -0500 Received: from flyer.cs.umd.edu ([128.8.128.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJanM-0004Jw-OK for tcpm@ietf.org; Tue, 20 Feb 2007 14:37:02 -0500 Received: from loompa.cs.umd.edu (loompa.cs.umd.edu [128.8.128.63]) by flyer.cs.umd.edu (8.12.11.20060308/8.12.5) with ESMTP id l1KJarNC024791; Tue, 20 Feb 2007 14:36:53 -0500 Received: (from capveg@localhost) by loompa.cs.umd.edu (8.12.10/8.12.5) id l1KJaqMr018700; Tue, 20 Feb 2007 14:36:52 -0500 (EST) Date: Tue, 20 Feb 2007 14:36:52 -0500 From: Rob Sherwood To: toby.moncaster@bt.com Subject: Re: [tcpm] New I-D posted : draft-moncaster-tcpm-rcv-cheat-00 Message-ID: <20070220193652.GZ20215@loompa.cs.umd.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Tue, Feb 20, 2007 at 05:27:03PM -0000, toby.moncaster@bt.com wrote: > All, > > As you will shortly see we have just posted a new ID called "A TCP Test > To Allow Senders to Identify Receiver Cheating" > draft-moncaster-tcpm-rcv-cheat-00. This draft was written as a result of > a request made to Bob Briscoe at IETF 67. There he mentioned to TVWG > that we would be happy to produce a transport layer nonce to protect > against receivers concealing lost packets. This suggestion was broadly > welcomed by the WG and this draft is our response. Initially we intended > to submit this to TSVWG as they requested it. However after checking > with the co-chairs of both TCPM and TSVWG it was agreed that TCPM would > be the best forum for the draft. The draft is available in various > formats at > http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html#tcp-rcv-cheat. Hi Toby, I gave a quick read through the draft on your website, and have a few comments. Section 5.1) I think there might be some confusion here, but the skipped segment solution that we proposed in our paper does not require the receiver supports SACK. Trivially, our paper presents performance results for receivers that do and do not support SACK. If the sender skips segment N, any ACK > N indicates misbehavior; SACK is simply not involved for correctness. If SACK is not supported in the connection, then the standard performance penalties for not implementing SACK apply, i.e., the receiver has to duplicate ACK each loss in turn. Am I missing something here? Section 6.2.4) "Periodically and randomly, any heavily loaded TCP sender SHOULD check the honesty of its receivers using the probabilistic test." I don't think it is sufficient that only heavily loaded TCP senders perform this test. Attackers can simply draw a small amount of traffic from many ("jillions" to quote Mark :-) of servers, not loading any one, but still have a large aggregate amount of traffic. In other words, if the solution is only applied to loaded servers, then the attack still exists. At a high level, I like the proposed two phase test in that it is slightly more efficient then the randomly skipped segment test alone, i.e., instead of honest receivers being penalized 1 RTT every test, they are only penalized the buffer time and 1 RTT if network reordering (pathologically?) undoes the reordering test. It is not clear, to me at least, how the efficiency gain weighs against the additional complexity of code, but presumably others can comment on that. However, my understanding of the concern raised on this list (if I can summarize other's opinions) was that there was a philosophical objection to mucking up[1] the TCP code for an attack which is not being actively exploited. In other words, it wasn't the efficiency of the solution that was at issue, but whether is should be applied at all. Should people decide that this two phases approach is preferable, it might be possible to simplify the first phase test as follows. Rather then reordering segments N-1,N,N+1,..,N+D to N-1,N+1,..,N+D,N as Toby et. al suggest, it might be better to more frequently perform this test with D=1, (i.e., simply swap the order of two sequential segments) and after some threshold number K failures, apply the second phase randomly skipped segment test. I only suggest this as the analysis is probably slightly simpler in that the reordering rate of pairs of packets have been previously measured, where as the probability that the N-1,N,N+1,..,N+D to N-1,N+1,..,N+D,N reordering would be undone is less well studied. - Rob . [1] "mucking up" is clearly a technical term :-) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Feb 20 15:17:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJbPw-00025Q-SA; Tue, 20 Feb 2007 15:16:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJbPv-00025J-6V for tcpm@ietf.org; Tue, 20 Feb 2007 15:16:51 -0500 Received: from web31702.mail.mud.yahoo.com ([68.142.201.182]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HJbPr-0002vo-LM for tcpm@ietf.org; Tue, 20 Feb 2007 15:16:51 -0500 Received: (qmail 16573 invoked by uid 60001); 20 Feb 2007 20:16:47 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=OiMW1vc3XngxikJOviX8+sgIE6EXbwTsf4gxT6RE+ejrRUq5hw/mazoafFaZOyboQX/IlufrGFWJDBWFydC5lrdgQ1qiGfrGcWMsLcqXq4s6UlAgorWwPTPjIy6D5ma8BnN29Wz6XSGqkg62zqvnexlB+evFy0vWBiGrENZcujg=; X-YMail-OSG: bdyeIiIVM1mzzgzUorsoY5Wh_HhesXg8Q8CARYsiIS24pwlj.k3gdJYmkq7rIrZLs5sbLzC66zGtBmfXjrsvMX0EW2vspn.edOKsvkhxunT1FHzwVAtOdgi4c8c_3.nXAA6aQHh9hiuYiEg- Received: from [69.28.107.2] by web31702.mail.mud.yahoo.com via HTTP; Tue, 20 Feb 2007 12:16:46 PST Date: Tue, 20 Feb 2007 12:16:46 -0800 (PST) From: MURALI BASHYAM Subject: Re: [tcpm] New I-D To: mallman@icir.org, weddy@grc.nasa.gov In-Reply-To: <20070220181023.9EAFC181B80@lawyers.icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <902737.15421.qm@web31702.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org --- Mark Allman wrote: > > Regarding: > > http://www.ietf.org/internet-drafts/draft-mahesh-persist-timeout-00.txt > > Wes: > > [...] but it looks to me like this is more of an > OS mechanism to > > manage resources rather than a protocol-based > mechanism. Is this > > correct? > > I'm with Wes here. > > I just took a spin through the draft and am left > with three thoughts ... > > + You say apps don't have a good role to play even > after citing apps > that 'pause' as the culprit. I can't make these > things agree in my > head. Even in the absence of TCP-specific > information it seems that > these apps could time themselves out if no > progress is being made > (i.e. data getting exchanged). Well behaved applications usually SHOULD do this, i agree, can't be guaranteed though. Leaving the problem to be addressed by the app, does not ensure timeliness from the point of view that TCP resources such as buffers and connections are scarce and by how much etc. The scheme lacks robustness if left to the application, and for it to be beneficial, ALL applications running on a system should be doing it, otherwise there is the weakest link. > > (Further, things like HTTP sends after which the > app goes away and > then getting wedged into persist don't worry me > much. That sounds > like a once in a blue moon sort of situation to > me.) > > + This seems fundamentally like an operating > system resource issue to > me and not something for a networking standards > body. OSes deal > with all sorts of resource contention issues > without standards. Why > does this problem need to be solved the same way > by each OS? At first glance, it does seem like an OS resource issue, but TCP connections can have data backlogged in their send queues for a variety of reasons and for variable amounts of time, i am not sure how a protocol unaware OS based solution can make the distinction between the network causing the backlog transiently, and a legitimate vs rogue receiver causing the backlog etc, i feel that making it TCP protocol specific (something designed only for persist state) allows for well controlled, granular solution(s) and heuristics to detect specifically misbehaving receivers in this scenario. > > + In particular, I think you have solved the > problem wrong. Don't get > me wrong ... maybe it is perfectly OK for your > purposes and it is > fine with me if you want to use it. However, I > would want something > a little smarter to really avoid the mythical > attacks you describe. > All you did was to cap the length of > connections. So, conceivably a > periodic attack could still keep all your > resources busy. It seems > to me that you'd want to use some sort of scheme > that actually took > into account contention and resource exhaustion. > E.g., some sort of > LRU what-has-been-in-persist longest when you > need new resources and > they are not available sort of culling scheme? > Or, when you have > exhausted X% of your resources to keep some in > reserve. That might > be wrong and busted itself (it is quickly off > the top of my head), > but it at least takes into account the resource > contention unlike a > naive timeout. > The LRU scheme can be overlaid on top of the timeout scheme to ensure a flexible and adaptive solution quite easily, i agree. It still calls for tracking connections bottlenecked specifically by the infinite persistence problem. Murali > Just my two bits ... > > allman > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm > ____________________________________________________________________________________ The fish are biting. Get more visitors on your site using Yahoo! Search Marketing. http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Feb 20 18:55:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJeo8-0007TL-R0; Tue, 20 Feb 2007 18:54:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJeo8-0007TG-Ar for tcpm@ietf.org; Tue, 20 Feb 2007 18:54:04 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJeo6-0001cl-Vh for tcpm@ietf.org; Tue, 20 Feb 2007 18:54:04 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l1KNruCg028258; Tue, 20 Feb 2007 15:53:56 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 9844D7F3404; Tue, 20 Feb 2007 18:53:50 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 057B41822A6; Tue, 20 Feb 2007 18:53:28 -0500 (EST) To: MURALI BASHYAM From: Mark Allman Subject: Re: [tcpm] New I-D In-Reply-To: <902737.15421.qm@web31702.mail.mud.yahoo.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Cocaine MIME-Version: 1.0 Date: Tue, 20 Feb 2007 18:53:27 -0500 Message-Id: <20070220235328.057B41822A6@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: tcpm@ietf.org, weddy@grc.nasa.gov X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1184101709==" Errors-To: tcpm-bounces@ietf.org --===============1184101709== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > Well behaved applications usually SHOULD do this, i > agree, can't be guaranteed though. Leaving the problem > to be addressed by the app, does not ensure timeliness > from the point of view that TCP resources such as > buffers and connections are scarce and by how much > etc. The scheme lacks robustness if left to the > application, and for it to be beneficial, ALL > applications running on a system should be doing it, > otherwise there is the weakest link. So, let me step back. I should have been more careful. I think this is a problem with the draft-not the approach. That is, I can certainly understand why a TCP would want to not depend on apps. But, the text in the i-d doesn't lead me to that conclusion and I think it is at very best dubious in some places. > At first glance, it does seem like an OS resource issue, but TCP > connections can have data backlogged in their send queues for a > variety of reasons and for variable amounts of time, i am not sure how > a protocol unaware OS based solution can make the distinction between > the network causing the backlog transiently, and a legitimate vs rogue > receiver causing the backlog etc, i feel that making it TCP protocol > specific (something designed only for persist state) allows for well > controlled, granular solution(s) and heuristics to detect specifically > misbehaving receivers in this scenario. We are having a terminology problem here. I meant "OS" as in the thing that contains the TCP implementation. I did not mean that an OS could blindly reap off resources without understanding anything about TCP. Let me put it this way ... This seems to me to be a TCP **implementation** issue. Why should we need to standardize this issue and not other internal resource contention issues? Why is this anything but a very local problem that can be handled by the TCP implementation in whatever way that implementation chooses? And, then why is the proposed solution the right one? allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFF24n3WyrrWs4yIs4RAoBWAKCVMKeMEke1Xj+eAhiN1SN+UjtrJwCeJSfs cE2JtznGhSgQ016YeviqoMc= =E5Se -----END PGP SIGNATURE----- --=_bOundary-- --===============1184101709== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1184101709==-- From tcpm-bounces@ietf.org Tue Feb 20 19:27:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJfJu-000882-8p; Tue, 20 Feb 2007 19:26:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJfJt-00087o-Fa for tcpm@ietf.org; Tue, 20 Feb 2007 19:26:53 -0500 Received: from web31715.mail.mud.yahoo.com ([68.142.201.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HJfJp-0000uC-VG for tcpm@ietf.org; Tue, 20 Feb 2007 19:26:53 -0500 Received: (qmail 78868 invoked by uid 60001); 21 Feb 2007 00:26:49 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=TmRxVkofvTCjXNaaWiLIRBuPJgxC3KiTpoQHTJYkdmKx5T7fqkTp4W/v65Dh0oEM7Ao3IL7PXQp81RRW8FBCZr+KKtKFbHqCSSNU8i/ex0KDVJJD9J5vqmeDBYvf3FgQpc5IGOvpxstV+x3Viucs6bfrW30xD9weVjFcqHe1uOk=; X-YMail-OSG: OXXG45wVM1lSF5yUSL4RmxiOq_DpQhAzdzxrfCCKv7IPCW8Q7KsXKzNusJRZycOLu5NFPE86wmfSHNNvwAWB1XcT6jbGHyCnpt6rquzbv_buESBUNmHe4SlqWlPGG1yZbJNqRyoHYWaHjub3_3zjKTqlYQLf2hjyCA-- Received: from [69.28.107.2] by web31715.mail.mud.yahoo.com via HTTP; Tue, 20 Feb 2007 16:26:49 PST Date: Tue, 20 Feb 2007 16:26:49 -0800 (PST) From: MURALI BASHYAM Subject: Re: [tcpm] New I-D To: mallman@icir.org In-Reply-To: <20070220235328.057B41822A6@lawyers.icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <333037.78056.qm@web31715.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: tcpm@ietf.org, weddy@grc.nasa.gov X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org --- Mark Allman wrote: > > > Well behaved applications usually SHOULD do this, > i > > agree, can't be guaranteed though. Leaving the > problem > > to be addressed by the app, does not ensure > timeliness > > from the point of view that TCP resources such as > > buffers and connections are scarce and by how much > > etc. The scheme lacks robustness if left to the > > application, and for it to be beneficial, ALL > > applications running on a system should be doing > it, > > otherwise there is the weakest link. > > So, let me step back. I should have been more > careful. I think this is > a problem with the draft-not the approach. That is, > I can certainly > understand why a TCP would want to not depend on > apps. But, the text in > the i-d doesn't lead me to that conclusion and I > think it is at very > best dubious in some places. If it is dubious, then we can correct it, and perhaps we need to explain the motivation for that more clearly. > > > At first glance, it does seem like an OS resource > issue, but TCP > > connections can have data backlogged in their send > queues for a > > variety of reasons and for variable amounts of > time, i am not sure how > > a protocol unaware OS based solution can make the > distinction between > > the network causing the backlog transiently, and a > legitimate vs rogue > > receiver causing the backlog etc, i feel that > making it TCP protocol > > specific (something designed only for persist > state) allows for well > > controlled, granular solution(s) and heuristics to > detect specifically > > misbehaving receivers in this scenario. > > We are having a terminology problem here. I meant > "OS" as in the thing > that contains the TCP implementation. I did not > mean that an OS could > blindly reap off resources without understanding > anything about TCP. Okay, we are on the same page :-). > > Let me put it this way ... This seems to me to be a > TCP > **implementation** issue. Why should we need to > standardize this issue > and not other internal resource contention issues? > Why is this anything > but a very local problem that can be handled by the > TCP implementation > in whatever way that implementation chooses? It is an implementation to correct a problem caused by the protocol's REQUIREMENT for a sender to be in an infinite persistence state, thus allowing for abuse by a misbehaving receiver side application (or by a lot of well-behaved receivers). The draft is outlining a solution to the problem (there could be others). The idea in the (informational) draft is to highlight to the group that requirement of the protocol, its consequences and a possible solution. Are you suggesting that any requirements of the protocol specification that lead to a potential denial of service type of scenarios and thus causing internal resource contention, and/or any other network issues are all to be considered 'implementation' ? Shouldn't we look at the requirements of the protocol a little more carefully? > And, then why is the proposed solution the right > one? It does solve the problem it sets out to based on a "total time allowed to be in persist state" type of cap on the duration. Are you implying there could be other behaviours from the receiver that may not be addressed here, such as the receiver opening the window a little and then closing it that fernando mentioned, thus leading to a longer term issue? We need to build heuristics into the solution that can detect this and other types of anomalous receiver behaviour, and take appropriate action. And the heuristics themselves need to be based on a notion of a well behaved receiver in this scenario, to avoid false positives. Murali > > allman > > > > ____________________________________________________________________________________ TV dinner still cooling? Check out "Tonight's Picks" on Yahoo! TV. http://tv.yahoo.com/ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Feb 20 19:58:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJfnQ-0006bu-4d; Tue, 20 Feb 2007 19:57:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJfnP-0006bo-PG for tcpm@ietf.org; Tue, 20 Feb 2007 19:57:23 -0500 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJfnG-0004WW-4Y for tcpm@ietf.org; Tue, 20 Feb 2007 19:57:23 -0500 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 4AEEDF0C485; Tue, 20 Feb 2007 21:42:43 -0300 (ART) Received: from fgont.gont.com.ar (72-179-231-201.fibertel.com.ar [201.231.179.72]) (authenticated bits=0) by venus.xmundo.net (8.12.11.20060308/8.12.11) with ESMTP id l1L0fSMG029531; Tue, 20 Feb 2007 21:42:13 -0300 Message-Id: <200702210042.l1L0fSMG029531@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 20 Feb 2007 21:41:08 -0300 To: mallman@icir.org, MURALI BASHYAM From: Fernando Gont Subject: Re: [tcpm] New I-D In-Reply-To: <20070220235328.057B41822A6@lawyers.icir.org> References: <902737.15421.qm@web31702.mail.mud.yahoo.com> <20070220235328.057B41822A6@lawyers.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Tue, 20 Feb 2007 21:42:42 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: tcpm@ietf.org, weddy@grc.nasa.gov X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 08:53 p.m. 20/02/2007, Mark Allman wrote: >Let me put it this way ... This seems to me to be a TCP >**implementation** issue. Why should we need to standardize this issue >and not other internal resource contention issues? Why is this anything >but a very local problem that can be handled by the TCP implementation >in whatever way that implementation chooses? I think there are some instances of this already... e.g., Clark's RFC on fragment reassembly. IMHO, an Inforamtional doc on some implementation issues that may be troublesome might be of help. >And, then why is the proposed solution the right one? So far it does not look like "the right one" to me. I raised at least a few ways in which the attacker can fool the proposed countermeasure. -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Feb 21 02:58:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJmM7-0006wC-Kw; Wed, 21 Feb 2007 02:57:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJmM5-0006u5-SN for tcpm@ietf.org; Wed, 21 Feb 2007 02:57:37 -0500 Received: from lmr1.uibk.ac.at ([138.232.1.142] helo=smtp.uibk.ac.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJmM4-000117-Di for tcpm@ietf.org; Wed, 21 Feb 2007 02:57:37 -0500 Received: from [138.232.65.105] (pc105-c703.uibk.ac.at [138.232.65.105] michael.welzl@uibk.ac.at) (authenticated bits=0) by smtp.uibk.ac.at (8.13.8/8.13.1/F1) with ESMTP id l1L7txIR025169 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 21 Feb 2007 08:55:59 +0100 Subject: Re: [tcpm] New I-D posted : draft-moncaster-tcpm-rcv-cheat-00 From: Michael Welzl To: tcpm@ietf.org, toby.moncaster@bt.com In-Reply-To: References: Content-Type: text/plain Organization: University of Innsbruck Date: Wed, 21 Feb 2007 08:55:59 +0100 Message-Id: <1172044559.3234.38.camel@pc105-c703.uibk.ac.at> Mime-Version: 1.0 X-Mailer: Evolution 2.8.0 (2.8.0-7.fc6) Content-Transfer-Encoding: 7bit X-Spam-Score: () -9.4 ALL_TRUSTED,RCV_SMTP_AUTH,RCV_SMTP_UIBK X-Scanned-By: MIMEDefang 2.58 at uibk.ac.at on 138.232.1.140 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Tue, 2007-02-20 at 17:27 +0000, toby.moncaster@bt.com wrote: > All, > > As you will shortly see we have just posted a new ID called "A TCP Test > To Allow Senders to Identify Receiver Cheating" > draft-moncaster-tcpm-rcv-cheat-00. This draft was written as a result of > (..) > http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html#tcp-rcv-cheat. > > After some background research we decided that an actual nonce would > probably be impractical since it would require modifications to both If you're referring to the ECN nonce, I think that it's not fair to compare this with it (as you also do in the draft), as it additionally tackles a different problem: concealing the reception of an ECN mark is much easier to do / less problematic than optimistic acking / concealing packet loss, and this is what the ECN nonce does but your scheme doesn't. On a side note, the following statement in the draft: > The proposed solution depends, like the skipped segments solution, on > the strict requirement that all TCP receivers have to send a > duplicate acknowledgement as soon as they receive an out-of-order > segment. is at odds with RFC 2581, which says: > Out-of-order data segments SHOULD be acknowledged immediately, in > order to accelerate loss recovery. ...although I wonder why this is only a SHOULD, and not a MUST, and herewith suggest to change this in 2581bis, unless there's a good reason not to do so. Cheers, Michael _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Feb 21 05:23:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJodG-00031a-T5; Wed, 21 Feb 2007 05:23:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJodG-00031U-4s for tcpm@ietf.org; Wed, 21 Feb 2007 05:23:30 -0500 Received: from mail.nuim.ie ([149.157.1.19] helo=LARCH.MAY.IE) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJodC-0001HA-Ot for tcpm@ietf.org; Wed, 21 Feb 2007 05:23:30 -0500 Received: from retina-bcl.hamilton.local ([149.157.192.252]) by NUIM.IE (PMDF V6.2-X17 #30789) with ESMTPA id <01MDE2P5IJCA004API@NUIM.IE> for tcpm@ietf.org; Wed, 21 Feb 2007 10:23:46 +0000 (GMT) Received: from gavinmc by retina-bcl.hamilton.local with local (Exim 4.50) id 1HJod3-0005Tn-6B; Wed, 21 Feb 2007 10:23:17 +0000 Date: Wed, 21 Feb 2007 10:23:17 +0000 From: Gavin McCullagh Subject: Re: [tcpm] New I-D posted : draft-moncaster-tcpm-rcv-cheat-00 In-reply-to: <20070220193652.GZ20215@loompa.cs.umd.edu> To: tcpm@ietf.org Message-id: <20070221102317.GP3162@nuim.ie> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: Mutt/1.5.9i References: <20070220193652.GZ20215@loompa.cs.umd.edu> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Gavin McCullagh List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Hi, On Tue, 20 Feb 2007, Rob Sherwood wrote: > Should people decide that this two phases approach is preferable, it > might be possible to simplify the first phase test as follows. Rather > then reordering segments N-1,N,N+1,..,N+D to N-1,N+1,..,N+D,N as Toby > et. al suggest, it might be better to more frequently perform this test > with D=1, (i.e., simply swap the order of two sequential segments) and > after some threshold number K failures, apply the second phase randomly > skipped segment test. Perhaps I misunderstand, but is it not necessary to have variation in D of at least 0 < D < 4 for the attack to be definitively prevented? The "lazy ack" form of the attack just omits duplicate acks in order that a loss is never detected. If the above were implemented with D=1 it appears that an attacker could always send the first duplicate ack in response to a missing packet but omit the second or third duplicate ack. This would seem to allow the attack to continue but also pass the N-1,N+1,N test. I guess if lots of packets are being lost as part of the attack this kind of precision may be impossible on the part of the attacker so maybe the above is not so important. Gavin _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Feb 21 09:46:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJsio-0002io-Cm; Wed, 21 Feb 2007 09:45:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJsin-0002hy-DA for tcpm@ietf.org; Wed, 21 Feb 2007 09:45:29 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJsim-0008Lz-0B for tcpm@ietf.org; Wed, 21 Feb 2007 09:45:29 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l1LEjNwL014475; Wed, 21 Feb 2007 06:45:23 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 975437FA395; Wed, 21 Feb 2007 09:45:17 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 3D3E01827FD; Wed, 21 Feb 2007 09:44:54 -0500 (EST) To: MURALI BASHYAM From: Mark Allman Subject: Re: [tcpm] New I-D In-Reply-To: <333037.78056.qm@web31715.mail.mud.yahoo.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Cocaine MIME-Version: 1.0 Date: Wed, 21 Feb 2007 09:44:54 -0500 Message-Id: <20070221144454.3D3E01827FD@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: tcpm@ietf.org, weddy@grc.nasa.gov X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0359913429==" Errors-To: tcpm-bounces@ietf.org --===============0359913429== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > It is an implementation to correct a problem caused by > the protocol's REQUIREMENT for a sender to be in an > infinite persistence state, thus allowing for abuse by > a misbehaving receiver side application (or by a lot > of well-behaved receivers). The draft is outlining a > solution to the problem (there could be others). The > idea in the (informational) draft is to highlight to > the group that requirement of the protocol, its > consequences and a possible solution. > > Are you suggesting that any requirements of the > protocol specification that lead to a potential denial > of service type of scenarios and thus causing internal > resource contention, and/or any other network issues > are all to be considered 'implementation' ? Shouldn't > we look at the requirements of the protocol a little > more carefully? Two things: + I think it is a big stretch to say this requirement should hold in resource constrained situations. There are a zillion examples where a system is supposed to do something, but if it can't do it then it can't do it. And, if a system cannot handle all the established + requested connections then something has to give---and, what that is ought to be a policy decision. + If you do want to read the standard as requiring a TCP to keep this connection in the face of everything then you don't need an informational because you cannot change a protocol requirement with an informational. > > And, then why is the proposed solution the right > > one? > > It does solve the problem it sets out to based on a > "total time allowed to be in persist state" type of > cap on the duration. > > Are you implying there could be other behaviours from I am not implying anything. In my previous note I said that a simple timeout is a poor solution to the problem because it does not actually take into account that resources are constrained. Let me try an example... Let's say we set this timer to 10 minutes. A TCP can stay in persist for 10 minutes. Two possibilities: + The 10 minutes goes by and this is the only connection on the machine. Why purge the connection? The ends are both actively still interested and the connection is not causing any problems. (Clearly, we could say this is just the machine's policy---that connections in persist for 10 minutes get purged. And, that is fine if someone wants to do that. But, in this case the connection is posing no problem and so purging the connection is not addressing a problem, just being done due to some sort of house keeping policy.) + The 10 minutes goes by and the machine is heavily loaded and has turned away dozens or hundreds of connections because of this overloaded situation. In this case, purging the connection may offer a little relief and let other connections come in. Maybe these will complete and this is good. Or, maybe this is an attack and so the next connection will just wedge us for another 10 minutes. The point here is that any relief we see from this purging is by happenstance and not because we did something to actually address the resource constraint problem. Why did we wait 10 minutes? Why not 9? Or 11? If we want to deal with resource issues then we need to kick something in when resources are limited. Kicking some connections out at some arbitrary point is just a *hope* that in some cases it will help. What am I missing here? allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFF3FrmWyrrWs4yIs4RAvATAJ9+HITnKKNkjK7WpKL5pzcGF2ZYFACfc5tj NDoM+d0xmnfYdmY36mwy3Js= =yS3C -----END PGP SIGNATURE----- --=_bOundary-- --===============0359913429== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0359913429==-- From tcpm-bounces@ietf.org Wed Feb 21 10:27:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJtNQ-0000yD-Gw; Wed, 21 Feb 2007 10:27:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJtNP-0000y7-4o for tcpm@ietf.org; Wed, 21 Feb 2007 10:27:27 -0500 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJtNJ-0008Lw-LK for tcpm@ietf.org; Wed, 21 Feb 2007 10:27:27 -0500 Received: from I2KF03BV-UKBR.domain1.systemhost.net ([193.113.197.43]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Feb 2007 15:27:13 +0000 Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.65]) by I2KF03BV-UKBR.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Feb 2007 15:27:12 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] New I-D posted : draft-moncaster-tcpm-rcv-cheat-00 Date: Wed, 21 Feb 2007 15:27:11 -0000 Message-ID: In-Reply-To: <1172044559.3234.38.camel@pc105-c703.uibk.ac.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] New I-D posted : draft-moncaster-tcpm-rcv-cheat-00 Thread-Index: AcdVjrmyq9cI+ktXRuiEy/Zir4SLsAAPPPjQ From: To: , X-OriginalArrivalTime: 21 Feb 2007 15:27:12.0946 (UTC) FILETIME=[C2932120:01C755CC] X-Spam-Score: 0.2 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Hi Michael. Just to clarify, I was not talking about the ECN nonce which, as you rightly say, is intended to address a different problem (the concealing of ECN marks). I was actually referring to a solution presented by Stefan Savage et al in the paper "TCP Congestion Control with a Misbehaving Receiver". In this paper they present two versions of a transport layer nonce which they call the "Singular Nonce" and "Cumulative Nonce". We do look at the ECN nonce in the actual draft since that claims to protect against the two attacks our test is designed to identify. Thanks for the pointer as to the slightly surprising wording in RFC2581. As far as I can tell everyone seems to assume this was a MUST anyway...! Toby ________________________________________________________________________ ____ Toby Moncaster, Networks Research Centre, BT Research B54/70 Adastral Park, Martlesham Heath, Ipswich, IP53RE, UK. +44 1473 648734=20 -----Original Message----- From: Michael Welzl [mailto:michael.welzl@uibk.ac.at]=20 Sent: 21 February 2007 07:56 To: tcpm@ietf.org; Moncaster,T,Toby,CXR9 R Subject: Re: [tcpm] New I-D posted : draft-moncaster-tcpm-rcv-cheat-00 On Tue, 2007-02-20 at 17:27 +0000, toby.moncaster@bt.com wrote: > All, >=20 > As you will shortly see we have just posted a new ID called "A TCP=20 > Test To Allow Senders to Identify Receiver Cheating" > draft-moncaster-tcpm-rcv-cheat-00. This draft was written as a result=20 > of > (..) > http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html#tcp-rcv-cheat. >=20 > After some background research we decided that an actual nonce would=20 > probably be impractical since it would require modifications to both If you're referring to the ECN nonce, I think that it's not fair to compare this with it (as you also do in the draft), as it additionally tackles a different problem: concealing the reception of an ECN mark is much easier to do / less problematic than optimistic acking / concealing packet loss, and this is what the ECN nonce does but your scheme doesn't. On a side note, the following statement in the draft: > The proposed solution depends, like the skipped segments solution, on=20 > the strict requirement that all TCP receivers have to send a duplicate > acknowledgement as soon as they receive an out-of-order segment. is at odds with RFC 2581, which says: > Out-of-order data segments SHOULD be acknowledged immediately, in=20 > order to accelerate loss recovery. ...although I wonder why this is only a SHOULD, and not a MUST, and herewith suggest to change this in 2581bis, unless there's a good reason not to do so. Cheers, Michael _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Feb 21 10:46:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJtfi-0001w9-W7; Wed, 21 Feb 2007 10:46:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJtfh-0001w4-SE for tcpm@ietf.org; Wed, 21 Feb 2007 10:46:21 -0500 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJtfc-0003dT-6c for tcpm@ietf.org; Wed, 21 Feb 2007 10:46:21 -0500 Received: from i2kc07-ukbr.domain1.systemhost.net ([193.113.197.14]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Feb 2007 15:46:15 +0000 Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.65]) by i2kc07-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Feb 2007 15:46:12 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] New I-D posted : draft-moncaster-tcpm-rcv-cheat-00 Date: Wed, 21 Feb 2007 15:46:10 -0000 Message-ID: In-Reply-To: <20070220193652.GZ20215@loompa.cs.umd.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] New I-D posted : draft-moncaster-tcpm-rcv-cheat-00 Thread-Index: AcdVKkqHb5mcZeOwQQuhseJdgbNsewApMjOg From: To: X-OriginalArrivalTime: 21 Feb 2007 15:46:12.0022 (UTC) FILETIME=[69845560:01C755CF] X-Spam-Score: 0.2 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Hi Rob, We were under the impression that you were keen that the skipped segments solution be implemented with SACK enabled as otherwise there is a risk that it could delay the notification of congestion by up to 1 RTT more. Apologies if we have got this wrong. The condition we give in 6.2.4 that "Periodically and randomly, any heavily loaded TCP sender SHOULD check the honesty of its receivers using the probabilistic test." wasn't meant to imply that this was the ONLY time a sender should test its receivers. It might be better in a future draft to change it to something wider like:=20 "Any TCP sender SHOULD check the honesty of its receivers using the probabilistic test periodically and randomly. In particular, it would be advantageous for any sender that is heavily loaded to identify if it is taken advantage of by an attack by a dishonest receiver". We would hope that senders would check at other times as well, hence the second bullet point in section 6.2.4. Final point, as Gavin McCullagh has already pointed out, apart from legacy Tahoe TCP implementations a receiver can be reasonably safe if it sends less than 3 duplicate ACKs for a missing segment as this will not trigger fast re-transmit. Consequently we have specified that the displacement should be at least this large. Toby ________________________________________________________________________ ____ Toby Moncaster, Networks Research Centre, BT Research B54/70 Adastral Park, Martlesham Heath, Ipswich, IP53RE, UK. +44 1473 648734=20 -----Original Message----- From: Rob Sherwood [mailto:capveg@cs.umd.edu]=20 Sent: 20 February 2007 19:37 To: Moncaster,T,Toby,CXR9 R Cc: tcpm@ietf.org Subject: Re: [tcpm] New I-D posted : draft-moncaster-tcpm-rcv-cheat-00 On Tue, Feb 20, 2007 at 05:27:03PM -0000, toby.moncaster@bt.com wrote: > All, >=20 > As you will shortly see we have just posted a new ID called "A TCP=20 > Test To Allow Senders to Identify Receiver Cheating" > draft-moncaster-tcpm-rcv-cheat-00. This draft was written as a result=20 > of a request made to Bob Briscoe at IETF 67. There he mentioned to=20 > TVWG that we would be happy to produce a transport layer nonce to=20 > protect against receivers concealing lost packets. This suggestion was > broadly welcomed by the WG and this draft is our response. Initially=20 > we intended to submit this to TSVWG as they requested it. However=20 > after checking with the co-chairs of both TCPM and TSVWG it was agreed > that TCPM would be the best forum for the draft. The draft is=20 > available in various formats at=20 > http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html#tcp-rcv-cheat. Hi Toby, I gave a quick read through the draft on your website, and have a few comments. Section 5.1)=20 I think there might be some confusion here, but the skipped segment solution that we proposed in our paper does not require the receiver supports SACK. Trivially, our paper presents performance results for receivers that do and do not support SACK. If the sender skips segment N, any ACK > N indicates misbehavior; SACK is simply not involved for correctness. If SACK is not supported in the connection, then the standard performance penalties for not implementing SACK apply, i.e., the receiver has to duplicate ACK each loss in turn. Am I missing something here? Section 6.2.4) "Periodically and randomly, any heavily loaded TCP sender SHOULD check the honesty of its receivers using the probabilistic test." I don't think it is sufficient that only heavily loaded TCP senders perform this test. Attackers can simply draw a small amount of traffic from many ("jillions" to quote Mark :-) of servers, not loading any one, but still have a large aggregate amount of traffic. In other words, if the solution is only applied to loaded servers, then the attack still exists. At a high level, I like the proposed two phase test in that it is slightly more efficient then the randomly skipped segment test alone, i.e., instead of honest receivers being penalized 1 RTT every test, they are only penalized the buffer time and 1 RTT if network reordering (pathologically?) undoes the reordering test. It is not clear, to me at least, how the efficiency gain weighs against the additional complexity of code, but presumably others can comment on that. However, my understanding of the concern raised on this list (if I can summarize other's opinions) was that there was a philosophical objection to mucking up[1] the TCP code for an attack which is not being actively exploited. In other words, it wasn't the efficiency of the solution that was at issue, but whether is should be applied at all. Should people decide that this two phases approach is preferable, it might be possible to simplify the first phase test as follows. Rather then reordering segments N-1,N,N+1,..,N+D to N-1,N+1,..,N+D,N as Toby et. al suggest, it might be better to more frequently perform this test with D=3D1, (i.e., simply swap the order of two sequential segments) and after some threshold number K failures, apply the second phase randomly skipped segment test. I only suggest this as the analysis is probably slightly simpler in that the reordering rate of pairs of packets have been previously measured, where as the probability that the N-1,N,N+1,..,N+D to N-1,N+1,..,N+D,N reordering would be undone is less well studied. - Rob . [1] "mucking up" is clearly a technical term :-) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Feb 21 10:47:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJth8-00048E-Oo; Wed, 21 Feb 2007 10:47:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJth6-00047i-Py for tcpm@ietf.org; Wed, 21 Feb 2007 10:47:48 -0500 Received: from lmr1.uibk.ac.at ([138.232.1.142] helo=smtp.uibk.ac.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJth4-00044O-El for tcpm@ietf.org; Wed, 21 Feb 2007 10:47:48 -0500 Received: from [138.232.65.105] (pc105-c703.uibk.ac.at [138.232.65.105] michael.welzl@uibk.ac.at) (authenticated bits=0) by smtp.uibk.ac.at (8.13.8/8.13.1/F1) with ESMTP id l1LFlgDo017222 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 21 Feb 2007 16:47:42 +0100 Subject: RE: [tcpm] New I-D posted : draft-moncaster-tcpm-rcv-cheat-00 From: Michael Welzl To: toby.moncaster@bt.com In-Reply-To: References: Content-Type: text/plain Organization: University of Innsbruck Date: Wed, 21 Feb 2007 16:47:42 +0100 Message-Id: <1172072862.3234.174.camel@pc105-c703.uibk.ac.at> Mime-Version: 1.0 X-Mailer: Evolution 2.8.0 (2.8.0-7.fc6) Content-Transfer-Encoding: 7bit X-Spam-Score: () -9.4 ALL_TRUSTED,RCV_SMTP_AUTH,RCV_SMTP_UIBK X-Scanned-By: MIMEDefang 2.58 at uibk.ac.at on 138.232.1.140 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org > Just to clarify, I was not talking about the ECN nonce which, as you > rightly say, is intended to address a different problem (the concealing > of ECN marks). I was actually referring to a solution presented by > Stefan Savage et al in the paper "TCP Congestion Control with a > Misbehaving Receiver". In this paper they present two versions of a > transport layer nonce which they call the "Singular Nonce" and > "Cumulative Nonce". We do look at the ECN nonce in the actual draft > since that claims to protect against the two attacks our test is > designed to identify. Hm, I always thought that the nonce in this paper by Stefan Savage is the ancestor of the ECN nonce, but maybe there's a small but significant difference there > Thanks for the pointer as to the slightly surprising wording in RFC2581. > As far as I can tell everyone seems to assume this was a MUST anyway...! ...and I would expect most implementations to conform with this interpretation - so it would be interesting to learn the reasoning behind the SHOULD. This is not the first time that I'm surprised by something in RFC 2581, and so far, it always turned out that there was a good reason for everything. It's just full of such intricacies :) Cheers, Michael _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Feb 21 12:33:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJvKl-0002tj-61; Wed, 21 Feb 2007 12:32:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJvKj-0002tU-89 for tcpm@ietf.org; Wed, 21 Feb 2007 12:32:49 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJvKg-0007qz-S5 for tcpm@ietf.org; Wed, 21 Feb 2007 12:32:49 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 21 Feb 2007 09:32:46 -0800 X-IronPort-AV: i="4.14,202,1170662400"; d="scan'208"; a="362087811:sNHT47105956" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l1LHWkip028938; Wed, 21 Feb 2007 09:32:46 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l1LHWgGo002898; Wed, 21 Feb 2007 09:32:42 -0800 (PST) Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Feb 2007 09:32:21 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] New I-D posted : draft-moncaster-tcpm-rcv-cheat-00 Date: Wed, 21 Feb 2007 09:32:19 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC5802E88736@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <1172044559.3234.38.camel@pc105-c703.uibk.ac.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] New I-D posted : draft-moncaster-tcpm-rcv-cheat-00 Thread-Index: AcdVjh3RvuGIzFFcTXyHIceGAU6CBgAQ7L3g From: "Anantha Ramaiah \(ananth\)" To: "Michael Welzl" , , X-OriginalArrivalTime: 21 Feb 2007 17:32:21.0476 (UTC) FILETIME=[3E01E240:01C755DE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1343; t=1172079166; x=1172943166; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20\(ananth\)=22=20 |Subject:=20RE=3A=20[tcpm]=20New=20I-D=20posted=20=3A=20=20draft-moncaste r-tcpm-rcv-cheat-00 |Sender:=20; bh=7HYR+Bi/nLRJrXfRBKKr9yQ9sJHP9kgjBUOHXpREMMI=; b=ktpWrIgnvDGuMiSG5nl5fOo6kefbT1SDdt2fBZFqilMJvihQB+NngNl0TYCfjWHqUF0ZaoWN 9nDmMH7Xt1UppZSoF6n0Xnhem8bZOTEi1ZcNU/wVfDrmp+n189xXTEmv; Authentication-Results: sj-dkim-2; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org =20 >=20 > is at odds with RFC 2581, which says: >=20 > > Out-of-order data segments SHOULD be acknowledged immediately, in=20 > > order to accelerate loss recovery. >=20 > ...although I wonder why this is only a SHOULD, and not a=20 > MUST, and herewith suggest to change this in 2581bis, unless=20 > there's a good reason not to do so. Although the RFC says SHOULD, in reality it is treated as a MUST, I think the majority of stacks will send a ack for a out-of-order segment. It probably makes sense to make this a MUST in RFC 2581bis if we want to enforce some basic congestion control stuff like fast-retransmissions (which is worded as a MUST by the way). The only reason which I can think off why it was worded as a SHOULD instead of a MUST is when the basic cong.control on TCP was written long time back, "putting" many packets (even if they serve some useful purpose) was probably considered aggressive, in the current context pure ACK's. I am sure there are folks in the list who may have better answers.=20 OTOH, recently, we were discussing about rate-limiting the no. of duplicate ACK's from mis-behaving receivers in the context of RFC 2581bis, now there is a mention about "some-receivers-that-may-exist-who-don't-send-duplicate-acks-for-out-of- order-segments-received"=20 :-) -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Feb 21 13:34:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJwHO-00086s-FK; Wed, 21 Feb 2007 13:33:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJwHN-00086l-LI for tcpm@ietf.org; Wed, 21 Feb 2007 13:33:25 -0500 Received: from circular.cs.umd.edu ([128.8.128.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJwHM-0006xB-C9 for tcpm@ietf.org; Wed, 21 Feb 2007 13:33:25 -0500 Received: from loompa.cs.umd.edu (loompa.cs.umd.edu [128.8.128.63]) by circular.cs.umd.edu (8.12.11.20060308/8.12.5) with ESMTP id l1LIXNFt020496; Wed, 21 Feb 2007 13:33:23 -0500 Received: (from capveg@localhost) by loompa.cs.umd.edu (8.12.10/8.12.5) id l1LIXNXC025097; Wed, 21 Feb 2007 13:33:23 -0500 (EST) Date: Wed, 21 Feb 2007 13:33:23 -0500 From: Rob Sherwood To: Gavin McCullagh Subject: Re: [tcpm] New I-D posted : draft-moncaster-tcpm-rcv-cheat-00 Message-ID: <20070221183323.GG20215@loompa.cs.umd.edu> References: <20070220193652.GZ20215@loompa.cs.umd.edu> <20070221102317.GP3162@nuim.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070221102317.GP3162@nuim.ie> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Wed, Feb 21, 2007 at 10:23:17AM +0000, Gavin McCullagh wrote: > Hi, > > On Tue, 20 Feb 2007, Rob Sherwood wrote: > > > Should people decide that this two phases approach is preferable, it > > might be possible to simplify the first phase test as follows. Rather > > then reordering segments N-1,N,N+1,..,N+D to N-1,N+1,..,N+D,N as Toby > > et. al suggest, it might be better to more frequently perform this test > > with D=1, (i.e., simply swap the order of two sequential segments) and > > after some threshold number K failures, apply the second phase randomly > > skipped segment test. > > Perhaps I misunderstand, but is it not necessary to have variation in D of > at least > 0 < D < 4 > for the attack to be definitively prevented? > > The "lazy ack" form of the attack just omits duplicate acks in order that a > loss is never detected. If the above were implemented with D=1 it appears > that an attacker could always send the first duplicate ack in response to a > missing packet but omit the second or third duplicate ack. This would seem > to allow the attack to continue but also pass the N-1,N+1,N test. > > I guess if lots of packets are being lost as part of the attack this kind > of precision may be impossible on the part of the attacker so maybe the > above is not so important. Your last paragraph sums it up correctly, IMHO. If the receiver is actually receiving all packets, then of course it can defeat any test -- but then there is no attack. With Lazy ack, if the receiver were dropping some constant percentage of packets p, then over n tests, we can expect the receiver to fail p*n tests, and this solution can be engineered so that k (the number of failed tests before phase 2) is chosen to prevent the amplification rate from being too high. In an alternate attack, the attacker could duplicate ack all packets, but then the amplication factor suffers (1 data packet/(D+1) acks == 1500/(D+1)*40 == 37.5x/(D+1)). Maybe it does make sense to consider D>1 such that the amplification factor suffers more. Obviously, D>37, i.e., the value the prevents *any* amplification, is too large for practical considerations, but it does make the case for a larger value of D (contrary to what I was suggesting earlier). - Rob . _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Feb 21 14:13:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJwtn-00034d-TC; Wed, 21 Feb 2007 14:13:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJwtm-00034Y-Na for tcpm@ietf.org; Wed, 21 Feb 2007 14:13:06 -0500 Received: from web31707.mail.mud.yahoo.com ([68.142.201.187]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HJwtj-0007TG-8a for tcpm@ietf.org; Wed, 21 Feb 2007 14:13:06 -0500 Received: (qmail 61400 invoked by uid 60001); 21 Feb 2007 19:13:02 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=MStrrZ3ZXGqI/Uwwi+khj5mZMhJ6LZhRtC8gM+vW1LMvLzRBRuqhgkIeDrIP4tdF2/1sRyRE+KeouVqJ4T+31Bf2L78Bod1kP6uw4bbWzp3x9xb/S+yKZZlXJivpgJWXiqyIM+lUQ9QpQRpmalXgqDqw9S+MI7da/2b7rLBsz4Q=; X-YMail-OSG: vUDOyjMVM1n7Q8kmf.ZyrJnwG.3I.ZqF938OyAiVdxuZtnZKW47WvJv2bRii_Td8KrRmIbT20wumYpJ29xqKEyELpg.BMbHzw9lH2c5rusSE2SPkytoA6RTRMM.CPcMR31fX_wWpVHx54ps- Received: from [69.28.107.2] by web31707.mail.mud.yahoo.com via HTTP; Wed, 21 Feb 2007 11:13:02 PST Date: Wed, 21 Feb 2007 11:13:02 -0800 (PST) From: MURALI BASHYAM Subject: Re: [tcpm] New I-D To: mallman@icir.org In-Reply-To: <20070221144454.3D3E01827FD@lawyers.icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <584178.60890.qm@web31707.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: tcpm@ietf.org, weddy@grc.nasa.gov X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org --- Mark Allman wrote: > > > It is an implementation to correct a problem > caused by > > the protocol's REQUIREMENT for a sender to be in > an > > infinite persistence state, thus allowing for > abuse by > > a misbehaving receiver side application (or by a > lot > > of well-behaved receivers). The draft is outlining > a > > solution to the problem (there could be others). > The > > idea in the (informational) draft is to highlight > to > > the group that requirement of the protocol, its > > consequences and a possible solution. > > > > Are you suggesting that any requirements of the > > protocol specification that lead to a potential > denial > > of service type of scenarios and thus causing > internal > > resource contention, and/or any other network > issues > > are all to be considered 'implementation' ? > Shouldn't > > we look at the requirements of the protocol a > little > > more carefully? > > Two things: > > + I think it is a big stretch to say this > requirement should hold in > resource constrained situations. There are a > zillion examples where > a system is supposed to do something, but if it > can't do it then it > can't do it. And, if a system cannot handle all > the established + > requested connections then something has to > give---and, what that is > ought to be a policy decision. > > + If you do want to read the standard as requiring > a TCP to keep this > connection in the face of everything then you > don't need an > informational because you cannot change a > protocol requirement with > an informational. > I am not sure what the status of the draft is supposed to be, would experimental be a more appropriate status? Aside from the status of the draft, the more fundamental point is whether we agree that this is a protocol specific requirement leading to a problem for which there is a protocol specific/aware solution we can put in place. > > > And, then why is the proposed solution the right > > > one? > > > > It does solve the problem it sets out to based on > a > > "total time allowed to be in persist state" type > of > > cap on the duration. > > > > Are you implying there could be other behaviours > from > > I am not implying anything. In my previous note I > said that a simple > timeout is a poor solution to the problem because it > does not actually > take into account that resources are constrained. > > Let me try an example... Let's say we set this > timer to 10 minutes. A > TCP can stay in persist for 10 minutes. Two > possibilities: > > + The 10 minutes goes by and this is the only > connection on the > machine. > > Why purge the connection? The ends are both > actively still > interested and the connection is not causing any > problems. > > (Clearly, we could say this is just the > machine's policy---that > connections in persist for 10 minutes get > purged. And, that is fine > if someone wants to do that. But, in this case > the connection is > posing no problem and so purging the connection > is not addressing a > problem, just being done due to some sort of > house keeping policy.) > > + The 10 minutes goes by and the machine is > heavily loaded and has > turned away dozens or hundreds of connections > because of this > overloaded situation. > > In this case, purging the connection may offer a > little relief and > let other connections come in. Maybe these will > complete and this > is good. Or, maybe this is an attack and so the > next connection > will just wedge us for another 10 minutes. > > The point here is that any relief we see from > this purging is by > happenstance and not because we did something to > actually address > the resource constraint problem. Why did we > wait 10 minutes? Why > not 9? Or 11? If we want to deal with resource > issues then we need > to kick something in when resources are limited. > Kicking some > connections out at some arbitrary point is just > a *hope* that in > some cases it will help. > > What am I missing here? I thought we agreed that a resource based demand driven scheme (based on who has been idle for the longest time) can be used on top of the timeout based policy scheme. Doesn't that address the issue are raising here? Thx, Murali > > allman > > > > ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Feb 21 14:16:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJwxD-0003h2-LR; Wed, 21 Feb 2007 14:16:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJwxB-0003gI-7l for tcpm@ietf.org; Wed, 21 Feb 2007 14:16:37 -0500 Received: from mms3.broadcom.com ([216.31.210.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJwx9-0008UQ-QI for tcpm@ietf.org; Wed, 21 Feb 2007 14:16:37 -0500 Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.0)); Wed, 21 Feb 2007 11:16:21 -0800 X-Server-Uuid: 9206F490-5C8F-4575-BE70-2AAA8A3D4853 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 0D13D2AF; Wed, 21 Feb 2007 11:16:21 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id ED2122AE; Wed, 21 Feb 2007 11:16:20 -0800 (PST) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EYP93575; Wed, 21 Feb 2007 11:16:16 -0800 (PST) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 2578720502; Wed, 21 Feb 2007 11:16:16 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] New I-D posted : draft-moncaster-tcpm-rcv-cheat-00 Date: Wed, 21 Feb 2007 11:16:14 -0800 Message-ID: <54AD0F12E08D1541B826BE97C98F99F101193858@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: Thread-Topic: [tcpm] New I-D posted : draft-moncaster-tcpm-rcv-cheat-00 Thread-Index: AcdUM1p48JkJlkW1QDC5NeLHuwq6tgAABe+wADfFPnAANXgAgA== From: "Caitlin Bestler" To: toby.moncaster@bt.com, tcpm@ietf.org X-WSS-ID: 69C2450F3Y826066982-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.6 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org I am very skeptical that there is a transport layer problem here, as opposed to an application layer problem. Basically, I do not accept the following premise: A large server relies on honest network congestion feedback to efficiently apportion its own resources between receivers. If such a large server devotes an excessive fraction of its own resources to misbehaving receivers, it may well hit its own resource limits and have to starve other half-connections even if their network path has spare capacity. I would rather contend: A large server does not rely on network congestion feedback alone to efficiently apportion its own resources between receivers. If such a large receiver devotes an excessive fraction of its own resources to any receiver (whether misbehaving, malicious or=20 merely greedy) it may well hit its own resource limits and have to starve other half-connections even if their network path has spare capacity. A server application that is willing to transmit multi-megabit flows to an anonymous client based solely on the alleged receive capacity of the receiver is so gullible it almost qualifies as a "willing accomplice". My understanding of this problem assumes the following: DoS attacks that seek to cause a server to send very large streams, and thereby cause local congestion at the server end, require establishing actual connections. Therefore the source of the attack is traceable. An attacker is unlikely to use their own machine for a traceable attack. Therefore these attacks would be launched from compromised machines, from a botnet. A compromised machine can already be used to "honestly" receive a stream at the compromised machine's capacity rate. The installed malware can simply throw the traffic away with very low CPU overhead. If clever, it can limit the rate to a fraction of the local bandwidth to avoid arousing suspicion of the machine's legitimate owner. Therefore the proposed test is intended as a countermeasure against attackers seeking to use optimistic acking to get a multiplier effect. By committing virtually all of the local machines receive bandwidth it can get the server to commit several times that on the server's local network. The fake receiver will ack packets that are actually reeived as though all prior packets had been received. An optimal attacker would probably simulate a long NAPI poll cycle of 100 HZ and ack the highest TCP sequence received ignoring all gaps. It would thereby simulate the behavior of an honest receiver that consolidated ACKs on a 100 HZ collection cycle. An important constraint is that the attacker wants to generate no fewer acks than an honest receiver actually receiving the packets would have. The greatest ACK to receive ratio that I can think of, this is also legitimate, occurs when an honest receiver generates a single ACK for all traffic received in a collection period. A receiver that is generating ACKs less frequently than every other sent packet or 100HZ AND is claiming that the connection is experiencing no congestion is inherently suspicious. Even if it manages to be RFC compliant, the sender is under no obligation to continue sending traffic to this client at higher and higher rates. This is especially true since even with the proposed test, an attacker can=20 always recruit compromised attackers to act as a bit bucket drain at typical home broadband rates. Since the goal of optimistic acking is to get a multiplier effect, the rates in question would be several times higher than typical home broadband capacities. So wouldn't having the application layer merely cap individual flows to anonymous clients be just as effective a counter-measure as fiddling with TCP? And wouldn't it be less harmful? The proposed test *is* harmful. It artifically increases the amount of packet re-ordering in the network. Receivers may already have engineered resources to provide resilient responses to re-ordered packets. Artificially caused packet reordering as a routine test eats away at those safety margins. And the duplicate acks generated ARE excess traffic. As an *administrative* test done when a flow already appears suspicious there would be no real problem. But as a routine test to determine when a flow is suspicious there is an inherent problem. Either the test is performed too seldom to be effective, or it is performed frequently enough to have a measurable impact on the performance of at least some receivers. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Feb 21 15:48:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJyNI-0004Mt-Ai; Wed, 21 Feb 2007 15:47:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJyNH-0004LU-KA for tcpm@ietf.org; Wed, 21 Feb 2007 15:47:39 -0500 Received: from mms2.broadcom.com ([216.31.210.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJyNG-0008Ma-8O for tcpm@ietf.org; Wed, 21 Feb 2007 15:47:39 -0500 Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.0)); Wed, 21 Feb 2007 12:47:22 -0800 X-Server-Uuid: 05DA3F36-9AA8-4766-A7E5-53B43A7C42E6 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 85CE42AF; Wed, 21 Feb 2007 12:47:22 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 71C682AE; Wed, 21 Feb 2007 12:47:22 -0800 (PST) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EYQ11626; Wed, 21 Feb 2007 12:47:21 -0800 (PST) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 46A9020502; Wed, 21 Feb 2007 12:47:21 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] New I-D Date: Wed, 21 Feb 2007 12:47:20 -0800 Message-ID: <54AD0F12E08D1541B826BE97C98F99F101193892@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <584178.60890.qm@web31707.mail.mud.yahoo.com> Thread-Topic: [tcpm] New I-D Thread-Index: AcdV7G9cW6UU9A9cQNKyUApCFbMEeQADEKvA From: "Caitlin Bestler" To: "MURALI BASHYAM" X-WSS-ID: 69C2705028C4947306-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: tcpm@ietf.org, weddy@grc.nasa.gov X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org MURALI BASHYAM wrote: >=20 > I am not sure what the status of the draft is supposed to be, > would experimental be a more appropriate status? > Aside from the status of the draft, the more fundamental > point is whether we agree that this is a protocol specific > requirement leading to a problem for which there is a > protocol specific/aware solution we can put in place. >=20 I have always assumed the following: Any application MAY disconnect from any peer when it no longer finds maintaining the connection with the peer to be of value. An application SHOULD disconnect from any peer when continued support of that peer will have an adverse impact on other connections, especially when the peer is acting suspiciously. Therefore any application MAY and perhaps SHOULD disconnect from a suspiciously idle peer, especially before maintaining the idle connection adversely impacts active connections. Are you suggesting that there is anything in any protocol requirement that contradicts this? _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Feb 21 17:34:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HK01z-0003G8-Kt; Wed, 21 Feb 2007 17:33:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HK01x-0003FL-PE for tcpm@ietf.org; Wed, 21 Feb 2007 17:33:45 -0500 Received: from circular.cs.umd.edu ([128.8.128.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJzyi-0006b6-2R for tcpm@ietf.org; Wed, 21 Feb 2007 17:30:25 -0500 Received: from loompa.cs.umd.edu (loompa.cs.umd.edu [128.8.128.63]) by circular.cs.umd.edu (8.12.11.20060308/8.12.5) with ESMTP id l1LMUMgT005718; Wed, 21 Feb 2007 17:30:22 -0500 Received: (from capveg@localhost) by loompa.cs.umd.edu (8.12.10/8.12.5) id l1LMUIDq007503; Wed, 21 Feb 2007 17:30:18 -0500 (EST) Date: Wed, 21 Feb 2007 17:30:17 -0500 From: Rob Sherwood To: toby.moncaster@bt.com Subject: Re: [tcpm] New I-D posted : draft-moncaster-tcpm-rcv-cheat-00 Message-ID: <20070221223017.GI20215@loompa.cs.umd.edu> References: <20070220193652.GZ20215@loompa.cs.umd.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Wed, Feb 21, 2007 at 03:46:10PM -0000, toby.moncaster@bt.com wrote: > Hi Rob, > > We were under the impression that you were keen that the skipped > segments solution be implemented with SACK enabled as otherwise there is > a risk that it could delay the notification of congestion by up to 1 RTT > more. Apologies if we have got this wrong. I'm not sure that I see that risk. I think both this point and the point below rely on the same aspect of TCP: when an out of order segment arrives, the receiver immediately sends a duplicate ACK for the previously acknowledged segment. Thus, as long as the receiver sends a single duplicate ack for the skipped segment, then the sender know it is honest. Because there is no delay in the dup ack generation, the penalty for receiving the skipped segment is at most 1 RTT. > "Any TCP sender SHOULD check the honesty of its receivers using the > probabilistic test periodically and randomly. In particular, it would be > advantageous for any sender that is heavily loaded to identify if it is > taken advantage of by an attack by a dishonest receiver". This wording is definitely clearer. > Final point, as Gavin McCullagh has already pointed out, apart from > legacy Tahoe TCP implementations a receiver can be reasonably safe if it > sends less than 3 duplicate ACKs for a missing segment as this will not > trigger fast re-transmit. Consequently we have specified that the > displacement should be at least this large. Maybe I'm the one who is confused, but as I understand it, a single duplicate ACK (for the correct segment) is enough to differentiate an honest receiver from a malicious one, so why do you need multiple duplicate acks? Fast retransmit should never be an issue, because the sender should not perform congestion control in response to a malicious receiver test. - Rob . _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Feb 21 17:38:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HK067-00027x-El; Wed, 21 Feb 2007 17:38:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HK066-0001we-9q for tcpm@ietf.org; Wed, 21 Feb 2007 17:38:02 -0500 Received: from mailer1.psc.edu ([128.182.58.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HK061-0007oA-Up for tcpm@ietf.org; Wed, 21 Feb 2007 17:38:02 -0500 Received: from [128.182.160.132] (ice.psc.edu [128.182.160.132]) (authenticated bits=0) by mailer1.psc.edu (8.13.8/8.13.3) with ESMTP id l1LMbnRl013562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Feb 2007 17:37:50 -0500 (EST) Message-ID: <45DCC9BB.4010302@psc.edu> Date: Wed, 21 Feb 2007 17:37:47 -0500 From: John Heffner User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: tcpm@ietf.org Subject: Re: [tcpm] New I-D References: <20070221144454.3D3E01827FD@lawyers.icir.org> In-Reply-To: <20070221144454.3D3E01827FD@lawyers.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: weddy@grc.nasa.gov, mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org I think I agree with Wes, David and Mark that this is more of an OS than a protocol issue (if I'm characterizing their comments correctly), and Fernando that the approach is not powerful enough to solve the broader problem when viewed as an attack. To expand a bit, I had a hallway conversation a couple years ago with Stanislav Shalunov about his netkill [1] attack, and more generally about contention for send buffer memory. (I think the problem you're addressing falls precisely into this broader category.) What I took away from this (Stas may or may not agree) is that since the resource contention occurs at the operating system level (competing for scarce kernel memory), that is the right place to arbitrate the contention. Each host may want to apply a different policy based on what it considers important. As proof of concept, I wrote up a simple script (I think only about 30 lines of python) that used the TCP ESTATS MIB to monitor connections, and kill off ones making no progress while consuming the most memory. This proved an effective defense against netkill, and I think would solve the problem described in the draft as well. It would be easy enough to write a kernel thread to do the same if the system doesn't do ESTATS. -John [1] http://shlang.com/netkill/ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Feb 21 18:20:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HK0kq-0007Br-U1; Wed, 21 Feb 2007 18:20:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HK0kp-0007Af-LX for tcpm@ietf.org; Wed, 21 Feb 2007 18:20:07 -0500 Received: from mailer1.psc.edu ([128.182.58.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HK0ko-0006Kr-82 for tcpm@ietf.org; Wed, 21 Feb 2007 18:20:07 -0500 Received: from [128.182.160.132] (ice.psc.edu [128.182.160.132]) (authenticated bits=0) by mailer1.psc.edu (8.13.8/8.13.3) with ESMTP id l1LNJwXC004474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Feb 2007 18:19:58 -0500 (EST) Message-ID: <45DCD39C.60005@psc.edu> Date: Wed, 21 Feb 2007 18:19:56 -0500 From: John Heffner User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: tcpm@ietf.org Subject: Re: [tcpm] New I-D posted : draft-moncaster-tcpm-rcv-cheat-00 References: <0C53DCFB700D144284A584F54711EC5802E88736@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC5802E88736@xmb-sjc-21c.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: "Anantha Ramaiah \(ananth\)" , Michael Welzl X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Anantha Ramaiah (ananth) wrote: > > >> is at odds with RFC 2581, which says: >> >>> Out-of-order data segments SHOULD be acknowledged immediately, in >>> order to accelerate loss recovery. >> ...although I wonder why this is only a SHOULD, and not a >> MUST, and herewith suggest to change this in 2581bis, unless >> there's a good reason not to do so. > > Although the RFC says SHOULD, in reality it is treated as a MUST, I > think the majority of stacks will send a ack for a out-of-order segment. > It probably makes sense to make this a MUST in RFC 2581bis if we want to > enforce some basic congestion control stuff like fast-retransmissions > (which is worded as a MUST by the way). > > The only reason which I can think off why it was worded as a SHOULD > instead of a MUST is when the basic cong.control on TCP was written long > time back, "putting" many packets (even if they serve some useful > purpose) was probably considered aggressive, in the current context pure > ACK's. I am sure there are folks in the list who may have better > answers. > > OTOH, recently, we were discussing about rate-limiting the no. of > duplicate ACK's from mis-behaving receivers in the context of RFC > 2581bis, now there is a mention about > "some-receivers-that-may-exist-who-don't-send-duplicate-acks-for-out-of- > order-segments-received" I would be reluctant to change this to a MUST. A few things that come to mind: As you mention, some receivers might want to adopt a slightly different ACK strategy if there's persistent reordering, to avoid having to ACK every packet in steady state, and to prevent triggering fast retransmit on senders that don't do NCR (RFC4653) or similar. In CPU- or interrupt-bound senders, suddenly doubling the rate of ACKs it must process can have adverse effects on performance. It might make sense for some high-performance flows with large windows to do delayed ACK all the time. (With large windows and a low loss rate, there's little risk.) Paths with severe asymmetry may want to thin ACKs. There were some papers on this in the mid to late 90's coming out of work with satellites and ADSL. There's been some talk lately about reverse path congestion control. (This would be much harder with TCP than DCCP, but maybe someone can figure it out?) Some of this stuff might be hair-brained or not, but we don't want to restrict flexibility unless it's really necessary. -John _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Feb 21 20:13:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HK2WP-00049V-Rr; Wed, 21 Feb 2007 20:13:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HK2WO-0003ws-2S for tcpm@ietf.org; Wed, 21 Feb 2007 20:13:20 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HK2WL-0007r4-GA for tcpm@ietf.org; Wed, 21 Feb 2007 20:13:20 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-2.cisco.com with ESMTP; 21 Feb 2007 17:13:17 -0800 X-IronPort-AV: i="4.14,203,1170662400"; d="scan'208"; a="362220889:sNHT54713548" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l1M1DGDK009746; Wed, 21 Feb 2007 17:13:17 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l1M1DGhq023922; Wed, 21 Feb 2007 17:13:16 -0800 (PST) Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Feb 2007 17:13:16 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] New I-D posted : draft-moncaster-tcpm-rcv-cheat-00 Date: Wed, 21 Feb 2007 17:13:14 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC5802E88AD8@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <45DCD39C.60005@psc.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] New I-D posted : draft-moncaster-tcpm-rcv-cheat-00 Thread-Index: AcdWDte6ps6oE3fNRvCGhOdkMrH+gQACmrbg From: "Anantha Ramaiah \(ananth\)" To: "John Heffner" , X-OriginalArrivalTime: 22 Feb 2007 01:13:16.0582 (UTC) FILETIME=[A1BC2C60:01C7561E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4593; t=1172106797; x=1172970797; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20\(ananth\)=22=20 |Subject:=20RE=3A=20[tcpm]=20New=20I-D=20posted=20=3A=20=20draft-moncaste r-tcpm-rcv-cheat-00 |Sender:=20; bh=9JulF82OT85Uhpgv/X5OVhCMaAZoUES9/0axbm3Q+3k=; b=Gf7IYbDVLUZ3hu5WY1pK6kiE31kQ07EgKIwdcVJrkSfrVyt/kPAEoSIY72lnkcTq4TAL48N6 KqTOI2H09zFO40kvxsqsbR0Mr4CFjbfQKl1P8xEuyuqf5i1Kl5/VtsZt; Authentication-Results: sj-dkim-7; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: Michael Welzl X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org =20 > -----Original Message----- > From: John Heffner [mailto:jheffner@psc.edu]=20 > Sent: Wednesday, February 21, 2007 3:20 PM > To: tcpm@ietf.org > Cc: Anantha Ramaiah (ananth); Michael Welzl; toby.moncaster@bt.com > Subject: Re: [tcpm] New I-D posted : draft-moncaster-tcpm-rcv-cheat-00 >=20 > Anantha Ramaiah (ananth) wrote: > > =20 > >=20 > >> is at odds with RFC 2581, which says: > >> > >>> Out-of-order data segments SHOULD be acknowledged immediately, in=20 > >>> order to accelerate loss recovery. > >> ...although I wonder why this is only a SHOULD, and not a=20 > MUST, and=20 > >> herewith suggest to change this in 2581bis, unless there's a good=20 > >> reason not to do so. > >=20 > > Although the RFC says SHOULD, in reality it is treated as a MUST, I=20 > > think the majority of stacks will send a ack for a=20 > out-of-order segment. > > It probably makes sense to make this a MUST in RFC 2581bis=20 > if we want=20 > > to enforce some basic congestion control stuff like=20 > > fast-retransmissions (which is worded as a MUST by the way). > >=20 > > The only reason which I can think off why it was worded as a SHOULD=20 > > instead of a MUST is when the basic cong.control on TCP was written=20 > > long time back, "putting" many packets (even if they serve=20 > some useful > > purpose) was probably considered aggressive, in the current context=20 > > pure ACK's. I am sure there are folks in the list who may=20 > have better=20 > > answers. > >=20 > > OTOH, recently, we were discussing about rate-limiting the no. of=20 > > duplicate ACK's from mis-behaving receivers in the context of RFC=20 > > 2581bis, now there is a mention about > >=20 > "some-receivers-that-may-exist-who-don't-send-duplicate-acks-for-out-o > > f- > > order-segments-received"=20 >=20 >=20 > I would be reluctant to change this to a MUST. A few things=20 > that come to mind: >=20 >=20 > As you mention, some receivers might want to adopt a slightly=20 > different=20 > ACK strategy if there's persistent reordering, to avoid having to ACK=20 > every packet in steady state, and to prevent triggering fast=20 > retransmit=20 > on senders that don't do NCR (RFC4653) or similar. I am not aware of receivers that rate limit the ACK's due to the fact that there was persistent re-ordering in the network. YMMV. >=20 > In CPU- or interrupt-bound senders, suddenly doubling the=20 > rate of ACKs=20 > it must process can have adverse effects on performance. It Well, I would classify this as the problem of the receiver which isn't able to process these ACK's. So, if I understand what you are saying correctly, if the peer to that receiver isn't sending a duplicate ACK for every out-of-order packet received, things would work well in this particular case, in cases if it peers with a box (host/router any TCP device) which follws the SHOULD clause seriously and ack's every other out-of-order-packet, then the receiver is in trouble? After all the receiver can chose to drop the ACK, when it detects conditions that effect performance. It is not rocket-sicence to implement performance monitors and take corrective actions. >=20 > Paths with severe asymmetry may want to thin ACKs. There were some=20 > papers on this in the mid to late 90's coming out of work with=20 > satellites and ADSL. Ok. >=20 > There's been some talk lately about reverse path congestion control.=20 > (This would be much harder with TCP than DCCP, but maybe someone can=20 > figure it out?) By reverse path, you mean ACK congestion control? Data transfer can be bi-directional. >=20 >=20 > Some of this stuff might be hair-brained or not, but we don't want to=20 > restrict flexibility unless it's really necessary. I agree. My point ( I haven't surveyed the whole internet/intranets obviously) is :- - since it is believed that most of the stacks existing today, ACKs every out-of-order segment it received, "SHOULD" clause has been in the experimental stage for a while.. - The internet has changed a long way what it was 20+ years back when the original TCP specs were written and some of the assumptions that were made are no longer commonplace. In other words the assumptions which were common has become rare today. Hence my thinking ( I know some folks wouldn't like it) is we don't lose much by changing it. May be we don't lose much by not changing ( except that we would be in a situation of not refelecting the common practice in the standards) as well :-) -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Feb 22 02:28:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HK8MJ-0000CZ-Eg; Thu, 22 Feb 2007 02:27:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HK8MH-0000Ba-EV for tcpm@ietf.org; Thu, 22 Feb 2007 02:27:17 -0500 Received: from lmr1.uibk.ac.at ([138.232.1.142] helo=smtp.uibk.ac.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HK8MF-0003CH-VR for tcpm@ietf.org; Thu, 22 Feb 2007 02:27:17 -0500 Received: from [138.232.65.105] (pc105-c703.uibk.ac.at [138.232.65.105] michael.welzl@uibk.ac.at) (authenticated bits=0) by smtp.uibk.ac.at (8.13.8/8.13.1/F1) with ESMTP id l1M7R66T032106 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 22 Feb 2007 08:27:06 +0100 Subject: RE: [tcpm] New I-D posted : draft-moncaster-tcpm-rcv-cheat-00 From: Michael Welzl To: "Anantha Ramaiah (ananth)" In-Reply-To: <0C53DCFB700D144284A584F54711EC5802E88AD8@xmb-sjc-21c.amer.cisco.com> References: <0C53DCFB700D144284A584F54711EC5802E88AD8@xmb-sjc-21c.amer.cisco.com> Content-Type: text/plain Organization: University of Innsbruck Date: Thu, 22 Feb 2007 08:27:06 +0100 Message-Id: <1172129226.3233.4.camel@pc105-c703.uibk.ac.at> Mime-Version: 1.0 X-Mailer: Evolution 2.8.0 (2.8.0-7.fc6) Content-Transfer-Encoding: 7bit X-Spam-Score: () -9.4 ALL_TRUSTED,RCV_SMTP_AUTH,RCV_SMTP_UIBK X-Scanned-By: MIMEDefang 2.58 at uibk.ac.at on 138.232.1.140 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org > > There's been some talk lately about reverse path congestion control. > > (This would be much harder with TCP than DCCP, but maybe someone can > > figure it out?) > > By reverse path, you mean ACK congestion control? Data transfer can be > bi-directional. Funny enough, I stumbled over this SHOULD when thinking about ACK congestion control, where it could be useful for the sender to be able to count the number of ACKs that the receiver would normally have to send during a loss period. In any case, it's the concern of a new mechanism, yet to be specified, how to do ACK congestion control, and not the concern of RFC 2581 - using a SHOULD instead of a MUST for sending ACKs to out-of-order segments doesn't implement or even help ACK congestion control, but it actually seems to be a hindrance. Cheers, Michael _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Feb 22 11:18:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKGdg-0005Cv-0j; Thu, 22 Feb 2007 11:17:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKGdf-00056p-42 for tcpm@ietf.org; Thu, 22 Feb 2007 11:17:47 -0500 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKGdX-00025l-Ki for tcpm@ietf.org; Thu, 22 Feb 2007 11:17:47 -0500 Received: from I2KF03BV-UKBR.domain1.systemhost.net ([193.113.197.43]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Feb 2007 16:17:38 +0000 Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.65]) by I2KF03BV-UKBR.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Feb 2007 16:17:38 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] New I-D posted : draft-moncaster-tcpm-rcv-cheat-00 Date: Thu, 22 Feb 2007 16:17:37 -0000 Message-ID: In-Reply-To: <20070221223017.GI20215@loompa.cs.umd.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] New I-D posted : draft-moncaster-tcpm-rcv-cheat-00 Thread-Index: AcdWB+FJ/zzDETHlRjSl+0yp7zDJCQAi7FHA From: To: X-OriginalArrivalTime: 22 Feb 2007 16:17:38.0336 (UTC) FILETIME=[F842C200:01C7569C] X-Spam-Score: 0.2 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Hi Rob, The rationale behind our mechanism is that the latency in receiving the skipped segment matters far less than any latency caused in the potential signalling of a congestion event occurring during the honesty test. This aspect is never significant with TCP SACK because there can be enough information in a single acknowledgment to signal both that a segment is missing, and that a later segment has experienced congestion. The mechanism you have presented in [Sherwood05] defers sending the skipped segment until TCP-SACK or a dup ack signals it is missing , which will take about one RTT. It will take another RTT for the skipped segment to be duly acknowledged. If SACK is not used, the problem is that the receiver cannot signal any congestion event for about one RTT, from the time when it detects the skipped segment is missing until the time it receives it. TCP can only advance the acknowledgement number when it receives in-order data (strictly data which advances the receive window). In other words your test will generate a stream of dup acks all for the segment before the skipped segment until such time as the skipped segment is actually received. =20 The advantage of the mechanism in [draft-moncaster-tcpm-rcv-cheat-00] is that it reduces the time it takes for the source to send the skipped segment to a (random) fraction of the congestion window, which on average will be less than half an RTT. Forcing a receiver to send a single duplicate ack does partially show their honesty in that it makes it hard for them to send optimistic acks. However it still allows them to conceal actual segment losses as they will generally not suffer any penalty (fast retransmit) until they have sent three duplicate acknowledgements. Toby -----Original Message----- From: Rob Sherwood [mailto:capveg@cs.umd.edu]=20 Sent: 21 February 2007 22:30 To: Moncaster,T,Toby,CXR9 R Cc: capveg@cs.umd.edu; tcpm@ietf.org Subject: Re: [tcpm] New I-D posted : draft-moncaster-tcpm-rcv-cheat-00 On Wed, Feb 21, 2007 at 03:46:10PM -0000, toby.moncaster@bt.com wrote: > Hi Rob, >=20 > We were under the impression that you were keen that the skipped=20 > segments solution be implemented with SACK enabled as otherwise there=20 > is a risk that it could delay the notification of congestion by up to=20 > 1 RTT more. Apologies if we have got this wrong. I'm not sure that I see that risk. I think both this point and the point below rely on the same aspect of TCP: when an out of order segment arrives, the receiver immediately sends a duplicate ACK for the previously acknowledged segment. Thus, as long as the receiver sends a single duplicate ack for the skipped segment, then the sender know it is honest. Because there is no delay in the dup ack generation, the penalty for receiving the skipped segment is at most 1 RTT. > "Any TCP sender SHOULD check the honesty of its receivers using the=20 > probabilistic test periodically and randomly. In particular, it would=20 > be advantageous for any sender that is heavily loaded to identify if=20 > it is taken advantage of by an attack by a dishonest receiver". This wording is definitely clearer. > Final point, as Gavin McCullagh has already pointed out, apart from=20 > legacy Tahoe TCP implementations a receiver can be reasonably safe if=20 > it sends less than 3 duplicate ACKs for a missing segment as this will > not trigger fast re-transmit. Consequently we have specified that the=20 > displacement should be at least this large. Maybe I'm the one who is confused, but as I understand it, a single duplicate ACK (for the correct segment) is enough to differentiate an honest receiver from a malicious one, so why do you need multiple duplicate acks? Fast retransmit should never be an issue, because=20 the sender should not perform congestion control in response to a malicious receiver test. =20 - Rob . _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Feb 22 14:25:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKJZ5-0004Gk-IU; Thu, 22 Feb 2007 14:25:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKJZ4-0004Gb-0x for tcpm@ietf.org; Thu, 22 Feb 2007 14:25:14 -0500 Received: from mailer2.psc.edu ([128.182.66.106]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKJZ2-0007Zi-P2 for tcpm@ietf.org; Thu, 22 Feb 2007 14:25:14 -0500 Received: from [128.182.160.132] (ice.psc.edu [128.182.160.132]) (authenticated bits=0) by mailer2.psc.edu (8.13.8/8.13.3) with ESMTP id l1MJP8XI010666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Feb 2007 14:25:09 -0500 (EST) Message-ID: <45DDEE13.2020008@psc.edu> Date: Thu, 22 Feb 2007 14:25:07 -0500 From: John Heffner User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Michael Welzl Subject: Re: [tcpm] New I-D posted : draft-moncaster-tcpm-rcv-cheat-00 References: <0C53DCFB700D144284A584F54711EC5802E88AD8@xmb-sjc-21c.amer.cisco.com> <1172129226.3233.4.camel@pc105-c703.uibk.ac.at> In-Reply-To: <1172129226.3233.4.camel@pc105-c703.uibk.ac.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Michael Welzl wrote: >>> There's been some talk lately about reverse path congestion control. >>> (This would be much harder with TCP than DCCP, but maybe someone can >>> figure it out?) >> By reverse path, you mean ACK congestion control? Data transfer can be >> bi-directional. > > Funny enough, I stumbled over this SHOULD when thinking about ACK > congestion control, where it could be useful for the sender to be > able to count the number of ACKs that the receiver would normally > have to send during a loss period. > > In any case, it's the concern of a new mechanism, yet to be specified, > how to do ACK congestion control, and not the concern of RFC 2581 - > using a SHOULD instead of a MUST for sending ACKs to out-of-order > segments doesn't implement or even help ACK congestion control, > but it actually seems to be a hindrance. On the other hand, I don't know how you could possibly hope to do ACK congestion control when congestion on the forward path MUST cause you to suddenly double your rate of sending ACKs. This also leads to another possible reason why you might want to continue delayed ACK during reordering/loss: on half-duplex links, especially wireless which may have a high per-packet cost, doubling your ACK rate in response to congestion actually makes the congestion worse. I don't really want to get into defending specifics of any of these general ideas, but I'm just trying to say I wouldn't want to entirely rule out any of these ideas from future TCP, unless a strong case is made to do so. -John _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Feb 22 16:01:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKL3k-0008DQ-DG; Thu, 22 Feb 2007 16:01:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKL3j-0008DL-Ec for tcpm@ietf.org; Thu, 22 Feb 2007 16:00:59 -0500 Received: from viefep18-int.chello.at ([213.46.255.21] helo=viefep14-int.chello.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKL3i-0004S4-0N for tcpm@ietf.org; Thu, 22 Feb 2007 16:00:59 -0500 Received: from work ([213.47.204.236]) by viefep14-int.chello.at (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20070222210056.HCXB21691.viefep14-int.chello.at@work>; Thu, 22 Feb 2007 22:00:56 +0100 From: "Michael Welzl" To: "John Heffner" Subject: AW: [tcpm] New I-D posted : draft-moncaster-tcpm-rcv-cheat-00 Date: Thu, 22 Feb 2007 22:01:31 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 In-Reply-To: <45DDEE13.2020008@psc.edu> Importance: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org > > In any case, it's the concern of a new mechanism, yet to be specified, > > how to do ACK congestion control, and not the concern of RFC 2581 - > > using a SHOULD instead of a MUST for sending ACKs to out-of-order > > segments doesn't implement or even help ACK congestion control, > > but it actually seems to be a hindrance. > > On the other hand, I don't know how you could possibly hope to do ACK > congestion control when congestion on the forward path MUST cause you to > suddenly double your rate of sending ACKs. What I meant with "new mechanism, yet to be specified" is that we could, at some point, decide to specify an ACK congestion control mechanism which would, under controlled conditions, reduce the ACK rate, and override this MUST with something else (i.e. update RFC 2581bis) - but since such a mechanism does not (yet) exist, 2581bis isn't the right place for this. > This also leads to another possible reason why you might want to > continue delayed ACK during reordering/loss: on half-duplex links, > especially wireless which may have a high per-packet cost, doubling your > ACK rate in response to congestion actually makes the congestion worse. > > I don't really want to get into defending specifics of any of these > general ideas, but I'm just trying to say I wouldn't want to entirely > rule out any of these ideas from future TCP, unless a strong case is > made to do so. It wouldn't rule this out from future RFCs on TCP, and TCP implementations that are based on them. It merely rules it out of future TCP implementations (and here, I would argue that a larger step is needed for proper ACK congestion control than the flexibility that is granted by the SHOULD in RFC 2581). Cheers, Michael _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Feb 22 16:25:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKLR2-0001ue-39; Thu, 22 Feb 2007 16:25:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKLR0-0001oi-AD for tcpm@ietf.org; Thu, 22 Feb 2007 16:25:02 -0500 Received: from mailer1.psc.edu ([128.182.58.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKLMC-0007KQ-Vs for tcpm@ietf.org; Thu, 22 Feb 2007 16:20:06 -0500 Received: from [128.182.160.132] (ice.psc.edu [128.182.160.132]) (authenticated bits=0) by mailer1.psc.edu (8.13.8/8.13.3) with ESMTP id l1MLK2ZN021242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Feb 2007 16:20:03 -0500 (EST) Message-ID: <45DE0900.8060207@psc.edu> Date: Thu, 22 Feb 2007 16:20:00 -0500 From: John Heffner User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Michael Welzl References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" Subject: [tcpm] Re: RFC2581bis ooo acking WAS: New I-D posted : draft-moncaster-tcpm-rcv-cheat-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org I guess I'm not quite sure what you mean (maybe we are using language that's too indirect). To get to the heart of the matter: do you advocate changing the first SHOULD in Section 3.2 of RFC2581 to a MUST in 2581bis? This is not a trivial change. Thanks, -John Michael Welzl wrote: >>> In any case, it's the concern of a new mechanism, yet to be specified, >>> how to do ACK congestion control, and not the concern of RFC 2581 - >>> using a SHOULD instead of a MUST for sending ACKs to out-of-order >>> segments doesn't implement or even help ACK congestion control, >>> but it actually seems to be a hindrance. >> On the other hand, I don't know how you could possibly hope to do ACK >> congestion control when congestion on the forward path MUST cause you to >> suddenly double your rate of sending ACKs. > > What I meant with "new mechanism, yet to be specified" is that > we could, at some point, decide to specify an ACK congestion > control mechanism which would, under controlled conditions, > reduce the ACK rate, and override this MUST with something > else (i.e. update RFC 2581bis) - but since such a mechanism > does not (yet) exist, 2581bis isn't the right place for this. > > >> This also leads to another possible reason why you might want to >> continue delayed ACK during reordering/loss: on half-duplex links, >> especially wireless which may have a high per-packet cost, doubling your >> ACK rate in response to congestion actually makes the congestion worse. >> >> I don't really want to get into defending specifics of any of these >> general ideas, but I'm just trying to say I wouldn't want to entirely >> rule out any of these ideas from future TCP, unless a strong case is >> made to do so. > > It wouldn't rule this out from future RFCs on TCP, and TCP > implementations that are based on them. It merely rules it > out of future TCP implementations (and here, I would argue > that a larger step is needed for proper ACK congestion > control than the flexibility that is granted by the SHOULD > in RFC 2581). > > Cheers, > Michael ______From tcpm-bounces@ietf.org Thu Feb 22 16:25:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKLR2-0001ue-39; Thu, 22 Feb 2007 16:25:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKLR0-0001oi-AD for tcpm@ietf.org; Thu, 22 Feb 2007 16:25:02 -0500 Received: from mailer1.psc.edu ([128.182.58.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKLMC-0007KQ-Vs for tcpm@ietf.org; Thu, 22 Feb 2007 16:20:06 -0500 Received: from [128.182.160.132] (ice.psc.edu [128.182.160.132]) (authenticated bits=0) by mailer1.psc.edu (8.13.8/8.13.3) with ESMTP id l1MLK2ZN021242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Feb 2007 16:20:03 -0500 (EST) Message-ID: <45DE0900.8060207@psc.edu> Date: Thu, 22 Feb 2007 16:20:00 -0500 From: John Heffner User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Michael Welzl References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" Subject: [tcpm] Re: RFC2581bis ooo acking WAS: New I-D posted : draft-moncaster-tcpm-rcv-cheat-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org I guess I'm not quite sure what you mean (maybe we are using language that's too indirect). To get to the heart of the matter: do you advocate changing the first SHOULD in Section 3.2 of RFC2581 to a MUST in 2581bis? This is not a trivial change. Thanks, -John Michael Welzl wrote: >>> In any case, it's the concern of a new mechanism, yet to be specified, >>> how to do ACK congestion control, and not the concern of RFC 2581 - >>> using a SHOULD instead of a MUST for sending ACKs to out-of-order >>> segments doesn't implement or even help ACK congestion control, >>> but it actually seems to be a hindrance. >> On the other hand, I don't know how you could possibly hope to do ACK >> congestion control when congestion on the forward path MUST cause you to >> suddenly double your rate of sending ACKs. > > What I meant with "new mechanism, yet to be specified" is that > we could, at some point, decide to specify an ACK congestion > control mechanism which would, under controlled conditions, > reduce the ACK rate, and override this MUST with something > else (i.e. update RFC 2581bis) - but since such a mechanism > does not (yet) exist, 2581bis isn't the right place for this. > > >> This also leads to another possible reason why you might want to >> continue delayed ACK during reordering/loss: on half-duplex links, >> especially wireless which may have a high per-packet cost, doubling your >> ACK rate in response to congestion actually makes the congestion worse. >> >> I don't really want to get into defending specifics of any of these >> general ideas, but I'm just trying to say I wouldn't want to entirely >> rule out any of these ideas from future TCP, unless a strong case is >> made to do so. > > It wouldn't rule this out from future RFCs on TCP, and TCP > implementations that are based on them. It merely rules it > out of future TCP implementations (and here, I would argue > that a larger step is needed for proper ACK congestion > control than the flexibility that is granted by the SHOULD > in RFC 2581). > > Cheers, > Michael _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Feb 22 16:25:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKLQo-0001C8-Rq; Thu, 22 Feb 2007 16:24:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKLQm-00016j-IM for tcpm@ietf.org; Thu, 22 Feb 2007 16:24:48 -0500 Received: from viefep18-int.chello.at ([213.46.255.21] helo=viefep15-int.chello.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKLOn-0007ny-DC for tcpm@ietf.org; Thu, 22 Feb 2007 16:22:46 -0500 Received: from work ([213.47.204.236]) by viefep15-int.chello.at (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20070222212243.YIZR11184.viefep15-int.chello.at@work>; Thu, 22 Feb 2007 22:22:43 +0100 From: "Michael Welzl" To: "John Heffner" Date: Thu, 22 Feb 2007 22:23:19 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <45DE0900.8060207@psc.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" Subject: [tcpm] AW: RFC2581bis ooo acking WAS: New I-D posted : draft-moncaster-tcpm-rcv-cheat-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org > To get to the heart of the matter: do you advocate changing the first > SHOULD in Section 3.2 of RFC2581 to a MUST in 2581bis? Yes, > This is not a trivial change. but I think it's a good one (and I don't see why it would be *that* problematic). Cheers, Michael _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm _________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Feb 22 16:25:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKLQo-0001C8-Rq; Thu, 22 Feb 2007 16:24:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKLQm-00016j-IM for tcpm@ietf.org; Thu, 22 Feb 2007 16:24:48 -0500 Received: from viefep18-int.chello.at ([213.46.255.21] helo=viefep15-int.chello.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKLOn-0007ny-DC for tcpm@ietf.org; Thu, 22 Feb 2007 16:22:46 -0500 Received: from work ([213.47.204.236]) by viefep15-int.chello.at (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20070222212243.YIZR11184.viefep15-int.chello.at@work>; Thu, 22 Feb 2007 22:22:43 +0100 From: "Michael Welzl" To: "John Heffner" Date: Thu, 22 Feb 2007 22:23:19 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <45DE0900.8060207@psc.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" Subject: [tcpm] AW: RFC2581bis ooo acking WAS: New I-D posted : draft-moncaster-tcpm-rcv-cheat-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org > To get to the heart of the matter: do you advocate changing the first > SHOULD in Section 3.2 of RFC2581 to a MUST in 2581bis? Yes, > This is not a trivial change. but I think it's a good one (and I don't see why it would be *that* problematic). Cheers, Michael _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Feb 23 15:54:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKhPD-0002nr-FW; Fri, 23 Feb 2007 15:52:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKhNf-0000pL-BX; Fri, 23 Feb 2007 15:51:03 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HKhNf-0005bp-0P; Fri, 23 Feb 2007 15:51:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 41AC02ACFF; Fri, 23 Feb 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HKhMh-000716-0G; Fri, 23 Feb 2007 15:50:03 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 23 Feb 2007 15:50:03 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-tcpsecure-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Improving TCP's Robustness to Blind In-Window Attacks Author(s) : A. Ramaiah, et al. Filename : draft-ietf-tcpm-tcpsecure-07.txt Pages : 26 Date : 2007-2-23 TCP has historically been considered protected against spoofed packet injection attacks by relying on the fact that it is difficult to guess the 4-tuple (the source and destination IP addresses and the source and destination ports) in combination with the 32 bit sequence number(s). A combination of increasing window sizes and applications using a longer term connections (e.g. H-323 or Border Gateway Protocol [RFC4271]) have left modern TCP implementation more vulnerable to these types of spoofed packet injection attacks. Many of these long term TCP applications tend to have predictable IP addresses and ports which makes it far easier for the 4-tuple to be guessed. Having guessed the 4-tuple correctly, an attacker can inject a RST, SYN or DATA segment into a TCP connection by carefully crafting the sequence number of the spoofed segment to be in the current receive window. This can cause the connection to either abort or possibly cause data corruption. This document specifies small modifications to the way TCP handles inbound segments that can reduce the chances of a successful attack. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tcpm-tcpsecure-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tcpm-tcpsecure-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-23111825.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-tcpsecure-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-tcpsecure-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-23111825.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --NextPart-- From tcpm-bounces@ietf.org Fri Feb 23 18:16:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKjdH-0007Ax-JH; Fri, 23 Feb 2007 18:15:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKjdG-0007As-9A for tcpm@ietf.org; Fri, 23 Feb 2007 18:15:18 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKjdE-0007uS-Tg for tcpm@ietf.org; Fri, 23 Feb 2007 18:15:18 -0500 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l1NNEUbn024175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Feb 2007 15:14:30 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.13.8/8.13.8/Submit) id l1NNETdk032537; Fri, 23 Feb 2007 15:14:29 -0800 (PST) (envelope-from faber) Date: Fri, 23 Feb 2007 15:14:29 -0800 From: Ted Faber To: Michael Welzl Subject: Re: [tcpm] AW: RFC2581bis ooo acking WAS: New I-D posted : draft-moncaster-tcpm-rcv-cheat-00 Message-ID: <20070223231429.GM31471@hut.isi.edu> References: <45DE0900.8060207@psc.edu> Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.4.2.2i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1159066771==" Errors-To: tcpm-bounces@ietf.org --===============1159066771== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3FyYKcuUbgqNYeqV" Content-Disposition: inline --3FyYKcuUbgqNYeqV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 22, 2007 at 10:23:19PM +0100, Michael Welzl wrote: > > To get to the heart of the matter: do you advocate changing the first= =20 > > SHOULD in Section 3.2 of RFC2581 to a MUST in 2581bis? >=20 > Yes, > =20 > > This is not a trivial change. >=20 > but I think it's a good one (and I don't see why it would > be *that* problematic). My thinking is that the SHOULD in question should reamin as it stands. The advantages of the receiver behavior are obvious, but it's also perfectly clear that this behavior is not imperative to the correct function of the TCP protocol, nor will disobeying the SHOULD impair other users of the network (the source will enter fast retransmit somewhat later than it optimally could have, but there are plenty of other possible causes of that delay). I don't think anyone argues that a good implementation will send the ACKs. I don't understand the argument that the system must be constrained to do it or be non-conformant. Optimizations are at most SHOULDs almost by definition. That's all IMHO, w/o a chair hat. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --3FyYKcuUbgqNYeqV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.2 (FreeBSD) iD8DBQFF33VVaUz3f+Zf+XsRAt6lAJ0eBESTteY7H8BzmlWz6kddk1RLFACeLBPT +NI330wzfKzXYUAwKHuZptw= =0MOU -----END PGP SIGNATURE----- --3FyYKcuUbgqNYeqV-- --===============1159066771== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1159066771==-- From tcpm-bounces@ietf.org Fri Feb 23 18:49:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKk9j-0004b6-3B; Fri, 23 Feb 2007 18:48:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKk9h-0004b1-9p for tcpm@ietf.org; Fri, 23 Feb 2007 18:48:49 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKk9f-00056i-VX for tcpm@ietf.org; Fri, 23 Feb 2007 18:48:49 -0500 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l1NNm4Q4002445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Feb 2007 15:48:04 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.13.8/8.13.8/Submit) id l1NNm46T033693; Fri, 23 Feb 2007 15:48:04 -0800 (PST) (envelope-from faber) Date: Fri, 23 Feb 2007 15:48:04 -0800 From: Ted Faber To: Michael Welzl Subject: Re: [tcpm] AW: RFC2581bis ooo acking WAS: New I-D posted : draft-moncaster-tcpm-rcv-cheat-00 Message-ID: <20070223234804.GP31471@hut.isi.edu> References: <45DE0900.8060207@psc.edu> <20070223231429.GM31471@hut.isi.edu> Mime-Version: 1.0 In-Reply-To: <20070223231429.GM31471@hut.isi.edu> User-Agent: Mutt/1.4.2.2i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1560924539==" Errors-To: tcpm-bounces@ietf.org --===============1560924539== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1BKOZKwX7DAU5odC" Content-Disposition: inline --1BKOZKwX7DAU5odC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 23, 2007 at 03:14:29PM -0800, Ted Faber wrote: > I don't think anyone argues that a good implementation will send the > ACKs.=20 Strike that; reverse it. We agree a good implementation will send the ACKs. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --1BKOZKwX7DAU5odC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.2 (FreeBSD) iD8DBQFF3300aUz3f+Zf+XsRArhPAKCTPK/t+o5YuteN7NQUmStdaDWWRgCg1BuR jHe+f0MuTGtMqmOYEJptkMc= =B99e -----END PGP SIGNATURE----- --1BKOZKwX7DAU5odC-- --===============1560924539== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1560924539==-- From tcpm-bounces@ietf.org Fri Feb 23 19:00:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKkKh-00038x-GJ; Fri, 23 Feb 2007 19:00:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKkKf-00034g-2C for tcpm@ietf.org; Fri, 23 Feb 2007 19:00:09 -0500 Received: from mms2.broadcom.com ([216.31.210.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKkKI-0006zR-Ul for tcpm@ietf.org; Fri, 23 Feb 2007 19:00:08 -0500 Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.0)); Fri, 23 Feb 2007 15:59:36 -0800 X-Server-Uuid: 05DA3F36-9AA8-4766-A7E5-53B43A7C42E6 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 5CE9C2AF; Fri, 23 Feb 2007 15:59:36 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 47CBE2AE; Fri, 23 Feb 2007 15:59:36 -0800 (PST) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EYX33557; Fri, 23 Feb 2007 15:59:34 -0800 (PST) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id B9EA220502; Fri, 23 Feb 2007 15:59:34 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] AW: RFC2581bis ooo acking WAS: New I-D posted : draft-moncaster-tcpm-rcv-cheat-00 Date: Fri, 23 Feb 2007 15:59:33 -0800 Message-ID: <54AD0F12E08D1541B826BE97C98F99F101193B7F@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <20070223234804.GP31471@hut.isi.edu> Thread-Topic: [tcpm] AW: RFC2581bis ooo acking WAS: New I-D posted : draft-moncaster-tcpm-rcv-cheat-00 Thread-Index: AcdXpXphsTiJbVA1RZmct0LqiviCAwAANhgg From: "Caitlin Bestler" To: "Ted Faber" , "Michael Welzl" X-WSS-ID: 69C1A06228C8641850-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Ted Faber wrote: > On Fri, Feb 23, 2007 at 03:14:29PM -0800, Ted Faber wrote: >> I don't think anyone argues that a good implementation will send the >> ACKs. >=20 > Strike that; reverse it. >=20 > We agree a good implementation will send the ACKs. I agree with that as long as "send" is understood to=20 be inclusive of piggy-backing the "send" on a TCP segment that is already scheduled for transmit. That is, when the draft says "immediately send" it means "do not delay, in fact use a pure ack if necessary." _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Feb 23 20:49:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKm1L-0004VX-IZ; Fri, 23 Feb 2007 20:48:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKm1K-0004VO-1Q for tcpm@ietf.org; Fri, 23 Feb 2007 20:48:18 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKm1H-0004VW-La for tcpm@ietf.org; Fri, 23 Feb 2007 20:48:18 -0500 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l1O1ldj9001010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Feb 2007 17:47:39 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.13.8/8.13.8/Submit) id l1O1ldCa036026; Fri, 23 Feb 2007 17:47:39 -0800 (PST) (envelope-from faber) Date: Fri, 23 Feb 2007 17:47:39 -0800 From: Ted Faber To: Caitlin Bestler Subject: Re: [tcpm] AW: RFC2581bis ooo acking WAS: New I-D posted : draft-moncaster-tcpm-rcv-cheat-00 Message-ID: <20070224014739.GU31471@hut.isi.edu> References: <20070223234804.GP31471@hut.isi.edu> <54AD0F12E08D1541B826BE97C98F99F101193B7F@NT-SJCA-0751.brcm.ad.broadcom.com> Mime-Version: 1.0 In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F101193B7F@NT-SJCA-0751.brcm.ad.broadcom.com> User-Agent: Mutt/1.4.2.2i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , Michael Welzl X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0399318121==" Errors-To: tcpm-bounces@ietf.org --===============0399318121== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="f6M9UaX53EEZorp0" Content-Disposition: inline --f6M9UaX53EEZorp0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 23, 2007 at 03:59:33PM -0800, Caitlin Bestler wrote: > Ted Faber wrote: > > On Fri, Feb 23, 2007 at 03:14:29PM -0800, Ted Faber wrote: > >> I don't think anyone argues that a good implementation will send the > >> ACKs. > >=20 > > Strike that; reverse it. > >=20 > > We agree a good implementation will send the ACKs. >=20 > I agree with that as long as "send" is understood to=20 > be inclusive of piggy-backing the "send" on a TCP > segment that is already scheduled for transmit. >=20 > That is, when the draft says "immediately send" it > means "do not delay, in fact use a pure ack if > necessary." We agree. It's my interpretation that TCP should always piggyback an ACK when possible. That's how I read P. 74 of RFC 793, anyway:=20 ESTABLISHED STATE FIN-WAIT-1 STATE FIN-WAIT-2 STATE Once in the ESTABLISHED state, it is possible to deliver segment text to user RECEIVE buffers. [...] When the TCP takes responsibility for delivering the data to the user it must also acknowledge the receipt of the data. [...] Send an acknowledgment of the form: This acknowledgment should be piggybacked on a segment being transmitted if possible without incurring undue delay. To my eyes that's a SHOULD in the last paragraph, but (loosely) because=20 793 < 2119 that typography wasn't in use. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --f6M9UaX53EEZorp0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.2 (FreeBSD) iD8DBQFF35k7aUz3f+Zf+XsRAlf3AKCXrI5yZy+GLwaBxSKRMftvYmrZ4gCg0FEZ 4aQjFYDbaEOC2S1Lpxza0PY= =xhQL -----END PGP SIGNATURE----- --f6M9UaX53EEZorp0-- --===============0399318121== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0399318121==-- From tcpm-bounces@ietf.org Sat Feb 24 02:25:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKrGN-0000ae-6f; Sat, 24 Feb 2007 02:24:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKrGL-0000Z8-Jn for tcpm@ietf.org; Sat, 24 Feb 2007 02:24:09 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKrGK-0003QD-2B for tcpm@ietf.org; Sat, 24 Feb 2007 02:24:09 -0500 Received: from [127.0.0.1] ([128.9.176.72]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l1O7NwbP005673; Fri, 23 Feb 2007 23:23:59 -0800 (PST) Message-ID: <45DFE808.9080502@isi.edu> Date: Fri, 23 Feb 2007 23:23:52 -0800 From: Joe Touch User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: tcpm@ietf.org Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-tcp-antispoof-05.txt (Ends 2 Feb 2007) References: <20070118012440.GC1540@hut.isi.edu> <20070126174742.GF44355@hut.isi.edu> In-Reply-To: <20070126174742.GF44355@hut.isi.edu> X-Enigmail-Version: 0.94.1.2.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1649157106==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1649157106== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig74A5599837F9C55A1EF5FB7A" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig74A5599837F9C55A1EF5FB7A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The following is a summary of feedback from the last call: - Wes Eddy endorsed the doc - Alfred Hoenes provided detailed input - numerous typos were addressed - sec 2.4 had an error, where the attack takes only 20 seconds for a 1Mbps link; this description was updated to indicate that such an attack is less likely primarily because of port randomization, and now cites Larsen/Gont's recent I-D - sec 5.2 AH was corrected from "deprecated" to "being phased out", and now cites 4301 - requested addressing NATs a paragraph was appended to the security considerations section - Lars Eggert provided input - also noticed the sec 2.4 error above - Pekka Savola provided input - sec 3.2.1, paragraph 3 was reworded according to his suggested text on filtering - draft-ietf-rtgwg-rfc3682bis-09.txt was added to the references where BITW was discussed - the document was updated with revised BCP 78 boilerplate All the above modifications were confirmed as sufficient by the parties above. The revised document, -06, has already been submitted to the I-D repository (and passed IDnits). It should be available shortly; until then, it is available at: http://www.isi.edu/touch/pubs/draft-ietf-tcpm-tcp-antispoof-06.txt Joe Ted Faber wrote: > On Wed, Jan 17, 2007 at 05:24:41PM -0800, Ted Faber wrote: >> Hi. >> >> As we mentioned in San Diego, the anti-spoof document is ready for a >> second last call. We're primarily checking to see that issues brought= >> up in the first WGLC have been addressed. You can find much of that >> discussion starting here: >> >> http://www1.ietf.org/mail-archive/web/tcpm/current/msg01890.html >> >> The draft is available from=20 >> >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-antispoof-05.tx= t >> >> Comments (including positive ones, please) to the list. >> >> This WGLC will end 2 Feb 2007 - a little more than 2 weeks from now. >=20 > Just a reminder: this WGLC has one week left. I've only seen one > message about the draft. Passing a WGLC requires some reaction from th= e > group. If you're interested in seeing this work done and believe that > this document represents a reasonable consensus, please speak up. And,= > of course, if you see problems with the draft, also speak up. >=20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enig74A5599837F9C55A1EF5FB7A 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 iD8DBQFF3+gJE5f5cImnZrsRAml5AJ4z+ngtLVad+2auCNMfMzTTr2uywgCgrZ6U tFsL0szfqEtO02iG2LMrA5s= =esYR -----END PGP SIGNATURE----- --------------enig74A5599837F9C55A1EF5FB7A-- --===============1649157106== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1649157106==-- From tcpm-bounces@ietf.org Sat Feb 24 03:20:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKs8K-0002QX-Pm; Sat, 24 Feb 2007 03:19:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKs8J-0002QN-Rc for tcpm@ietf.org; Sat, 24 Feb 2007 03:19:55 -0500 Received: from lmr1.uibk.ac.at ([138.232.1.142] helo=smtp.uibk.ac.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKs8I-0004i9-By for tcpm@ietf.org; Sat, 24 Feb 2007 03:19:55 -0500 Received: from localhost (lwm1.uibk.ac.at [138.232.1.160] Michael.Welzl@uibk.ac.at) by smtp.uibk.ac.at (8.13.8/8.13.1/F1) with ESMTP id l1O8Jcb6016227; Sat, 24 Feb 2007 09:19:38 +0100 Received: from chello213047204236.tirol.surfer.at (chello213047204236.tirol.surfer.at [213.47.204.236]) by web-mail1.uibk.ac.at (IMP) with HTTP for ; Sat, 24 Feb 2007 09:19:38 +0100 Message-ID: <1172305178.45dff51a52ad1@web-mail1.uibk.ac.at> Date: Sat, 24 Feb 2007 09:19:38 +0100 From: Michael Welzl To: Ted Faber Subject: Re: [tcpm] AW: RFC2581bis ooo acking WAS: New I-D posted : draft-moncaster-tcpm-rcv-cheat-00 References: <45DE0900.8060207@psc.edu> <20070223231429.GM31471@hut.isi.edu> In-Reply-To: <20070223231429.GM31471@hut.isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Originating-IP: 213.47.204.236 X-Forwarded-For: X-Spam-Score: () -7.4 ALL_TRUSTED,RCV_SMTP_UIBK,RCV_WEBMAIL X-Scanned-By: MIMEDefang 2.58 at uibk.ac.at on 138.232.1.140 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org > My thinking is that the SHOULD in question should reamin as it stands. > The advantages of the receiver behavior are obvious, but it's also > perfectly clear that this behavior is not imperative to the correct > function of the TCP protocol, nor will disobeying the SHOULD impair > other users of the network (the source will enter fast retransmit > somewhat later than it optimally could have, but there are plenty of > other possible causes of that delay). > > I don't think anyone argues that a good implementation will send the > ACKs. I don't understand the argument that the system must be > constrained to do it or be non-conformant. Optimizations are at most > SHOULDs almost by definition. What confuses me is this discrepance that, on the one hand, a lot of effort was made to avoid entering slow start by reasonably using DupACKs (NewReno, the SACK scoreboard) and getting enough of them (Limited Transmit), while on the other, we simply leave it up to the receiver to send less than it should. Does it make sense to allow a receiver to do something which has no obvious benefit, but clearly leads to undesirable behavior? Cheers, Michael _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Feb 24 11:06:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKzOm-0006RF-Kp; Sat, 24 Feb 2007 11:05:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKzOl-0006R4-23 for tcpm@ietf.org; Sat, 24 Feb 2007 11:05:23 -0500 Received: from gateway.insightbb.com ([74.128.0.19] helo=asav18.insightbb.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKzOi-0003t4-Qc for tcpm@ietf.org; Sat, 24 Feb 2007 11:05:23 -0500 Received: from 74-140-122-125.dhcp.insightbb.com (HELO elb.elitists.net) ([74.140.122.125]) by asav18.insightbb.com with ESMTP; 24 Feb 2007 11:04:29 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAPrw30VKjHp9/2dsb2JhbACiUAEBAQ Received: from colt.internal (colt [192.168.33.1]) by elb.elitists.net (Postfix) with ESMTP id 83F632BE21 for ; Sat, 24 Feb 2007 11:04:28 -0500 (EST) Received: by colt.internal (Postfix, from userid 3000) id 324122822F; Sat, 24 Feb 2007 11:04:28 -0500 (EST) Date: Sat, 24 Feb 2007 11:04:28 -0500 From: Ethan Blanton To: tcpm@ietf.org Subject: Re: [tcpm] AW: RFC2581bis ooo acking WAS: New I-D posted : draft-moncaster-tcpm-rcv-cheat-00 Message-ID: <20070224160428.GA18638@elb.elitists.net> Mail-Followup-To: tcpm@ietf.org References: <45DE0900.8060207@psc.edu> <20070223231429.GM31471@hut.isi.edu> <1172305178.45dff51a52ad1@web-mail1.uibk.ac.at> MIME-Version: 1.0 In-Reply-To: <1172305178.45dff51a52ad1@web-mail1.uibk.ac.at> X-GnuPG-Fingerprint: A290 14A8 C682 5C88 AE51 4787 AFD9 00F4 883C 1C14 User-Agent: Mutt/1.5.12-2006-07-14 X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0938576797==" Errors-To: tcpm-bounces@ietf.org --===============0938576797== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CE+1k2dSO48ffgeK" Content-Disposition: inline --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [The "something" below being delaying a dup ACK for a segment received out-of-order using delayed ACKs.] Michael Welzl spake unto us the following wisdom: > Does it make sense to allow a receiver to do something which > has no obvious benefit, but clearly leads to undesirable > behavior? Yes, if it does not break the protocol. The receiver may have other concerns than absolute rapidity of throughput; for example, power savings, bandwidth conservation, local processing time, etc. etc. This, in my mind, simply falls into the realm of dictating implementation details. The point is that a receiver delaying that out-of-order ACK will still perform correctly with respect to protocol semantics, it may just take a little bit longer. I am inclined to not change this in 2581bis. I don't see any major benefit in doing so, and it does constrain implementors' choices, while not fixing any serious misinteraction. Anyone violating that SHOULD already SHOULD [heh] have a very good reason to be doing so. Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 --CE+1k2dSO48ffgeK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFF4GILr9kA9Ig8HBQRAv6LAJ0buJmGds+J5rcKJoC0sqka9va+uACgyv91 Zg105beihF+OjPFwqKOjKDg= =QRC7 -----END PGP SIGNATURE----- --CE+1k2dSO48ffgeK-- --===============0938576797== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0938576797==-- From tcpm-bounces@ietf.org Sun Feb 25 08:03:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLJ0E-0007VO-Uy; Sun, 25 Feb 2007 08:01:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLJ0C-0007UB-Vg for tcpm@ietf.org; Sun, 25 Feb 2007 08:01:21 -0500 Received: from lmr1.uibk.ac.at ([138.232.1.142] helo=smtp.uibk.ac.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLJ0B-0004H8-Gs for tcpm@ietf.org; Sun, 25 Feb 2007 08:01:20 -0500 Received: from localhost (lwm2.uibk.ac.at [138.232.1.161] Michael.Welzl@uibk.ac.at) by smtp.uibk.ac.at (8.13.8/8.13.1/F1) with ESMTP id l1PD18p3005908 for ; Sun, 25 Feb 2007 14:01:08 +0100 Received: from chello213047204236.tirol.surfer.at (chello213047204236.tirol.surfer.at [213.47.204.236]) by web-mail2.uibk.ac.at (IMP) with HTTP for ; Sun, 25 Feb 2007 14:01:08 +0100 Message-ID: <1172408468.45e1889489b08@web-mail2.uibk.ac.at> Date: Sun, 25 Feb 2007 14:01:08 +0100 From: Michael Welzl To: tcpm@ietf.org Subject: Re: [tcpm] AW: RFC2581bis ooo acking WAS: New I-D posted : draft-moncaster-tcpm-rcv-cheat-00 References: <45DE0900.8060207@psc.edu> <20070223231429.GM31471@hut.isi.edu> <1172305178.45dff51a52ad1@web-mail1.uibk.ac.at> <20070224160428.GA18638@elb.elitists.net> In-Reply-To: <20070224160428.GA18638@elb.elitists.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Originating-IP: 213.47.204.236 X-Forwarded-For: X-Spam-Score: () -7.4 ALL_TRUSTED,RCV_SMTP_UIBK,RCV_WEBMAIL X-Scanned-By: MIMEDefang 2.58 at uibk.ac.at on 138.232.1.140 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Folks, You convinced me. Thanks for the discussion! Cheers, Michael Zitat von Ethan Blanton : > [The "something" below being delaying a dup ACK for a segment received > out-of-order using delayed ACKs.] > > Michael Welzl spake unto us the following wisdom: > > Does it make sense to allow a receiver to do something which > > has no obvious benefit, but clearly leads to undesirable > > behavior? > > Yes, if it does not break the protocol. The receiver may have other > concerns than absolute rapidity of throughput; for example, power > savings, bandwidth conservation, local processing time, etc. etc. > This, in my mind, simply falls into the realm of dictating > implementation details. The point is that a receiver delaying that > out-of-order ACK will still perform correctly with respect to protocol > semantics, it may just take a little bit longer. > > I am inclined to not change this in 2581bis. I don't see any major > benefit in doing so, and it does constrain implementors' choices, > while not fixing any serious misinteraction. Anyone violating that > SHOULD already SHOULD [heh] have a very good reason to be doing so. > > Ethan > > -- > The laws that forbid the carrying of arms are laws [that have no remedy > for evils]. They disarm only those who are neither inclined nor > determined to commit crimes. > -- Cesare Beccaria, "On Crimes and Punishments", 1764 > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Feb 25 13:06:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLNk0-0001Ll-3Q; Sun, 25 Feb 2007 13:04:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLNjy-0001Lg-MN for tcpm@ietf.org; Sun, 25 Feb 2007 13:04:54 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLNjv-0004aP-Nu for tcpm@ietf.org; Sun, 25 Feb 2007 13:04:54 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 25 Feb 2007 10:04:51 -0800 X-IronPort-AV: i="4.14,216,1170662400"; d="scan'208"; a="466961627:sNHT47861768" 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/8.12.11) with ESMTP id l1PI4pN1014436; Sun, 25 Feb 2007 10:04:51 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l1PI4fUw023144; Sun, 25 Feb 2007 10:04:45 -0800 (PST) Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 25 Feb 2007 10:04:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] AW: RFC2581bis ooo acking WAS: New I-D posted :draft-moncaster-tcpm-rcv-cheat-00 Date: Sun, 25 Feb 2007 10:04:39 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC5802ED6AC4@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <1172408468.45e1889489b08@web-mail2.uibk.ac.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] AW: RFC2581bis ooo acking WAS: New I-D posted :draft-moncaster-tcpm-rcv-cheat-00 Thread-Index: AcdY3Xp0vzFmNpcPS0WyFOClm/8PWQAJAdQw From: "Anantha Ramaiah \(ananth\)" To: "Michael Welzl" , X-OriginalArrivalTime: 25 Feb 2007 18:04:40.0857 (UTC) FILETIME=[6B9EF090:01C75907] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2097; t=1172426691; x=1173290691; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20\(ananth\)=22=20 |Subject:=20RE=3A=20[tcpm]=20AW=3A=20RFC2581bis=20ooo=20acking=20WAS=3A=2 0New=20I-D=20posted=20=3Adraft-moncaster-tcpm-rcv-cheat-00 |Sender:=20; bh=crur7iAen5P228lBnHoVoQR7gHORX682YGI+04f/WyM=; b=br/LN6mYgKG8StElnXLbX7wEh/xQvzPV4jTXCvL0vjIZ5d6NgjLZK4WQSbqo9OQNRVvpesOo NuBP6KeHmGoYsplfOj92wjx8y0pGMHiaYshn6fRfMiYfPPoNK86b6q6r; Authentication-Results: sj-dkim-3; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Actually my thinking is a bit different here. If there is choice to pick, and I was given that choice, I would go with MUST ;-) A few comments inline ( I may be repeating myself here).....=20 >=20 > Zitat von Ethan Blanton : >=20 > > [The "something" below being delaying a dup ACK for a=20 > segment received =20 > > out-of-order using delayed ACKs.] > > > > Michael Welzl spake unto us the following wisdom: > > > Does it make sense to allow a receiver to do something=20 > which has no=20 > > > obvious benefit, but clearly leads to undesirable behavior? > > > > Yes, if it does not break the protocol. The receiver may=20 > have other=20 > > concerns than absolute rapidity of throughput; for example, power=20 > > savings, bandwidth conservation, local processing time, etc. etc. > > This, in my mind, simply falls into the realm of dictating=20 > > implementation details. The point is that a receiver delaying that=20 > > out-of-order ACK will still perform correctly with respect=20 > to protocol=20 > > semantics, it may just take a little bit longer. - The question I would ask is: "Is fast retransmission considered a MUST? Yes, according to RFC 2581. If so I would think the surrounding mechanisms, esp the ones which has direct influence, which facilitate the fast-retransmision, can also be considered for a MUST candidate, like in this case the generation of Duplicate ACK's.=20 - The above example on "power savings, b/w conservation etc.," can be applied to, in theory, to any packet, not just the duplicate ACK's. I may sound argumentative here, but my experience ( not theoretical, coming from working on internet devices/stacks which use TCP) treats the dupacks as a MUST. Also to my knowledge, I haven't heard of stacks which don't send or delay ( the latter may be ok, like you point out above) these duplicate ACKs and would be interested to know if any one of the widely used stacks permit this either naturally or by means of knob. But this is my opinion, OMMV. Thanks, -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Feb 25 13:34:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLOBr-0000C7-Vc; Sun, 25 Feb 2007 13:33:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLOBq-0000Bz-Vu for tcpm@ietf.org; Sun, 25 Feb 2007 13:33:42 -0500 Received: from gateway.insightbb.com ([74.128.0.19] helo=asav02.insightbb.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLOBp-0001OA-OG for tcpm@ietf.org; Sun, 25 Feb 2007 13:33:42 -0500 Received: from 74-140-122-125.dhcp.insightbb.com (HELO elb.elitists.net) ([74.140.122.125]) by asav02.insightbb.com with ESMTP; 25 Feb 2007 13:33:28 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAKtl4UVKjHp9/2dsb2JhbACjDAEBAQ Received: from colt.internal (colt [192.168.33.1]) by elb.elitists.net (Postfix) with ESMTP id 3691A2BE21 for ; Sun, 25 Feb 2007 13:33:28 -0500 (EST) Received: by colt.internal (Postfix, from userid 3000) id 8CA302822F; Sun, 25 Feb 2007 13:33:27 -0500 (EST) Date: Sun, 25 Feb 2007 13:33:27 -0500 From: Ethan Blanton To: tcpm@ietf.org Subject: Re: [tcpm] AW: RFC2581bis ooo acking WAS: New I-D posted :draft-moncaster-tcpm-rcv-cheat-00 Message-ID: <20070225183327.GB18638@elb.elitists.net> Mail-Followup-To: tcpm@ietf.org References: <1172408468.45e1889489b08@web-mail2.uibk.ac.at> <0C53DCFB700D144284A584F54711EC5802ED6AC4@xmb-sjc-21c.amer.cisco.com> MIME-Version: 1.0 In-Reply-To: <0C53DCFB700D144284A584F54711EC5802ED6AC4@xmb-sjc-21c.amer.cisco.com> X-GnuPG-Fingerprint: A290 14A8 C682 5C88 AE51 4787 AFD9 00F4 883C 1C14 User-Agent: Mutt/1.5.12-2006-07-14 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0719963845==" Errors-To: tcpm-bounces@ietf.org --===============0719963845== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XF85m9dhOBO43t/C" Content-Disposition: inline --XF85m9dhOBO43t/C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Anantha Ramaiah (ananth) spake unto us the following wisdom: > > > Yes, if it does not break the protocol. The receiver may have other= =20 > > > concerns than absolute rapidity of throughput; for example, power=20 > > > savings, bandwidth conservation, local processing time, etc. etc. > > > This, in my mind, simply falls into the realm of dictating=20 > > > implementation details. The point is that a receiver delaying that= =20 > > > out-of-order ACK will still perform correctly with respect to protocol > > > semantics, it may just take a little bit longer. >=20 > - The question I would ask is: "Is fast retransmission considered a > MUST? Yes, according to RFC 2581. If so I would think the surrounding > mechanisms, esp the ones which has direct influence, which facilitate > the fast-retransmision, can also be considered for a MUST candidate, > like in this case the generation of Duplicate ACK's.=20 I agree; however, the duplicate ACK *will* be generated; it just may be delayed by as much as 500ms. (Note that 1122 says that the "delay MUST be less than 0.5 seconds".) As several people, including myself, have said in this thread, it is not at all an issue of *correctness*. If we were talking about correctness, I would completely agree that the correct solution is the only option. Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 --XF85m9dhOBO43t/C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFF4dZ3r9kA9Ig8HBQRAl2QAKCdUG19CEMQ3fHdvd4c3sfTrG9zOwCdEfHz 3fO/y/ZXurb8pa4Q+ReBeF8= =hTEt -----END PGP SIGNATURE----- --XF85m9dhOBO43t/C-- --===============0719963845== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0719963845==-- From tcpm-bounces@ietf.org Sun Feb 25 14:36:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLP9L-00015W-Ni; Sun, 25 Feb 2007 14:35:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLP9K-00015K-7P for tcpm@ietf.org; Sun, 25 Feb 2007 14:35:10 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLP9F-0001vn-In for tcpm@ietf.org; Sun, 25 Feb 2007 14:35:10 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-6.cisco.com with ESMTP; 25 Feb 2007 11:35:05 -0800 X-IronPort-AV: i="4.14,216,1170662400"; d="scan'208"; a="116043247:sNHT55595052" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l1PJZ4AN029579 for ; Sun, 25 Feb 2007 11:35:04 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l1PJZ4ho029558 for ; Sun, 25 Feb 2007 11:35:04 -0800 (PST) Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 25 Feb 2007 11:35:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] I-D ACTION:draft-ietf-tcpm-tcpsecure-07.txt Date: Sun, 25 Feb 2007 11:35:03 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC5802ED6AE0@xmb-sjc-21c.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] I-D ACTION:draft-ietf-tcpm-tcpsecure-07.txt Thread-Index: AcdXjM7hrHASo9GHTxGu6XSQneqA/QBfsU9w From: "Anantha Ramaiah \(ananth\)" To: X-OriginalArrivalTime: 25 Feb 2007 19:35:04.0596 (UTC) FILETIME=[0C6BD540:01C75914] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4774; t=1172432105; x=1173296105; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20\(ananth\)=22=20 |Subject:=20RE=3A=20[tcpm]=20I-D=20ACTION=3Adraft-ietf-tcpm-tcpsecure-07. txt=20 |Sender:=20; bh=LzXnqq89Z7Bvk7NeVsguyWjl9JoOW/njerl7GW1juDU=; b=S5YGApcSpjvfxTmjkgbv0KrfRSbZj7P/rI5iDJbH0zgLUVheN06PVfZJKEEl14ZeaNyp+pQv fBuvoQgLod0UCCMoH7AmdTrsqOQB03TBP3cQZdi0N9jwF4RVdzp9vIx2; Authentication-Results: sj-dkim-8; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Greetings, The main changes from -06- to -07- can be summarised as follows : - Ted had a an important technical suggestion i.e, to make the mitigations proposed in the document from MUST to SHOULD. This is because to echo Ted's statement : "I'm not really keen on making all existing TCP implementations non-conformant to deal with an attack that isn't exactly a threat to all the web." We think it is a very fair statement and hence changed these mitigations to SHOULD, and the general intention is to say something like "TCP's SHOULD do this, for TCP's which do this MUST......" - editorial, grammatical, typos, correctness stuff. In particular, Ted and Alfred HInes (Hoenes) provided comments in this area. There were comments too from other folks. Thanks a lot for all of them. As a re-cap, the previous revision -06- took care of most of Joe's comments ( which was sent on the list), revised security considerations text (thanks to Ted), spell check, grammar and other minor editorial changes. Pl review the -07- version. More Comments welcome :-) Thanks, -Anantha > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Friday, February 23, 2007 12:50 PM > To: i-d-announce@ietf.org > Cc: tcpm@ietf.org > Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-tcpsecure-07.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the TCP Maintenance and Minor=20 > Extensions Working Group of the IETF. >=20 > Title : Improving TCP's Robustness to Blind=20 > In-Window Attacks > Author(s) : A. Ramaiah, et al. > Filename : draft-ietf-tcpm-tcpsecure-07.txt > Pages : 26 > Date : 2007-2-23 > =09 > TCP has historically been considered protected against spoofed packet > injection attacks by relying on the fact that it is difficult to > guess the 4-tuple (the source and destination IP addresses and the > source and destination ports) in combination with the 32=20 > bit sequence > number(s). A combination of increasing window sizes and=20 > applications > using a longer term connections (e.g. H-323 or Border Gateway > Protocol [RFC4271]) have left modern TCP implementation more > vulnerable to these types of spoofed packet injection attacks. >=20 > Many of these long term TCP applications tend to have=20 > predictable IP > addresses and ports which makes it far easier for the 4-tuple to be > guessed. Having guessed the 4-tuple correctly, an attacker can > inject a RST, SYN or DATA segment into a TCP connection by=20 > carefully > crafting the sequence number of the spoofed segment to be in the > current receive window. This can cause the connection to either > abort or possibly cause data corruption. This document specifies > small modifications to the way TCP handles inbound=20 > segments that can > reduce the chances of a successful attack. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-07.txt >=20 > To remove yourself from the I-D Announcement list, send a=20 > message to i-d-announce-request@ietf.org with the word=20 > unsubscribe in the body of the message.=20 > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username "anonymous" and a password of your e-mail=20 > address. After logging in, type "cd internet-drafts" and then=20 > "get draft-ietf-tcpm-tcpsecure-07.txt". >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-tcpm-tcpsecure-07.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant=20 > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. >=20 > Below is the data which will enable a MIME compliant mail=20 > reader implementation to automatically retrieve the ASCII=20 > version of the Internet-Draft. >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Feb 26 14:43:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLljX-0007Yc-EH; Mon, 26 Feb 2007 14:42:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLljW-0007YX-Qj for tcpm@ietf.org; Mon, 26 Feb 2007 14:42:02 -0500 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 1HLljV-0002jc-87 for tcpm@ietf.org; Mon, 26 Feb 2007 14:42:02 -0500 Received: from [139.133.207.152] (dhcp-207-152.erg.abdn.ac.uk [139.133.207.152]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id l1QJffwG012128; Mon, 26 Feb 2007 19:41:42 GMT Message-ID: <45E337F6.3030803@erg.abdn.ac.uk> Date: Mon, 26 Feb 2007 19:41:42 +0000 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: John Heffner Subject: Re: [tcpm] New I-D posted : draft-moncaster-tcpm-rcv-cheat-00 - (asymmetry) References: <0C53DCFB700D144284A584F54711EC5802E88736@xmb-sjc-21c.amer.cisco.com> <45DCD39C.60005@psc.edu> In-Reply-To: <45DCD39C.60005@psc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gf@erg.abdn.ac.uk X-Spam-Status: No X-Spam-Score: -2.8 (--) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org John Heffner wrote: > Anantha Ramaiah (ananth) wrote: > >>> is at odds with RFC 2581, which says: >>> >>>> Out-of-order data segments SHOULD be acknowledged immediately, in >>>> order to accelerate loss recovery. >>> >>> ...although I wonder why this is only a SHOULD, and not a MUST, and >>> herewith suggest to change this in 2581bis, unless there's a good >>> reason not to do so. >> > > Paths with severe asymmetry may want to thin ACKs. There were some > papers on this in the mid to late 90's coming out of work with > satellites and ADSL. > These arguments are in RFC 3449, for reference if you wish to go there. If you expect receivers to ALWAYS generate specific ACKs, the RFC3449 mitigations will give you some unexpected shocks (i.e. if you try to read more into the ACK stream than the TCP sender needed to clock out the data). Gorry Fairhurst _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Feb 26 18:10:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLnmI-0006rQ-0M; Mon, 26 Feb 2007 16:53:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLmoJ-0005mr-OP; Mon, 26 Feb 2007 15:51:03 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HLmoI-0007jk-T4; Mon, 26 Feb 2007 15:51:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 3C0131764A; Mon, 26 Feb 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HLmnK-0004zd-Uq; Mon, 26 Feb 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 26 Feb 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-tcp-antispoof-06.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Defending TCP Against Spoofing Attacks Author(s) : J. Touch Filename : draft-ietf-tcpm-tcp-antispoof-06.txt Pages : 29 Date : 2007-2-26 Recent analysis of potential attacks on core Internet infrastructure indicates an increased vulnerability of TCP connections to spurious resets (RSTs), sent with forged IP source addresses (spoofing). TCP has always been susceptible to such RST spoofing attacks, which were indirectly protected by checking that the RST sequence number was inside the current receive window, as well as via the obfuscation of TCP endpoint and port numbers. For pairs of well-known endpoints often over predictable port pairs, such as BGP or between web servers and well-known large-scale caches, increases in the path bandwidth- delay product of a connection have sufficiently increased the receive window space that off-path third parties can brute-force generate a viable RST sequence number. The susceptibility to attack increases with the square of the bandwidth, thus presents a significant vulnerability for recent high-speed networks. This document addresses this vulnerability, discussing proposed solutions at the transport level and their inherent challenges, as well as existing network level solutions and the feasibility of their deployment. This document focuses on vulnerabilities due to spoofed TCP segments, and includes a discussion of related ICMP spoofing attacks on TCP connections. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-antispoof-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tcpm-tcp-antispoof-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tcpm-tcp-antispoof-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-26120738.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-tcp-antispoof-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-antispoof-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-26120738.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --NextPart--