From tcpm-bounces@ietf.org Mon Jul 02 11:29:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5NqH-0002vH-Kt; Mon, 02 Jul 2007 11:29:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5NqG-0002tN-K2 for tcpm@ietf.org; Mon, 02 Jul 2007 11:29:32 -0400 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5NpE-000674-Qi for tcpm@ietf.org; Mon, 02 Jul 2007 11:29:32 -0400 Received: from [139.133.204.42] (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id l62FQJjp006518 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Mon, 2 Jul 2007 16:26:20 +0100 (BST) User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Mon, 02 Jul 2007 11:31:54 +0200 From: Gorry Fairhurst To: Message-ID: Thread-Topic: Comments on Soft Errors I-D: draft-ietf-tcpm-tcp-soft-errors-06 Thread-Index: Ace8lDVfc+AUoCiHEdyERQAKlc/qXg== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gf@erg.abdn.ac.uk X-Spam-Status: No X-Spam-Score: -2.8 (--) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: Gorry Fairhurst , Fernando Gont Subject: [tcpm] Comments on Soft Errors I-D: draft-ietf-tcpm-tcp-soft-errors-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 The document looks in good shape, and seemed easy to read to me. Here are a few comments on the latest draft, really relating to congestion-control and increased state. Best wishes, Gorry In Section 3.2 (Problems that may arise with Dual Stack IPv6 on by Default): There may also be drawbacks in this approach --- e.g. this creates additional host state, and could also establish additional context state for other devices along the network path (NAT. Firewall, link compressors, encryption devices, etc). Similarly, section 5 does not speak of the effects of a non-standard approach on the network. One question I have relates to the behaviour of a parallel and/or successive strategy to exploit multiple IP bindings. If I understand, this opens a (potentially) large number of connections, to see which succeeds. This seems to me to be injecting extra SYN packets into the network, and therefore can potentially waste network resources. If these connections are in series, each is opened one after another, after a "fixed" time (i.e. not exponentially backed-off)... which generates more state or more packets/rtt than using the standard algorithm. When connections are opened in parallel, this is even more noted. In an extreme case, this could look like a syn-attack or lead to congestion-based loss. Are these concerns valid? Is this only used for a single IPv4 and an equivalent IPv6 address? Are there limitations that would mitigate these effects if I had many candidate addresses? ---- The remaining comments are editorial, for the author to consider in their next rev: INTRODUCTION, paragraph 14: - Could consider to tighten English a little. CURRENT: This document describes a non-standard, but widely implemented, modification to TCP's handling of ICMP soft error messages, that rejects pending connection-requests when those error messages are received. This behavior reduces the likelihood of long delays between connection establishment attempts that may arise in a number of scenarios, including one in which dual stack nodes that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 environments. SUGGESTION: This document describes a non-standard, but widely implemented, modification to TCP's handling of ICMP soft error messages, which rejects pending connection-requests when these error messages are received. This behavior reduces the likelihood of long delays between connection establishment attempts that may arise in a number of scenarios, including one in which dual stack nodes that have IPv6 enabled by default are deployed in IPv4, or mixed IPv4 and IPv6 environments. Section 1., paragraph 2: In the Internet architecture, the Internet Control Message Protocol (ICMP) [RFC0792] is one fault isolation technique to report network error conditions to the hosts sending datagrams over the network. - Add the IPv6 ICMP reference too here? Section 3.2., paragraph 1: - Language could perhaps be improved. CURRENT: A particular scenario in which the above sketched type of problem may occur regularly is that where dual stack nodes that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 environments, and the IPv6 connectivity is non-existent [I-D.ietf-v6ops-v6onbydefault]. SUGGESTION: A particular scenario in which the problems outlined above can occur regularly arises where dual stack nodes (with IPv6 enabled by default) are deployed in IPv4 or mixed IPv4 and IPv6 environments, and the IPv6 connectivity is non-existent. [I-D.ietf-v6ops-v6onbydefault]. Section 4.1., paragraph 0: Could Add: Section 5 discusses drawbacks to changing this behaviour. Section 4.2., paragraph 1: - Language could perhaps be improved. OLD: A more conservative approach than simply treating soft errors as hard errors as described above would be to abort a connection in the SYN- SENT or SYN-RECEIVED states only after an ICMP Destination Unreachable has been received a specified number of times, and the SYN segment has been retransmitted more than some specified number of times. SUGGESTION: An approach that is more conservative than simply treating soft errors as hard errors, as described above, would be to abort a connection in the SYN- SENT or SYN-RECEIVED states only after an ICMP Destination Unreachable has been received a specified number of times, and the SYN segment has been retransmitted more than some specified number of times. Section 5, paragraph 1: - Capital E? CURRENT: +----------------------------------+--------------------------------+ | Time Exceeded (codes 0 and 1) | Time exceeded (codes 0 and 1) | ^ Section 5.3., paragraph 1: CURRENT: Some NATs respond to an unsolicited inbound SYN segment with an ICMP soft error message. If the system sending the unsolicited SYN segment implements the workaround described in this document, it will abort the connection upon receipt of the ICMP error message, thus probably preventing TCP's simultaneous open through the NAT from succeeding. However, it must be stressed that those NATs described in this section are not BEHAVE-compliant, and therefore should implement REQ-4 of [I-D.ietf-behave-tcp] instead. SUGGESTION: Some NATs respond to an unsolicited inbound SYN segment with an ICMP soft error message. If the system sending the unsolicited SYN segment implements the workaround described in this document, it will abort the connection upon receipt of the ICMP error message, thus probably preventing TCP's simultaneous open through the NAT from succeeding. However, it must be stressed that the NATs described in this section are not BEHAVE-compliant, and therefore should implement REQ-4 of [I-D.ietf-behave-tcp] instead. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 02 13:00:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5PGS-0006J7-GF; Mon, 02 Jul 2007 13:00:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5PGR-0006J2-OK for tcpm@ietf.org; Mon, 02 Jul 2007 13:00:39 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5PGM-0007mt-6d for tcpm@ietf.org; Mon, 02 Jul 2007 13:00:39 -0400 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 l62H0XJI030991 for ; Mon, 2 Jul 2007 10:00:33 -0700 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 1AC22C628CA for ; Mon, 2 Jul 2007 13:00:28 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 12FE024E3B1 for ; Mon, 2 Jul 2007 12:59:38 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Centerfield MIME-Version: 1.0 Date: Mon, 02 Jul 2007 12:59:38 -0400 Message-Id: <20070702165938.12FE024E3B1@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [tcpm] early retransmit --- one more time 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="===============1416272621==" Errors-To: tcpm-bounces@ietf.org --===============1416272621== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Folks- We rev-ed (but didn't change) the early retransmit I-D. We have asked for agenda time in TCPM on this topic, but it is not clear that we'll get it. Regardless, this is really our last plea for folks to look at this and let us know if it is worth pursuing. A long while ago it had a bit of steam behind it, but from the lack of response it seems that people don't care about this problem or this solution to it anymore. That is fine. If there is no support we're happy to drop it. The draft is: Mark Allman, Konstantin Avrachenkov, Urtzi Ayesta, Josh Blanton. Early Retransmit for TCP and SCTP, June 2007. Internet-Draft draft-allman-tcp-early-rexmt-05.txt (work in progress). http://www.icir.org/mallman/papers/draft-allman-tcp-early-rexmt-05.txt Comments on the list, off the list, or in Chicago (perhaps in the TCPM meeting, certainly in the hallway) are all fine. Thanks, allman -- Mark Allman -- ICIR/ICSI -- http://www.icir.org/mallman/ --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGiS75WyrrWs4yIs4RAiIlAKCXTppSoAEew9ECEWl5GAwrbGkZawCgkR7D johVLzr9UsVDFRjH3rs+yfw= =dZ2d -----END PGP SIGNATURE----- --=_bOundary-- --===============1416272621== 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 --===============1416272621==-- From tcpm-bounces@ietf.org Mon Jul 02 13:22:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5Pb9-0007Lf-1B; Mon, 02 Jul 2007 13:22:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5Pb5-0007Kj-Hy for tcpm@ietf.org; Mon, 02 Jul 2007 13:21:59 -0400 Received: from c00l3r.networx.ch ([62.48.2.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5Paz-0003nv-Jx for tcpm@ietf.org; Mon, 02 Jul 2007 13:21:59 -0400 Received: (qmail 47296 invoked from network); 2 Jul 2007 17:21:29 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 2 Jul 2007 17:21:29 -0000 Message-ID: <46893432.4000303@freebsd.org> Date: Mon, 02 Jul 2007 19:21:54 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: mallman@icir.org Subject: Re: [tcpm] early retransmit --- one more time References: <20070702165938.12FE024E3B1@lawyers.icir.org> In-Reply-To: <20070702165938.12FE024E3B1@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: 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 Mark Allman wrote: > > Folks- > > We rev-ed (but didn't change) the early retransmit I-D. We have asked > for agenda time in TCPM on this topic, but it is not clear that we'll > get it. Regardless, this is really our last plea for folks to look at > this and let us know if it is worth pursuing. A long while ago it had a > bit of steam behind it, but from the lack of response it seems that > people don't care about this problem or this solution to it anymore. > That is fine. If there is no support we're happy to drop it. The draft > is: > > Mark Allman, Konstantin Avrachenkov, Urtzi Ayesta, Josh Blanton. Early > Retransmit for TCP and SCTP, June 2007. Internet-Draft > draft-allman-tcp-early-rexmt-05.txt (work in progress). > http://www.icir.org/mallman/papers/draft-allman-tcp-early-rexmt-05.txt > > Comments on the list, off the list, or in Chicago (perhaps in the TCPM > meeting, certainly in the hallway) are all fine. I think it is worthwhile to continue with this proposal. The rationale seems to sound but may need updated real world data. -- Andre andre@FreeBSD.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 02 16:14:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5SHt-0004jh-AR; Mon, 02 Jul 2007 16:14:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5SHs-0004hw-Nz for tcpm@ietf.org; Mon, 02 Jul 2007 16:14:20 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5SHj-0002Zn-Rl for tcpm@ietf.org; Mon, 02 Jul 2007 16:14:20 -0400 Received: from [192.168.1.45] (pool-72-81-85-53.phlapa.east.verizon.net [72.81.85.53]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l62KDrLW024915; Mon, 2 Jul 2007 13:13:54 -0700 (PDT) Message-ID: <46895C7F.7060307@isi.edu> Date: Mon, 02 Jul 2007 13:13:51 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Gorry Fairhurst Subject: Re: [tcpm] Comments on Soft Errors I-D: draft-ietf-tcpm-tcp-soft-errors-06 References: In-Reply-To: X-Enigmail-Version: 0.95.1 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Cc: Gorry Fairhurst , 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: , Content-Type: multipart/mixed; boundary="===============1457114715==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1457114715== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0758A9571A5E1AB91351E2C1" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0758A9571A5E1AB91351E2C1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Gorry Fairhurst wrote: > The document looks in good shape, and seemed easy to read to me. >=20 > Here are a few comments on the latest draft, really relating to > congestion-control and increased state. >=20 > Best wishes, > =20 > Gorry >=20 > In Section 3.2 (Problems that may arise with Dual Stack IPv6 on by Defa= ult): > There may also be drawbacks in this approach --- e.g. this creates > additional host state, and could also establish additional context stat= e for > other devices along the network path (NAT. Firewall, link compressors, > encryption devices, etc). >=20 > Similarly, section 5 does not speak of the effects of a non-standard > approach on the network. One question I have relates to the behaviour o= f a > parallel and/or successive strategy to exploit multiple IP bindings. If= I > understand, this opens a (potentially) large number of connections, to = see > which succeeds. This seems to me to be injecting extra SYN packets into= the > network, and therefore can potentially waste network resources. > =20 > If these connections are in series, each is opened one after another, a= fter > a "fixed" time (i.e. not exponentially backed-off)... which generates m= ore > state or more packets/rtt than using the standard algorithm. > =20 > When connections are opened in parallel, this is even more noted. In a= n > extreme case, this could look like a syn-attack or lead to congestion-b= ased > loss. Are these concerns valid? Is this only used for a single IPv4 an= d an > equivalent IPv6 address? Are there limitations that would mitigate thes= e > effects if I had many candidate addresses? RFC1122 discusses the technique of trying multiple addresses, and it is issue only when a DNS name resolves to multiple addresses. It would be unusual for a large number of addresses to refer to the same host; in many cases, there are only a small number for one host (typically for IPv4 and IPv6), and the larger number is used for DNS rotation to distribute load to a number of servers. There are exceptions, such as where multiple IP addresses are used for shared web service -- though that has fallen out of use as newer HTTP protocols determine the host in the request (sending GET and the DNS name, in addition to the filename) rather than only by the IP address (which was the only way compatible with HTTP 1.0, e.g.). Whether in serial or in parallel, methods to moderate the number of outstanding SYNs are probably useful. But this isn't the focus of this document anyway. Joe > ---- >=20 > The remaining comments are editorial, for the author to consider in the= ir > next rev: > =20 > INTRODUCTION, paragraph 14: > - Could consider to tighten English a little. >=20 > CURRENT: > This document describes a non-standard, but widely implemented, > modification to TCP's handling of ICMP soft error messages, that > rejects pending connection-requests when those error messages are > received. This behavior reduces the likelihood of long delays > between connection establishment attempts that may arise in a numbe= r > of scenarios, including one in which dual stack nodes that have IPv= 6 > enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 > environments. > SUGGESTION: > This document describes a non-standard, but widely implemented, > modification to TCP's handling of ICMP soft error messages, which > rejects pending connection-requests when these error messages are > received. This behavior reduces the likelihood of long delays > between connection establishment attempts that may arise in a numbe= r > of scenarios, including one in which dual stack nodes that have IPv= 6 > enabled by default are deployed in IPv4, or mixed IPv4 and IPv6 > environments. >=20 > Section 1., paragraph 2: > In the Internet architecture, the Internet Control Message Protocol= > (ICMP) [RFC0792] is one fault isolation technique to report network= > error conditions to the hosts sending datagrams over the network. >=20 > - Add the IPv6 ICMP reference too here? >=20 >=20 > Section 3.2., paragraph 1: > - Language could perhaps be improved. > CURRENT: > A particular scenario in which the above sketched type of problem m= ay > occur regularly is that where dual stack nodes that have IPv6 enabl= ed > by default are deployed in IPv4 or mixed IPv4 and IPv6 environments= , > and the IPv6 connectivity is non-existent > [I-D.ietf-v6ops-v6onbydefault]. >=20 > SUGGESTION: >=20 > A particular scenario in which the problems outlined above > can occur regularly arises where dual stack nodes (with IPv6 enable= d > by default) are deployed in IPv4 or mixed IPv4 and IPv6 environment= s, > and the IPv6 connectivity is non-existent. > [I-D.ietf-v6ops-v6onbydefault]. >=20 > Section 4.1., paragraph 0: > Could Add: Section 5 discusses drawbacks to changing this behaviour. >=20 >=20 > Section 4.2., paragraph 1: > - Language could perhaps be improved. > OLD: > A more conservative approach than simply treating soft errors as ha= rd > errors as described above would be to abort a connection in the SYN= - > SENT or SYN-RECEIVED states only after an ICMP Destination > Unreachable has been received a specified number of times, and the > SYN segment has been retransmitted more than some specified number = of > times. >=20 > SUGGESTION: > An approach that is more conservative than simply treating soft err= ors > as hard > errors, as described above, would be to abort a connection in the S= YN- > SENT or SYN-RECEIVED states only after an ICMP Destination > Unreachable has been received a specified number of times, and the > SYN segment has been retransmitted more than some specified number = of > times. >=20 > Section 5, paragraph 1: > - Capital E? > CURRENT: > +----------------------------------+-------------------------------= -+ > | Time Exceeded (codes 0 and 1) | Time exceeded (codes 0 and 1)= | > ^ >=20 > Section 5.3., paragraph 1: > CURRENT: > Some NATs respond to an unsolicited inbound SYN segment with an ICM= P > soft error message. If the system sending the unsolicited SYN > segment implements the workaround described in this document, it wi= ll > abort the connection upon receipt of the ICMP error message, thus > probably preventing TCP's simultaneous open through the NAT from > succeeding. However, it must be stressed that those NATs described= > in this section are not BEHAVE-compliant, and therefore should > implement REQ-4 of [I-D.ietf-behave-tcp] instead. >=20 > SUGGESTION: > Some NATs respond to an unsolicited inbound SYN segment with an ICM= P > soft error message. If the system sending the unsolicited SYN > segment implements the workaround described in this document, it wi= ll > abort the connection upon receipt of the ICMP error message, thus > probably preventing TCP's simultaneous open through the NAT from > succeeding. However, it must be stressed that the NATs described > in this section are not BEHAVE-compliant, and therefore should > implement REQ-4 of [I-D.ietf-behave-tcp] instead. >=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 --------------enig0758A9571A5E1AB91351E2C1 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 iD8DBQFGiVx/E5f5cImnZrsRAiaPAKCjrF3Vlk3eECSTskHN4DVXd75lcgCff1P+ /srYrBB28Hr7s1O0ZUJf5GE= =Qh3T -----END PGP SIGNATURE----- --------------enig0758A9571A5E1AB91351E2C1-- --===============1457114715== 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 --===============1457114715==-- From tcpm-bounces@ietf.org Mon Jul 02 16:28:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5SVP-00073I-Gn; Mon, 02 Jul 2007 16:28:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5SVP-00071e-24 for tcpm@ietf.org; Mon, 02 Jul 2007 16:28:19 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5SVL-0006HU-N4 for tcpm@ietf.org; Mon, 02 Jul 2007 16:28:19 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 02 Jul 2007 22:28:15 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAAX8iEaQ/uCLh2dsb2JhbACPKAIJDiw X-IronPort-AV: i="4.16,488,1175464800"; d="scan'208"; a="147051722:sNHT24231550" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l62KSEHE009969; Mon, 2 Jul 2007 22:28:14 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l62KS9TC013604; Mon, 2 Jul 2007 20:28:14 GMT Received: from lwood-wxp01.cisco.com (ams3-vpn-dhcp4668.cisco.com [10.61.82.59]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id VAA01892; Mon, 2 Jul 2007 21:28:06 +0100 (BST) Message-Id: <200707022028.VAA01892@cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 02 Jul 2007 21:27:34 +0100 To: Joe Touch From: Lloyd Wood Subject: Re: [tcpm] Comments on Soft Errors I-D: draft-ietf-tcpm-tcp-soft-errors-06 In-Reply-To: <46895C7F.7060307@isi.edu> References: <46895C7F.7060307@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Authentication-Results: ams-dkim-2; header.From=L.Wood@surrey.ac.uk; dkim=neutral X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Gorry Fairhurst , 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 At Monday 02/07/2007 13:13 -0700, Joe Touch wrote: >There are exceptions, such as >where multiple IP addresses are used for shared web service -- though >that has fallen out of use as newer HTTP protocols determine the host in >the request (sending GET and the DNS name, in addition to the filename) >rather than only by the IP address (which was the only way compatible >with HTTP 1.0, e.g.). Care to elaborate? Your claims don't match what e.g. RFC1945 specifies, or what HTTP 1.0 did. L. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 02 22:18:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5XyN-0003OG-AH; Mon, 02 Jul 2007 22:18:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5XyK-0003L9-DC for tcpm@ietf.org; Mon, 02 Jul 2007 22:18:32 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I5XyK-0007jj-1u for tcpm@ietf.org; Mon, 02 Jul 2007 22:18:32 -0400 Received: from [192.168.1.45] (pool-72-81-85-53.phlapa.east.verizon.net [72.81.85.53]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l632I0Qo014995; Mon, 2 Jul 2007 19:18:00 -0700 (PDT) Message-ID: <4689B1D5.2040502@isi.edu> Date: Mon, 02 Jul 2007 19:17:57 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Lloyd Wood Subject: Re: [tcpm] Comments on Soft Errors I-D: draft-ietf-tcpm-tcp-soft-errors-06 References: <46895C7F.7060307@isi.edu> <200707022028.VAA01892@cisco.com> In-Reply-To: <200707022028.VAA01892@cisco.com> X-Enigmail-Version: 0.95.1 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Gorry Fairhurst , 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: , Content-Type: multipart/mixed; boundary="===============1976934313==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1976934313== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1933E25331F2CE4B51BA40DD" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1933E25331F2CE4B51BA40DD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Lloyd Wood wrote: > At Monday 02/07/2007 13:13 -0700, Joe Touch wrote: >> There are exceptions, such as >> where multiple IP addresses are used for shared web service -- though >> that has fallen out of use as newer HTTP protocols determine the host = in >> the request (sending GET and the DNS name, in addition to the filename= ) >> rather than only by the IP address (which was the only way compatible >> with HTTP 1.0, e.g.). >=20 > Care to elaborate? >=20 > Your claims don't match what e.g. RFC1945 specifies, or what HTTP 1.0 d= id. In 1.0 http://www.abc.com/ means open a connection to an IP address www.abc.com resolves to then issue "GET /" In 1.1, the same URL means open a connection to an IP address www.abc.com resolves to then issue "GET / HTTP/1.1 HOST: www.abc.com" This helps when www.abc.com and www.def.com are on the same host. In 1.0, they had to have different IP addresses*, with servers listening on port 80 specific to those IP addresses. The address isn't actually sent (sorry that it was implied above). *(they could have different ports, but I'm focusing on the common case where the port isn't specified, e.g., for common public servers) In 1.1, you could have a single server listening on both IP addresses, with each HOST name bound to a different file root. The HOST option could indicate which DNS name's root to use. Joe --------------enig1933E25331F2CE4B51BA40DD 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 iD8DBQFGibHWE5f5cImnZrsRAtglAKDWtpFP+YIybiixsbtYWzLCkMptAACfSDTj GqcAqCLxBq636tOjPNVqcQE= =ZSdw -----END PGP SIGNATURE----- --------------enig1933E25331F2CE4B51BA40DD-- --===============1976934313== 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 --===============1976934313==-- From tcpm-bounces@ietf.org Tue Jul 03 03:54:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5dDQ-0003hb-86; Tue, 03 Jul 2007 03:54:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5dDN-0003go-8Y for tcpm@ietf.org; Tue, 03 Jul 2007 03:54:25 -0400 Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I5dDM-0003I0-N6 for tcpm@ietf.org; Tue, 03 Jul 2007 03:54:25 -0400 Received: from [139.133.204.42] (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id l637rP9d010131 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Tue, 3 Jul 2007 08:53:26 +0100 (BST) User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Tue, 03 Jul 2007 09:53:24 +0200 Subject: Re: [tcpm] Comments on Soft Errors I-D: draft-ietf-tcpm-tcp-soft-errors-06 From: Gorry Fairhurst To: Joe Touch , Gorry Fairhurst Message-ID: Thread-Topic: [tcpm] Comments on Soft Errors I-D: draft-ietf-tcpm-tcp-soft-errors-06 Thread-Index: Ace9RztieibqLik6Edy+OgAKlc/qXg== In-Reply-To: <46895C7F.7060307@isi.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 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 My observation was only that if a host repeatedly opens several TCP sessions to search for a valid IP address (e.g. Attempting to try all IP addresses that correspond to abc.com), then it *could* consume much more network & host resources, than a host that opens a session to each address in turn, with a backoff between each request. Gorry On 2/7/07 22:13, "Joe Touch" wrote: > > > Gorry Fairhurst wrote: >> The document looks in good shape, and seemed easy to read to me. >> >> Here are a few comments on the latest draft, really relating to >> congestion-control and increased state. >> >> Best wishes, >> >> Gorry >> >> In Section 3.2 (Problems that may arise with Dual Stack IPv6 on by Default): >> There may also be drawbacks in this approach --- e.g. this creates >> additional host state, and could also establish additional context state for >> other devices along the network path (NAT. Firewall, link compressors, >> encryption devices, etc). >> >> Similarly, section 5 does not speak of the effects of a non-standard >> approach on the network. One question I have relates to the behaviour of a >> parallel and/or successive strategy to exploit multiple IP bindings. If I >> understand, this opens a (potentially) large number of connections, to see >> which succeeds. This seems to me to be injecting extra SYN packets into the >> network, and therefore can potentially waste network resources. >> >> If these connections are in series, each is opened one after another, after >> a "fixed" time (i.e. not exponentially backed-off)... which generates more >> state or more packets/rtt than using the standard algorithm. >> >> When connections are opened in parallel, this is even more noted. In an >> extreme case, this could look like a syn-attack or lead to congestion-based >> loss. Are these concerns valid? Is this only used for a single IPv4 and an >> equivalent IPv6 address? Are there limitations that would mitigate these >> effects if I had many candidate addresses? > > RFC1122 discusses the technique of trying multiple addresses, and it is > issue only when a DNS name resolves to multiple addresses. It would be > unusual for a large number of addresses to refer to the same host; in > many cases, there are only a small number for one host (typically for > IPv4 and IPv6), and the larger number is used for DNS rotation to > distribute load to a number of servers. There are exceptions, such as > where multiple IP addresses are used for shared web service -- though > that has fallen out of use as newer HTTP protocols determine the host in > the request (sending GET and the DNS name, in addition to the filename) > rather than only by the IP address (which was the only way compatible > with HTTP 1.0, e.g.). > > Whether in serial or in parallel, methods to moderate the number of > outstanding SYNs are probably useful. But this isn't the focus of this > document anyway. > > Joe > >> ---- >> >> The remaining comments are editorial, for the author to consider in their >> next rev: >> >> INTRODUCTION, paragraph 14: >> - Could consider to tighten English a little. >> >> CURRENT: >> This document describes a non-standard, but widely implemented, >> modification to TCP's handling of ICMP soft error messages, that >> rejects pending connection-requests when those error messages are >> received. This behavior reduces the likelihood of long delays >> between connection establishment attempts that may arise in a number >> of scenarios, including one in which dual stack nodes that have IPv6 >> enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 >> environments. >> SUGGESTION: >> This document describes a non-standard, but widely implemented, >> modification to TCP's handling of ICMP soft error messages, which >> rejects pending connection-requests when these error messages are >> received. This behavior reduces the likelihood of long delays >> between connection establishment attempts that may arise in a number >> of scenarios, including one in which dual stack nodes that have IPv6 >> enabled by default are deployed in IPv4, or mixed IPv4 and IPv6 >> environments. >> >> Section 1., paragraph 2: >> In the Internet architecture, the Internet Control Message Protocol >> (ICMP) [RFC0792] is one fault isolation technique to report network >> error conditions to the hosts sending datagrams over the network. >> >> - Add the IPv6 ICMP reference too here? >> >> >> Section 3.2., paragraph 1: >> - Language could perhaps be improved. >> CURRENT: >> A particular scenario in which the above sketched type of problem may >> occur regularly is that where dual stack nodes that have IPv6 enabled >> by default are deployed in IPv4 or mixed IPv4 and IPv6 environments, >> and the IPv6 connectivity is non-existent >> [I-D.ietf-v6ops-v6onbydefault]. >> >> SUGGESTION: >> >> A particular scenario in which the problems outlined above >> can occur regularly arises where dual stack nodes (with IPv6 enabled >> by default) are deployed in IPv4 or mixed IPv4 and IPv6 environments, >> and the IPv6 connectivity is non-existent. >> [I-D.ietf-v6ops-v6onbydefault]. >> >> Section 4.1., paragraph 0: >> Could Add: Section 5 discusses drawbacks to changing this behaviour. >> >> >> Section 4.2., paragraph 1: >> - Language could perhaps be improved. >> OLD: >> A more conservative approach than simply treating soft errors as hard >> errors as described above would be to abort a connection in the SYN- >> SENT or SYN-RECEIVED states only after an ICMP Destination >> Unreachable has been received a specified number of times, and the >> SYN segment has been retransmitted more than some specified number of >> times. >> >> SUGGESTION: >> An approach that is more conservative than simply treating soft errors >> as hard >> errors, as described above, would be to abort a connection in the SYN- >> SENT or SYN-RECEIVED states only after an ICMP Destination >> Unreachable has been received a specified number of times, and the >> SYN segment has been retransmitted more than some specified number of >> times. >> >> Section 5, paragraph 1: >> - Capital E? >> CURRENT: >> +----------------------------------+--------------------------------+ >> | Time Exceeded (codes 0 and 1) | Time exceeded (codes 0 and 1) | >> ^ >> >> Section 5.3., paragraph 1: >> CURRENT: >> Some NATs respond to an unsolicited inbound SYN segment with an ICMP >> soft error message. If the system sending the unsolicited SYN >> segment implements the workaround described in this document, it will >> abort the connection upon receipt of the ICMP error message, thus >> probably preventing TCP's simultaneous open through the NAT from >> succeeding. However, it must be stressed that those NATs described >> in this section are not BEHAVE-compliant, and therefore should >> implement REQ-4 of [I-D.ietf-behave-tcp] instead. >> >> SUGGESTION: >> Some NATs respond to an unsolicited inbound SYN segment with an ICMP >> soft error message. If the system sending the unsolicited SYN >> segment implements the workaround described in this document, it will >> abort the connection upon receipt of the ICMP error message, thus >> probably preventing TCP's simultaneous open through the NAT from >> succeeding. However, it must be stressed that the NATs described >> in this section are not BEHAVE-compliant, and therefore should >> implement REQ-4 of [I-D.ietf-behave-tcp] instead. >> >> >> >> _______________________________________________ >> 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 Tue Jul 03 09:32:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5iUO-00065w-4N; Tue, 03 Jul 2007 09:32:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5iUN-00062Z-4H for tcpm@ietf.org; Tue, 03 Jul 2007 09:32:19 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5iTj-0002hr-SJ for tcpm@ietf.org; Tue, 03 Jul 2007 09:32:19 -0400 Received: from [192.168.1.45] (pool-72-81-85-53.phlapa.east.verizon.net [72.81.85.53]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l63DVKnb007362; Tue, 3 Jul 2007 06:31:21 -0700 (PDT) Message-ID: <468A4FA6.7050809@isi.edu> Date: Tue, 03 Jul 2007 06:31:18 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Gorry Fairhurst Subject: Re: [tcpm] Comments on Soft Errors I-D: draft-ietf-tcpm-tcp-soft-errors-06 References: In-Reply-To: X-Enigmail-Version: 0.95.1 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 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: , Content-Type: multipart/mixed; boundary="===============0143070529==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0143070529== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig250BA661415B0A757E78752F" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig250BA661415B0A757E78752F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Gorry Fairhurst wrote: > My observation was only that if a host repeatedly opens several TCP ses= sions > to search for a valid IP address (e.g. Attempting to try all IP address= es > that correspond to abc.com), then it *could* consume much more network = & > host resources, than a host that opens a session to each address in tur= n, > with a backoff between each request. That's true, but there aren't rules for either parallel or serial. I.e., a host that opens 2 each (v4, v6) in parallel (then sequences through v4 and v6) consumes less resources than one that opens 8 in serial. It's a matter of rules governing how to try the sequence. I.e., either one could swamp things, depending on how the application wor= ks. Joe >=20 > Gorry >=20 >=20 > On 2/7/07 22:13, "Joe Touch" wrote: >=20 >> >> Gorry Fairhurst wrote: >>> The document looks in good shape, and seemed easy to read to me. >>> >>> Here are a few comments on the latest draft, really relating to >>> congestion-control and increased state. >>> >>> Best wishes, >>> =20 >>> Gorry >>> >>> In Section 3.2 (Problems that may arise with Dual Stack IPv6 on by De= fault): >>> There may also be drawbacks in this approach --- e.g. this creates >>> additional host state, and could also establish additional context st= ate for >>> other devices along the network path (NAT. Firewall, link compressors= , >>> encryption devices, etc). >>> >>> Similarly, section 5 does not speak of the effects of a non-standard >>> approach on the network. One question I have relates to the behaviour= of a >>> parallel and/or successive strategy to exploit multiple IP bindings. = If I >>> understand, this opens a (potentially) large number of connections, t= o see >>> which succeeds. This seems to me to be injecting extra SYN packets in= to the >>> network, and therefore can potentially waste network resources. >>> =20 >>> If these connections are in series, each is opened one after another,= after >>> a "fixed" time (i.e. not exponentially backed-off)... which generates= more >>> state or more packets/rtt than using the standard algorithm. >>> =20 >>> When connections are opened in parallel, this is even more noted. In= an >>> extreme case, this could look like a syn-attack or lead to congestion= -based >>> loss. Are these concerns valid? Is this only used for a single IPv4 = and an >>> equivalent IPv6 address? Are there limitations that would mitigate th= ese >>> effects if I had many candidate addresses? >> RFC1122 discusses the technique of trying multiple addresses, and it i= s >> issue only when a DNS name resolves to multiple addresses. It would be= >> unusual for a large number of addresses to refer to the same host; in >> many cases, there are only a small number for one host (typically for >> IPv4 and IPv6), and the larger number is used for DNS rotation to >> distribute load to a number of servers. There are exceptions, such as >> where multiple IP addresses are used for shared web service -- though >> that has fallen out of use as newer HTTP protocols determine the host = in >> the request (sending GET and the DNS name, in addition to the filename= ) >> rather than only by the IP address (which was the only way compatible >> with HTTP 1.0, e.g.). >> >> Whether in serial or in parallel, methods to moderate the number of >> outstanding SYNs are probably useful. But this isn't the focus of this= >> document anyway. >> >> Joe >> >>> ---- >>> >>> The remaining comments are editorial, for the author to consider in t= heir >>> next rev: >>> =20 >>> INTRODUCTION, paragraph 14: >>> - Could consider to tighten English a little. >>> >>> CURRENT: >>> This document describes a non-standard, but widely implemented, >>> modification to TCP's handling of ICMP soft error messages, that >>> rejects pending connection-requests when those error messages are= >>> received. This behavior reduces the likelihood of long delays >>> between connection establishment attempts that may arise in a num= ber >>> of scenarios, including one in which dual stack nodes that have I= Pv6 >>> enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 >>> environments. >>> SUGGESTION: >>> This document describes a non-standard, but widely implemented, >>> modification to TCP's handling of ICMP soft error messages, which= >>> rejects pending connection-requests when these error messages are= >>> received. This behavior reduces the likelihood of long delays >>> between connection establishment attempts that may arise in a num= ber >>> of scenarios, including one in which dual stack nodes that have I= Pv6 >>> enabled by default are deployed in IPv4, or mixed IPv4 and IPv6 >>> environments. >>> >>> Section 1., paragraph 2: >>> In the Internet architecture, the Internet Control Message Protoc= ol >>> (ICMP) [RFC0792] is one fault isolation technique to report netwo= rk >>> error conditions to the hosts sending datagrams over the network.= >>> >>> - Add the IPv6 ICMP reference too here? >>> >>> >>> Section 3.2., paragraph 1: >>> - Language could perhaps be improved. >>> CURRENT: >>> A particular scenario in which the above sketched type of problem= may >>> occur regularly is that where dual stack nodes that have IPv6 ena= bled >>> by default are deployed in IPv4 or mixed IPv4 and IPv6 environmen= ts, >>> and the IPv6 connectivity is non-existent >>> [I-D.ietf-v6ops-v6onbydefault]. >>> >>> SUGGESTION: >>> >>> A particular scenario in which the problems outlined above >>> can occur regularly arises where dual stack nodes (with IPv6 enab= led >>> by default) are deployed in IPv4 or mixed IPv4 and IPv6 environme= nts, >>> and the IPv6 connectivity is non-existent. >>> [I-D.ietf-v6ops-v6onbydefault]. >>> >>> Section 4.1., paragraph 0: >>> Could Add: Section 5 discusses drawbacks to changing this behaviour. >>> >>> >>> Section 4.2., paragraph 1: >>> - Language could perhaps be improved. >>> OLD: >>> A more conservative approach than simply treating soft errors as = hard >>> errors as described above would be to abort a connection in the S= YN- >>> SENT or SYN-RECEIVED states only after an ICMP Destination >>> Unreachable has been received a specified number of times, and th= e >>> SYN segment has been retransmitted more than some specified numbe= r of >>> times. >>> >>> SUGGESTION: >>> An approach that is more conservative than simply treating soft e= rrors >>> as hard >>> errors, as described above, would be to abort a connection in the= SYN- >>> SENT or SYN-RECEIVED states only after an ICMP Destination >>> Unreachable has been received a specified number of times, and th= e >>> SYN segment has been retransmitted more than some specified numbe= r of >>> times. >>> >>> Section 5, paragraph 1: >>> - Capital E? >>> CURRENT: >>> +----------------------------------+-----------------------------= ---+ >>> | Time Exceeded (codes 0 and 1) | Time exceeded (codes 0 and = 1) | >>> ^ >>> >>> Section 5.3., paragraph 1: >>> CURRENT: >>> Some NATs respond to an unsolicited inbound SYN segment with an I= CMP >>> soft error message. If the system sending the unsolicited SYN >>> segment implements the workaround described in this document, it = will >>> abort the connection upon receipt of the ICMP error message, thus= >>> probably preventing TCP's simultaneous open through the NAT from >>> succeeding. However, it must be stressed that those NATs describ= ed >>> in this section are not BEHAVE-compliant, and therefore should >>> implement REQ-4 of [I-D.ietf-behave-tcp] instead. >>> >>> SUGGESTION: >>> Some NATs respond to an unsolicited inbound SYN segment with an I= CMP >>> soft error message. If the system sending the unsolicited SYN >>> segment implements the workaround described in this document, it = will >>> abort the connection upon receipt of the ICMP error message, thus= >>> probably preventing TCP's simultaneous open through the NAT from >>> succeeding. However, it must be stressed that the NATs described= >>> in this section are not BEHAVE-compliant, and therefore should >>> implement REQ-4 of [I-D.ietf-behave-tcp] instead. >>> >>> >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www1.ietf.org/mailman/listinfo/tcpm >=20 --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enig250BA661415B0A757E78752F 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 iD8DBQFGik+mE5f5cImnZrsRAoesAJ9E4jPhamaY4Ul3L3vNLC15nUtEFQCeJ7UI Tg6g6ebNDEWYnm135TBH7hM= =y+qe -----END PGP SIGNATURE----- --------------enig250BA661415B0A757E78752F-- --===============0143070529== 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 --===============0143070529==-- From tcpm-bounces@ietf.org Tue Jul 03 09:53:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5ioV-0003lb-Uj; Tue, 03 Jul 2007 09:53:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5ioV-0003lW-29 for tcpm@ietf.org; Tue, 03 Jul 2007 09:53:07 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5ioC-0007QR-Ce for tcpm@ietf.org; Tue, 03 Jul 2007 09:53:07 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 03 Jul 2007 15:52:47 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAKrwiUaQ/uCLh2dsb2JhbACPJAIJDiw X-IronPort-AV: i="4.16,492,1175464800"; d="scan'208"; a="147123018:sNHT26185144" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l63DqlBI001686; Tue, 3 Jul 2007 15:52:47 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l63DqkTC026674; Tue, 3 Jul 2007 13:52:47 GMT Received: from lwood-wxp01.cisco.com ([64.103.85.251]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA26522; Tue, 3 Jul 2007 14:52:46 +0100 (BST) Message-Id: <200707031352.OAA26522@cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 03 Jul 2007 14:52:45 +0100 To: Joe Touch From: Lloyd Wood Subject: Re: [tcpm] Comments on Soft Errors I-D: draft-ietf-tcpm-tcp-soft-errors-06 In-Reply-To: <4689B1D5.2040502@isi.edu> References: <46895C7F.7060307@isi.edu> <200707022028.VAA01892@cisco.com> <4689B1D5.2040502@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Authentication-Results: ams-dkim-2; header.From=L.Wood@surrey.ac.uk; dkim=neutral X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Gorry Fairhurst , 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 At Monday 02/07/2007 19:17 -0700, Joe Touch wrote: >Lloyd Wood wrote: >> At Monday 02/07/2007 13:13 -0700, Joe Touch wrote: >>> There are exceptions, such as >>> where multiple IP addresses are used for shared web service -- though >>> that has fallen out of use as newer HTTP protocols determine the host in >>> the request (sending GET and the DNS name, in addition to the filename) >>> rather than only by the IP address (which was the only way compatible >>> with HTTP 1.0, e.g.). >> >> Care to elaborate? >> >> Your claims don't match what e.g. RFC1945 specifies, or what HTTP 1.0 did. > >In 1.0 http://www.abc.com/ means > open a connection to an IP address www.abc.com resolves to > then issue "GET /" > >In 1.1, the same URL means > open a connection to an IP address www.abc.com resolves to > then issue "GET / HTTP/1.1 HOST: www.abc.com" > >This helps when www.abc.com and www.def.com are on the same host. In >1.0, they had to have different IP addresses*, with servers listening on >port 80 specific to those IP addresses. The address isn't actually sent >(sorry that it was implied above). > >*(they could have different ports, but I'm focusing on the common case >where the port isn't specified, e.g., for common public servers) > >In 1.1, you could have a single server listening on both IP addresses, >with each HOST name bound to a different file root. The HOST option >could indicate which DNS name's root to use. Yes, the resolved IP address is never sent (unless it's already in the url.) In http 1.1, you can have a single server listening on a single IP address that both DNS names resolve to. In http 1.0, the context of name/address is implicit; in 1.1 it's explicitly given with Host: L. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jul 03 10:03:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5iyZ-00080w-4Q; Tue, 03 Jul 2007 10:03:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5iyY-00080Z-2d for tcpm@ietf.org; Tue, 03 Jul 2007 10:03:30 -0400 Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I5iyX-0006jH-GS for tcpm@ietf.org; Tue, 03 Jul 2007 10:03:29 -0400 Received: from don.erg.abdn.ac.uk (don.erg.abdn.ac.uk [139.133.204.83]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id l63E2C3t025249; Tue, 3 Jul 2007 15:02:12 +0100 (BST) Date: Tue, 3 Jul 2007 15:02:12 +0100 (BST) From: Gorry Fairhurst To: Joe Touch Subject: Re: [tcpm] Comments on Soft Errors I-D: draft-ietf-tcpm-tcp-soft-errors-06 In-Reply-To: <468A4FA6.7050809@isi.edu> Message-ID: References: <468A4FA6.7050809@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 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 OK. I am not suggesting the document creates new rules or methods. My suggestion is that the author could consider if this should or should not be documented (in the security considerations, for example). This is not a showstopper to me. Gorry On Tue, 3 Jul 2007, Joe Touch wrote: > > Gorry Fairhurst wrote: >> My observation was only that if a host repeatedly opens several TCP sessions >> to search for a valid IP address (e.g. Attempting to try all IP addresses >> that correspond to abc.com), then it *could* consume much more network & >> host resources, than a host that opens a session to each address in turn, >> with a backoff between each request. > > That's true, but there aren't rules for either parallel or serial. I.e., > a host that opens 2 each (v4, v6) in parallel (then sequences through v4 > and v6) consumes less resources than one that opens 8 in serial. It's a > matter of rules governing how to try the sequence. > > I.e., either one could swamp things, depending on how the application works. > > Joe > >> >> Gorry >> >> >> On 2/7/07 22:13, "Joe Touch" wrote: >> >>> >>> Gorry Fairhurst wrote: >>>> The document looks in good shape, and seemed easy to read to me. >>>> >>>> Here are a few comments on the latest draft, really relating to >>>> congestion-control and increased state. >>>> >>>> Best wishes, >>>> >>>> Gorry >>>> >>>> In Section 3.2 (Problems that may arise with Dual Stack IPv6 on by Default): >>>> There may also be drawbacks in this approach --- e.g. this creates >>>> additional host state, and could also establish additional context state for >>>> other devices along the network path (NAT. Firewall, link compressors, >>>> encryption devices, etc). >>>> >>>> Similarly, section 5 does not speak of the effects of a non-standard >>>> approach on the network. One question I have relates to the behaviour of a >>>> parallel and/or successive strategy to exploit multiple IP bindings. If I >>>> understand, this opens a (potentially) large number of connections, to see >>>> which succeeds. This seems to me to be injecting extra SYN packets into the >>>> network, and therefore can potentially waste network resources. >>>> >>>> If these connections are in series, each is opened one after another, after >>>> a "fixed" time (i.e. not exponentially backed-off)... which generates more >>>> state or more packets/rtt than using the standard algorithm. >>>> >>>> When connections are opened in parallel, this is even more noted. In an >>>> extreme case, this could look like a syn-attack or lead to congestion-based >>>> loss. Are these concerns valid? Is this only used for a single IPv4 and an >>>> equivalent IPv6 address? Are there limitations that would mitigate these >>>> effects if I had many candidate addresses? >>> RFC1122 discusses the technique of trying multiple addresses, and it is >>> issue only when a DNS name resolves to multiple addresses. It would be >>> unusual for a large number of addresses to refer to the same host; in >>> many cases, there are only a small number for one host (typically for >>> IPv4 and IPv6), and the larger number is used for DNS rotation to >>> distribute load to a number of servers. There are exceptions, such as >>> where multiple IP addresses are used for shared web service -- though >>> that has fallen out of use as newer HTTP protocols determine the host in >>> the request (sending GET and the DNS name, in addition to the filename) >>> rather than only by the IP address (which was the only way compatible >>> with HTTP 1.0, e.g.). >>> >>> Whether in serial or in parallel, methods to moderate the number of >>> outstanding SYNs are probably useful. But this isn't the focus of this >>> document anyway. >>> >>> Joe >>> >>>> ---- >>>> >>>> The remaining comments are editorial, for the author to consider in their >>>> next rev: >>>> >>>> INTRODUCTION, paragraph 14: >>>> - Could consider to tighten English a little. >>>> >>>> CURRENT: >>>> This document describes a non-standard, but widely implemented, >>>> modification to TCP's handling of ICMP soft error messages, that >>>> rejects pending connection-requests when those error messages are >>>> received. This behavior reduces the likelihood of long delays >>>> between connection establishment attempts that may arise in a number >>>> of scenarios, including one in which dual stack nodes that have IPv6 >>>> enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 >>>> environments. >>>> SUGGESTION: >>>> This document describes a non-standard, but widely implemented, >>>> modification to TCP's handling of ICMP soft error messages, which >>>> rejects pending connection-requests when these error messages are >>>> received. This behavior reduces the likelihood of long delays >>>> between connection establishment attempts that may arise in a number >>>> of scenarios, including one in which dual stack nodes that have IPv6 >>>> enabled by default are deployed in IPv4, or mixed IPv4 and IPv6 >>>> environments. >>>> >>>> Section 1., paragraph 2: >>>> In the Internet architecture, the Internet Control Message Protocol >>>> (ICMP) [RFC0792] is one fault isolation technique to report network >>>> error conditions to the hosts sending datagrams over the network. >>>> >>>> - Add the IPv6 ICMP reference too here? >>>> >>>> >>>> Section 3.2., paragraph 1: >>>> - Language could perhaps be improved. >>>> CURRENT: >>>> A particular scenario in which the above sketched type of problem may >>>> occur regularly is that where dual stack nodes that have IPv6 enabled >>>> by default are deployed in IPv4 or mixed IPv4 and IPv6 environments, >>>> and the IPv6 connectivity is non-existent >>>> [I-D.ietf-v6ops-v6onbydefault]. >>>> >>>> SUGGESTION: >>>> >>>> A particular scenario in which the problems outlined above >>>> can occur regularly arises where dual stack nodes (with IPv6 enabled >>>> by default) are deployed in IPv4 or mixed IPv4 and IPv6 environments, >>>> and the IPv6 connectivity is non-existent. >>>> [I-D.ietf-v6ops-v6onbydefault]. >>>> >>>> Section 4.1., paragraph 0: >>>> Could Add: Section 5 discusses drawbacks to changing this behaviour. >>>> >>>> >>>> Section 4.2., paragraph 1: >>>> - Language could perhaps be improved. >>>> OLD: >>>> A more conservative approach than simply treating soft errors as hard >>>> errors as described above would be to abort a connection in the SYN- >>>> SENT or SYN-RECEIVED states only after an ICMP Destination >>>> Unreachable has been received a specified number of times, and the >>>> SYN segment has been retransmitted more than some specified number of >>>> times. >>>> >>>> SUGGESTION: >>>> An approach that is more conservative than simply treating soft errors >>>> as hard >>>> errors, as described above, would be to abort a connection in the SYN- >>>> SENT or SYN-RECEIVED states only after an ICMP Destination >>>> Unreachable has been received a specified number of times, and the >>>> SYN segment has been retransmitted more than some specified number of >>>> times. >>>> >>>> Section 5, paragraph 1: >>>> - Capital E? >>>> CURRENT: >>>> +----------------------------------+--------------------------------+ >>>> | Time Exceeded (codes 0 and 1) | Time exceeded (codes 0 and 1) | >>>> ^ >>>> >>>> Section 5.3., paragraph 1: >>>> CURRENT: >>>> Some NATs respond to an unsolicited inbound SYN segment with an ICMP >>>> soft error message. If the system sending the unsolicited SYN >>>> segment implements the workaround described in this document, it will >>>> abort the connection upon receipt of the ICMP error message, thus >>>> probably preventing TCP's simultaneous open through the NAT from >>>> succeeding. However, it must be stressed that those NATs described >>>> in this section are not BEHAVE-compliant, and therefore should >>>> implement REQ-4 of [I-D.ietf-behave-tcp] instead. >>>> >>>> SUGGESTION: >>>> Some NATs respond to an unsolicited inbound SYN segment with an ICMP >>>> soft error message. If the system sending the unsolicited SYN >>>> segment implements the workaround described in this document, it will >>>> abort the connection upon receipt of the ICMP error message, thus >>>> probably preventing TCP's simultaneous open through the NAT from >>>> succeeding. However, it must be stressed that the NATs described >>>> in this section are not BEHAVE-compliant, and therefore should >>>> implement REQ-4 of [I-D.ietf-behave-tcp] instead. >>>> >>>> >>>> >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/tcpm >> > > -- > ---------------------------------------- > 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 Wed Jul 04 03:30:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5zJh-0003YN-3Y; Wed, 04 Jul 2007 03:30:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5zJf-0003Vn-M6 for tcpm@ietf.org; Wed, 04 Jul 2007 03:30:23 -0400 Received: from mail.nttv6.net ([2001:fa8::25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5zJT-0000Tf-LE for tcpm@ietf.org; Wed, 04 Jul 2007 03:30:23 -0400 Received: from andrew.nttv6.net (dhcp-3-196.nttv6.com [192.47.163.196]) by mail.nttv6.net (8.14.1/8.14.1) with ESMTP id l647UAWS023319 for ; Wed, 4 Jul 2007 16:30:10 +0900 (JST) (envelope-from arifumi@nttv6.net) Message-ID: <468B4BFA.80206@nttv6.net> Date: Wed, 04 Jul 2007 16:27:54 +0900 From: Arifumi Matsumoto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; ja-JP-mac; rv:1.8.1.4) Gecko/20070604 Thunderbird/2.0.0.4 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: tcpm@ietf.org Subject: Re: [tcpm] I-D ACTION:draft-ietf-tcpm-tcp-soft-errors-06.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mail.nttv6.net [192.68.245.115]); Wed, 04 Jul 2007 16:30:10 +0900 (JST) X-Spam-Score: 0.1 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 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, this revision basically looks good to me. About section 2 which I commented the other day and Fernando addressed it perfectly, it occurred to me that SIIT RFC(2765) nicely described the translation from ICMPv4 Error Messages to ICMPv6 Error Messages at "ICMP Error" part in section 3.3 page 14. It seems to me better to just put reference to RFC2765 to clarify the error code mapppng between ICMP and ICMPv6 error messages and to clarify that soft/hard classification corresponds to that of RFC1122. Please don't take me wrong, I'm not trying to slow down standardization of this draft ;) > 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's Reaction to Soft Errors > Author(s) : F. Gont > Filename : draft-ietf-tcpm-tcp-soft-errors-06.txt > Pages : 15 > Date : 2007-6-25 > > This document describes a non-standard, but widely implemented, > modification to TCP's handling of ICMP soft error messages, that > rejects pending connection-requests when those error messages are > received. This behavior reduces the likelihood of long delays > between connection establishment attempts that may arise in a number > of scenarios, including one in which dual stack nodes that have IPv6 > enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 > environments. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-soft-errors-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-soft-errors-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-soft-errors-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. > > > ------------------------------------------------------------------------ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm -- Arifumi Matsumoto IP Technology Expert Team Secure Communication Project NTT Information Sharing Platform Laboratories E-mail: arifumi@nttv6.net _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jul 04 06:35:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I62Cz-0005Vl-Ui; Wed, 04 Jul 2007 06:35:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I62Cu-0005Sd-Ej; Wed, 04 Jul 2007 06:35:36 -0400 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 1I62Cp-00088O-Vd; Wed, 04 Jul 2007 06:35:36 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l64AYohQ018159; Wed, 4 Jul 2007 13:35:14 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jul 2007 13:34:50 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jul 2007 13:34:49 +0300 Received: from [172.21.34.161] (esdhcp034161.research.nokia.com [172.21.34.161]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l64AYlnT023391; Wed, 4 Jul 2007 13:34:48 +0300 In-Reply-To: <0E46EBE9-1C13-44B6-9C04-476D418F5A6D@nokia.com> References: <200702111621.l1BGL6mw029875@venus.xmundo.net> <0E46EBE9-1C13-44B6-9C04-476D418F5A6D@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lars Eggert Subject: Re: [Tsvwg] Re: [tcpm] Revision of draft-larsen-tsvwg-port-randomization Date: Wed, 4 Jul 2007 13:34:42 +0300 To: tsvwg WG X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 04 Jul 2007 10:34:49.0993 (UTC) FILETIME=[F319AF90:01C7BE26] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: tcpm@ietf.org, DCCP mailing list , ext Fernando Gont , TSV Dir X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tsvwg WG List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On 2007-5-31, at 17:51, ext Lars Eggert wrote: > The concepts in this draft are likely relevant to most of our > transport protocols, and hence would be in scope for TSVWG. The > TSVWG chairs are interested in comments on whether there is group > interest in this draft - please comment on tsvwg@ietf.org. We've received some positive feedback on adopting this draft, but I'd like to see a stronger show of support, because this draft impacts several of our transport protocols at the same time. Please comment on tsvwg@ietf.org - reply-to set accordingly. Lars _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jul 05 22:20:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6dQx-0003bC-7L; Thu, 05 Jul 2007 22:20:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6dQw-0003b6-NX for tcpm@ietf.org; Thu, 05 Jul 2007 22:20:34 -0400 Received: from mailer1.psc.edu ([128.182.58.100]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6dQw-0005T6-Fd for tcpm@ietf.org; Thu, 05 Jul 2007 22:20:34 -0400 Received: from [192.168.0.103] (rdbck-3869.wasilla.mtaonline.net [12.104.83.59]) (authenticated bits=0) by mailer1.psc.edu (8.13.8/8.13.3) with ESMTP id l662JnLD021576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jul 2007 22:19:53 -0400 (EDT) Message-ID: <468DA6C1.5060107@psc.edu> Date: Thu, 05 Jul 2007 18:19:45 -0800 From: John Heffner User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) MIME-Version: 1.0 To: Mahesh Jethanandani Subject: Re: [tcpm] New I-D References: <20070221144454.3D3E01827FD@lawyers.icir.org> <45DCC9BB.4010302@psc.edu> <46856FC2.90309@cisco.com> In-Reply-To: <46856FC2.90309@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: tcpm@ietf.org, 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 Mahesh Jethanandani wrote: > Context is the draft - > http://www.ietf.org/internet-drafts/draft-mahesh-persist-timeout-00.txt > > John Heffner wrote: >> 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 > John, > > The issue with Netkill or any other application trying to kill > connections is that they cannot distinguish between connections that are > held up because of network issues where packets are getting dropped and > connections that are in persist state because the client refuses to open > the zero window. TCP can distinguish between the connections and > determine which ones need to go. Wouldn't you agree? > > m/ That's going back a ways. I think I've paged the original thread back in to memory. ;) It may be important to distinguish between recovery and persist (the ESTATS MIB will do this). I mention netkill because it is pretty effective at running the attacked system out of buffer memory without using the persist state. I think a more general defense is better located at the operating system level (either a daemon or in the kernel), since that is the point where resource contention is resolved and policy enforced. Thanks, -John _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jul 05 22:29:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6dZ5-0003lP-KA; Thu, 05 Jul 2007 22:28:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6dZ3-0003lJ-OV for tcpm@ietf.org; Thu, 05 Jul 2007 22:28:57 -0400 Received: from mailer1.psc.edu ([128.182.58.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6dYw-0001An-Mh for tcpm@ietf.org; Thu, 05 Jul 2007 22:28:57 -0400 Received: from [192.168.0.103] (rdbck-3869.wasilla.mtaonline.net [12.104.83.59]) (authenticated bits=0) by mailer1.psc.edu (8.13.8/8.13.3) with ESMTP id l662Qhjq001479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jul 2007 22:26:44 -0400 (EDT) Message-ID: <468DA85C.1000500@psc.edu> Date: Thu, 05 Jul 2007 18:26:36 -0800 From: John Heffner User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) MIME-Version: 1.0 To: Sally Floyd Subject: Re: [tcpm] taking RFC 2861 (Congestion Window Validation) to Proposed Standard? References: <46770412.8090307@psc.edu> <46ffa03042528d92a9ea2875e1764b19@mac.com> In-Reply-To: <46ffa03042528d92a9ea2875e1764b19@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Murari Sridharan , Jitu Padhye , tcpm , Mark Handley 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 Sally Floyd wrote: > John - > > (Apologies, as always, for the late reply.) > >> There have been enough reports of performance problems with >> intrinsically bursty applications that an option was added to Linux to >> disable cwnd decay. (It is still enabled by default.) I'm not aware >> of any issues with the "not raising cwnd when application-limited" part. > > I understand that bursty applications would often rather not reduce > cwnd after an idle or application-limited periiod. (It *might* be > in their own interests, if it helps the flow to avoid unnecessary > packet drops, but it *might not* be in their own interests, e.g., > if that flow doesn't receive any packet drops when bursting after > an idle period. > > But the following question also matters: > > (1) What about when there are N possibly-bursty flows sharing the > same congested link? Are there any reports about whether the *N > flows* do better when all flows use CWV, or whether they do better > when none of them use CWV, and none of them reduce cwnd after an > idle period? > > (If there is no congestion, I would expect that the N flows do > better without CWV. If there *is* congestion, I would expect that > the N flows in general do better *with* CWV, as opposed to not > reducing cwnd after idle periods. But it is not something that one > could tell from reports from individual users...) This agrees with my intuition, for what it's worth. :) I'm not aware of any experiments along these lines. I'm also really interested in how much difference pacing out bursts after an idle period might make. Thanks, -John _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 09 15:16:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7yiJ-0001eU-TJ; Mon, 09 Jul 2007 15:16:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7yi8-000199-OZ; Mon, 09 Jul 2007 15:15:52 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7yi8-0003D5-G2; Mon, 09 Jul 2007 15:15:52 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 59E652AC75; Mon, 9 Jul 2007 19:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I7yhK-0001vZ-1i; Mon, 09 Jul 2007 15:15:02 -0400 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, 09 Jul 2007 15:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-ecnsyn-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 : Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets Author(s) : A. Kuzmanovic, et al. Filename : draft-ietf-tcpm-ecnsyn-02.txt,.ps Pages : 22 Date : 2007-7-9 This draft specifies a modification to RFC 3168 to allow TCP SYN/ACK packets to be ECN-Capable. For TCP, RFC 3168 only specifies setting an ECN-Capable codepoint on data packets, and not on SYN and SYN/ACK packets. However, because of the high cost to the TCP transfer of having a SYN/ACK packet dropped, with the resulting retransmit timeout, this document specifies the use of ECN for the SYN/ACK packet itself, when sent in response to a SYN packet with the two ECN flags set in the TCP header, indicating a willingness to use ECN. Setting TCP SYN/ACK packets as ECN-Capable can be of great benefit to the TCP connection, avoiding the severe penalty of a retransmit timeout for a connection that has not yet started placing a load on the network. The sender of the SYN/ACK packet must respond to a report of an ECN-marked SYN/ACK packet by reducing its initial congestion window from two, three, or four segments to one segment, thereby reducing the subsequent load from that connection on the network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-ecnsyn-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-ecnsyn-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-ecnsyn-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-7-9142333.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-ecnsyn-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-ecnsyn-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-9142333.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 Tue Jul 10 16:59:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Mnp-0004XB-PS; Tue, 10 Jul 2007 16:59:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Mno-0004Sy-Hc for tcpm@ietf.org; Tue, 10 Jul 2007 16:59:20 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8Mnk-0003QA-4x for tcpm@ietf.org; Tue, 10 Jul 2007 16:59:20 -0400 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 l6AKxFYq022207 for ; Tue, 10 Jul 2007 13:59:15 -0700 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 ADA73CAB11E for ; Tue, 10 Jul 2007 16:59:09 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 3299725CF9E for ; Tue, 10 Jul 2007 16:59:06 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Panama MIME-Version: 1.0 Date: Tue, 10 Jul 2007 16:59:06 -0400 Message-Id: <20070710205906.3299725CF9E@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Subject: [tcpm] Chicago agenda 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="===============1431732691==" Errors-To: tcpm-bounces@ietf.org --===============1431732691== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Folks- Below is the current agenda for the TCPM meeting in Chicago. We do not expect any major changes at this time, but one never knows. Please endeavor to read through the drafts we are going to be discussing. There are important questions we want to discuss on each of the documents. Thanks, allman TCPM WG Agenda Thu, July 26 2007, 1300-1500 Administravia: TCPM + TCP-AUTH Design Team Status chairs 15 minutes WG Items: tcpsecure Randall Stewart draft-ietf-tcpm-tcpsecure-08.txt 15 minutes Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets Sally Floyd draft-ietf-tcpm-ecnsyn-02.txt 10 minutes Maintenance Items: Advanceing RFC 4138 Pasi Sarolahti draft-ietf-tcpm-rfc4138bis-00.txt draft-kojo-tcpm-frto-eval-00.txt 15 minutes Revision of RFC 1323 David Borman draft-borman-1323bis-00.txt 15 minutes Non-WG Items: Adding Acknowledgement Congestion Control to TCP Sally Floyd draft-floyd-tcpm-ackcc-01.txt 12 minutes RFC 2861 on TCP Congestion Window Validation Sally Floyd 12 minutes Early Retransmit for TCP and SCTP Mark Allman draft-allman-tcp-early-rexmt-05.txt 12 minutes A TCP Test to Allow Senders to Identify Receiver Non-Compliance Toby Moncaster draft-moncaster-tcpm-rcv-cheat-01.txt 12 minutes --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGk/MaWyrrWs4yIs4RAn3sAKCOENlmUICqwyZv/STv3Gfn0yazCQCfVCgQ FwpR/N1n5G5NkFmTRqJKD4U= =1iyp -----END PGP SIGNATURE----- --=_bOundary-- --===============1431732691== 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 --===============1431732691==-- From tcpm-bounces@ietf.org Tue Jul 10 17:15:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8N3C-0000Lw-2x; Tue, 10 Jul 2007 17:15:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8N30-0000CO-OQ; Tue, 10 Jul 2007 17:15:02 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8N30-0003mh-El; Tue, 10 Jul 2007 17:15:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 3832926EB9; Tue, 10 Jul 2007 21:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I8N2z-00017O-VI; Tue, 10 Jul 2007 17:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 10 Jul 2007 17:15:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-tcpsecure-08.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-08.txt Pages : 26 Date : 2007-7-10 TCP has historically been considered protected against spoofed off- path 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 longer term connections (e.g. H-323 or Border Gateway Protocol [RFC4271]) have left modern TCP implementations 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 systematically guessing 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-08.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-08.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-08.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-7-10164003.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-tcpsecure-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-tcpsecure-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-10164003.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 Thu Jul 12 19:51:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I98RJ-0002Eu-PU; Thu, 12 Jul 2007 19:51:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I98RG-0002En-DU for tcpm@ietf.org; Thu, 12 Jul 2007 19:51:15 -0400 Received: from smtpout.mac.com ([17.250.248.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I98RC-0001Tj-1c for tcpm@ietf.org; Thu, 12 Jul 2007 19:51:14 -0400 Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (Xserve/smtpout05/MantshX 4.0) with ESMTP id l6CNp3aq012080; Thu, 12 Jul 2007 16:51:03 -0700 (PDT) Received: from [192.150.186.170] (laptop170.icsi.berkeley.edu [192.150.186.170]) (authenticated bits=0) by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id l6CNp2IB026490; Thu, 12 Jul 2007 16:51:02 -0700 (PDT) In-Reply-To: <4685BEA0.8070705@mail.eecis.udel.edu> References: <46770412.8090307@psc.edu> <46ffa03042528d92a9ea2875e1764b19@mac.com> <4685BEA0.8070705@mail.eecis.udel.edu> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Sally Floyd Subject: Re: [tcpm] taking RFC 2861 (Congestion Window Validation) to Proposed Standard? Date: Thu, 12 Jul 2007 16:51:01 -0700 To: iyengar@cis.udel.edu X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Murari Sridharan , Jitu Padhye , tcpm , Mark Handley 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'm generally happy enough with RFC 2861 to support it to go to > Proposed Standard. But, if we do not know more (or enough) about the > implications of CWV than we did when RFC2861 was published, on what > basis do we recommend that it change status? > > A show of hands by folks who know that it is used and has not caused > complaints would also be very useful, IMHO. Yes, I agree. - Sally http://www.icir.org/floyd/ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jul 12 20:13:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I98nF-0005Ii-B3; Thu, 12 Jul 2007 20:13:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I98nD-0005Fa-VM for tcpm@ietf.org; Thu, 12 Jul 2007 20:13:55 -0400 Received: from smtpout.mac.com ([17.250.248.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I98n9-0001wN-IK for tcpm@ietf.org; Thu, 12 Jul 2007 20:13:55 -0400 Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (Xserve/smtpout05/MantshX 4.0) with ESMTP id l6D0Deiv024296; Thu, 12 Jul 2007 17:13:41 -0700 (PDT) Received: from [192.150.186.170] (laptop170.icsi.berkeley.edu [192.150.186.170]) (authenticated bits=0) by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id l6D0DeCS007401; Thu, 12 Jul 2007 17:13:40 -0700 (PDT) In-Reply-To: <468DA85C.1000500@psc.edu> References: <46770412.8090307@psc.edu> <46ffa03042528d92a9ea2875e1764b19@mac.com> <468DA85C.1000500@psc.edu> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <350d2cecde2aa453588abd6c8f72882c@mac.com> Content-Transfer-Encoding: 7bit From: Sally Floyd Subject: Re: [tcpm] taking RFC 2861 (Congestion Window Validation) to Proposed Standard? Date: Thu, 12 Jul 2007 17:13:40 -0700 To: John Heffner X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Murari Sridharan , Jitu Padhye , tcpm , Mark Handley 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 understand that bursty applications would often rather not reduce >> cwnd after an idle or application-limited periiod. (It *might* be >> in their own interests, if it helps the flow to avoid unnecessary >> packet drops, but it *might not* be in their own interests, e.g., >> if that flow doesn't receive any packet drops when bursting after >> an idle period. >> But the following question also matters: >> (1) What about when there are N possibly-bursty flows sharing the >> same congested link? Are there any reports about whether the *N >> flows* do better when all flows use CWV, or whether they do better >> when none of them use CWV, and none of them reduce cwnd after an >> idle period? >> (If there is no congestion, I would expect that the N flows do >> better without CWV. If there *is* congestion, I would expect that >> the N flows in general do better *with* CWV, as opposed to not >> reducing cwnd after idle periods. But it is not something that one >> could tell from reports from individual users...) > > > This agrees with my intuition, for what it's worth. :) I'm not aware > of any experiments along these lines. I'm also really interested in > how much difference pacing out bursts after an idle period might make. Many thanks. I assume that pacing would be a big win, with or without Congestion Window Validation. (With CWV, the window is not set right away to the initial window, but is halved each RTO.) RFC 2861 also has a paragraph at the end of Section 2 arguing that pacing by itself would not be sufficient, without *some* reduction of cwnd after a long idle period. (Would one really want connections with a cwnd of 1000 packets or more to start up with that cwnd after an idle period of an hour? With or pacing? Even though there very well *might* not be any congestion after the hour-long idle period?) - Sally http://www.icir.org/floyd/ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Jul 13 14:24:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9PoB-00044c-MR; Fri, 13 Jul 2007 14:24:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Po9-00044I-Hg for tcpm@ietf.org; Fri, 13 Jul 2007 14:24:01 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9Po9-0004Rb-8I for tcpm@ietf.org; Fri, 13 Jul 2007 14:24:01 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 13 Jul 2007 11:24:00 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAGRgl0arR7MV/2dsb2JhbAA X-IronPort-AV: i="4.16,537,1175497200"; d="scan'208"; a="503063521:sNHT26986314" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6DIO0J1026380; Fri, 13 Jul 2007 11:24:00 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6DINoXt019580; Fri, 13 Jul 2007 18:24:00 GMT 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); Fri, 13 Jul 2007 11:23:59 -0700 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: Fri, 13 Jul 2007 11:23:56 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5803A3AD96@xmb-sjc-21c.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New version of tcp-secure draft. Thread-Index: AcfFevk+7VANEEmKRrON2huHuYJ8Eg== From: "Anantha Ramaiah \(ananth\)" To: X-OriginalArrivalTime: 13 Jul 2007 18:23:59.0344 (UTC) FILETIME=[FB238700:01C7C57A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1038; t=1184351040; x=1185215040; 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:=20New=20version=20of=20tcp-secure=20draft. |Sender:=20; bh=f+1TZFSsH1jeeGXsL0Fy682D10avDg0geqz4WOZFkuw=; b=s9D3oBQRPIYlkqLsmd7356hIDiITTzTZoFych4K/jUuqoWYHBg5oHRljZHIYqbZ9Zg4Z2XAj NL6jhKAQzUC1eGg7WY9415GOeqQmd3HY2uJfh6O8onO2VGrdT2jiP/L09qpBvtGp1yHhB7buSt k3AZ2VRJnRevvy2YWd8Dn/sA4=; 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: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Ted Faber , mallman@icir.org Subject: [tcpm] New version of tcp-secure draft. 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, I have posted the new version of tcp-secure which incorporates the comments received on the previous version (07) http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-08.txt Briefly the changes are :- - editorial, grammar changes. Incoporated comments received from Ted Faber, Alfred Hoenes, Toby and others. - Added more clarifications on the data-injection section. Also added a note on its usefulness in dealing with spoofed FIN segments. This was done in response to Ted's suggestion. The pending issue seems to be the strength of each mitigations (MUST, SHOULD or MAY). This would be discussed in the TCPM meeting this time. As usual comments welcome. We would like to get this to WGLC soon. There have been many changes made (editorial, format/grammar, techincal changes etc., )in the past 4-5 versions and we believe this document is in a pretty good shape to move forward. We take this moment to appreciate your valuable comments received on this so far.=20 Thanks, -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jul 18 23:39:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBMqq-0003ka-Ki; Wed, 18 Jul 2007 23:38:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBMqq-0003kU-2i for tcpm@ietf.org; Wed, 18 Jul 2007 23:38:52 -0400 Received: from smtp.microsoft.com ([131.107.115.215]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBMqp-0002QO-Nb for tcpm@ietf.org; Wed, 18 Jul 2007 23:38:51 -0400 Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.700.0; Wed, 18 Jul 2007 20:38:50 -0700 Received: from NA-EXMSG-C110.redmond.corp.microsoft.com ([157.54.62.162]) by TK5-EXHUB-C102.redmond.corp.microsoft.com ([157.54.70.72]) with mapi; Wed, 18 Jul 2007 20:38:50 -0700 From: Murari Sridharan To: "iccrg@cs.ucl.ac.uk" , "tcpm@ietf.org" , "'lars.eggert@nokia.com'" , "weddy@grc.nasa.gov" Date: Wed, 18 Jul 2007 20:38:46 -0700 Thread-Topic: Compound TCP: draft-sridharan-tcpm-ctcp-00.txt Thread-Index: AcfJtlAH8WAvXe+FTUmOGlMZvB6iJA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: "Deepak Bansal \(NETWORKING\)" , Dave Thaler Subject: [tcpm] Compound TCP: draft-sridharan-tcpm-ctcp-00.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: , Content-Type: multipart/mixed; boundary="===============1886966874==" Errors-To: tcpm-bounces@ietf.org --===============1886966874== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_FCA794787FDE0D4DBE9FFA11053ECEB60C25A76D2ANAEXMSGC110re_" --_000_FCA794787FDE0D4DBE9FFA11053ECEB60C25A76D2ANAEXMSGC110re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, We have written a Experimental RFC for Compound TCP. You can find the curre= nt draft at http://research.microsoft.com/users/dthaler/draft-sridharan-tcp= m-ctcp-00.txt This is to kick off the process outlined in Lars' cc-alt ION. We will also = be presenting Compound TCP at the ICCRG meeting in Chicago next week. Thanks --_000_FCA794787FDE0D4DBE9FFA11053ECEB60C25A76D2ANAEXMSGC110re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

We have written a Experimental RFC for Compound TCP. Y= ou can find the current draft at http://research.microsoft.com/users/dthaler/draft-sridharan-tcpm= -ctcp-00.txt

This is to kick off the process outlined in Lars’ cc-alt = ION. We will also be presenting Compound TCP at the ICCRG meeting in Chicago nex= t week.

 

Thanks

 

 

--_000_FCA794787FDE0D4DBE9FFA11053ECEB60C25A76D2ANAEXMSGC110re_-- --===============1886966874== 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 --===============1886966874==-- From tcpm-bounces@ietf.org Thu Jul 19 00:27:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBNbb-0001Nt-OX; Thu, 19 Jul 2007 00:27:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBNbV-0001NL-U6; Thu, 19 Jul 2007 00:27:05 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBNbV-0003En-D7; Thu, 19 Jul 2007 00:27:05 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6J4QHVV002914; Thu, 19 Jul 2007 07:27:03 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 07:27:02 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 07:27:02 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 07:27:01 +0300 Received: from [10.130.5.118] (essapo-nirac252186.europe.nokia.com [10.162.252.186]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6J4QxxK021359; Thu, 19 Jul 2007 07:27:00 +0300 Mime-Version: 1.0 (Apple Message framework v752.3) To: TSV Area Message-Id: <32A448E7-1FE9-4C5C-B009-0155F3B568A8@nokia.com> From: Lars Eggert Date: Thu, 19 Jul 2007 07:26:53 +0300 X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 19 Jul 2007 04:27:01.0554 (UTC) FILETIME=[0D7B6120:01C7C9BD] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: tcpm@ietf.org Subject: [tcpm] bringing new congestion control to the IETF 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="===============0369822427==" Errors-To: tcpm-bounces@ietf.org --===============0369822427== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-36-353583946; protocol="application/pkcs7-signature" --Apple-Mail-36-353583946 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, folks may want to attend the ICCRG meeting next week. The agenda (http://tools.ietf.org/agenda/69/iccrg.html) has at least one presentation of a congestion control scheme that will undergo ICCRG review following the recently approved process in ion-tsv-alt- cc.txt, and may hence pop up in TCPM at a future time. (The ION is still at http://www3.tools.ietf.org/group/iesg/trac/ browser/ions/drafts/ion-tsv-alt-cc.txt but will appear at http:// www.ietf.org/IESG/content/ions/ shortly). Lars --Apple-Mail-36-353583946 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 MBwGCSqGSIb3DQEJBTEPFw0wNzA3MTkwNDI2NTRaMCMGCSqGSIb3DQEJBDEWBBSxTZqRHPvAeTxa fT7LO/cWdb3ybTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAjTjwFYjWjxV2ZIbUPWdFG1K+fDnMCM2qJsCh3LpKB8b9knf9l9HW DSmM/mUmZ3FMY+GqZJ+jzsQN/rUNloQOUxzVpcOMNjPDOq6ENKfbA1zP1TbA8b6UL9Ru+dYzHZ89 SA4UAsrY5Zj1c43rTMFQtaE9JEYQpFgzh6xpd0+16zXHYIeHqSbA4/+JNJuWfVEwq5cvWwBKFzyC y6bVnZkMffdelVnTQ+O4xG5FN2BabMmRviKBfhkfaISEKhnLSCp8+diggeP/BW0kElQPHHcfgGpI bePOlMLhD0ALuYqcsDbKips9IxpGrAbrszSBitQili/2VM/GULM13iPP91TTbQAAAAAAAA== --Apple-Mail-36-353583946-- --===============0369822427== 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 --===============0369822427==-- From tcpm-bounces@ietf.org Thu Jul 19 20:22:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBgFq-0003F6-UF; Thu, 19 Jul 2007 20:21:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBgFp-0003F1-Nm for tcpm@ietf.org; Thu, 19 Jul 2007 20:21:57 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBgFo-0006v3-Bd for tcpm@ietf.org; Thu, 19 Jul 2007 20:21:57 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 19 Jul 2007 17:21:31 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigcAAidn0arR7O6/2dsb2JhbACCLjeFeZ16 X-IronPort-AV: i="4.16,559,1175497200"; d="scan'208,217"; a="185265103:sNHT3467432223" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6K0LVXj007197; Thu, 19 Jul 2007 17:21:31 -0700 Received: from [171.69.75.156] (dhcp-171-69-75-156.cisco.com [171.69.75.156]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l6K0LUSb003853; Fri, 20 Jul 2007 00:21:30 GMT Message-ID: <46A00008.7060603@cisco.com> Date: Thu, 19 Jul 2007 17:21:28 -0700 From: Mahesh Jethanandani Organization: Cisco Systems Inc. User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: John Heffner Subject: Re: [tcpm] New I-D References: <20070221144454.3D3E01827FD@lawyers.icir.org> <45DCC9BB.4010302@psc.edu> <46856FC2.90309@cisco.com> <468DA6C1.5060107@psc.edu> In-Reply-To: <468DA6C1.5060107@psc.edu> DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8360; t=1184890891; x=1185754891; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mahesh@cisco.com; z=From:=20Mahesh=20Jethanandani=20 |Subject:=20Re=3A=20[tcpm]=20New=20I-D |Sender:=20; bh=bRGxA0XroBKFfjcsTGaUwInnvRH0MY2c/VKEU2i05/U=; b=qG7koO6SejzusPFFLMQu5uI4eg9TtlhbVMYLLW52HClt8aBBaisVeIxz4QCpTET+WO6jB1ZL Op+Z4Jo/LHEGVE8so3Fc0tvv+sXr+RGNziFBPlRnSsZZVNohd5mse1eJ; Authentication-Results: sj-dkim-2; header.From=mahesh@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: tcpm@ietf.org, 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: , Content-Type: multipart/mixed; boundary="===============0961435540==" Errors-To: tcpm-bounces@ietf.org This is a multi-part message in MIME format. --===============0961435540== Content-Type: multipart/alternative; boundary="------------000301070604020009000002" This is a multi-part message in MIME format. --------------000301070604020009000002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit John Heffner wrote: > Mahesh Jethanandani wrote: >> Context is the draft - >> http://www.ietf.org/internet-drafts/draft-mahesh-persist-timeout-00.txt >> >> John Heffner wrote: >>> 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 >> John, >> >> The issue with Netkill or any other application trying to kill >> connections is that they cannot distinguish between connections that >> are held up because of network issues where packets are getting >> dropped and connections that are in persist state because the client >> refuses to open the zero window. TCP can distinguish between the >> connections and determine which ones need to go. Wouldn't you agree? >> >> m/ > > That's going back a ways. I think I've paged the original thread back > in to memory. ;) > > It may be important to distinguish between recovery and persist (the > ESTATS MIB will do this). I mention netkill because it is pretty > effective at running the attacked system out of buffer memory without > using the persist state. I think a more general defense is better > located at the operating system level (either a daemon or in the > kernel), since that is the point where resource contention is resolved > and policy enforced. > > Thanks, > -John General defense - yes. Operating system can enforce a maximum number of resource allocation to TCP to prevent it from exhausting all the buffers. Let us further assume that the operating system enforces a per connection buffer utilization count. Now suppose one was to write a resource contention daemon or do this as part of the kernel. What would be the information it would need? It would need per connection buffer utilization, how long the buffers have been on that connection, what is the state of the connection (assume it gets it from the MIB, which BTW gets it from TCP), how many times the connection has entered or exited this condition (in case someone is trying to fool the system), information that is part of TCP. So you can peek into the TCP connection table, extract all the information needed to make the determination or let TCP manage the buffers that it has borrowed from the operating system and is ultimately responsible for. Without that intimate knowledge of each connection, I can think of at least two scenarios that can stump an operating system. * Large number of connections with one buffer each in persist condition, where the total number of buffers exceed the amount set as the upper limit set by the operating system. Without the OS knowing that the connection is in persist condition AND for how long (after all you do not want to whack a connection just because it entered persist condition), how does it determine if the connection should be torn down or not. * Fewer than a large number of connection mentioned above each in persist condition, where the numbers are short of the max. buffers per connection but the total number of buffers by all connections exceeds the max. count set by the OS for all of TCP. Now the sender can run out of buffers sooner and with fewer connection setups. This all assumes that TCP always runs as part of an operating system. Is that assumption always true? --------------000301070604020009000002 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

John Heffner wrote:
Mahesh Jethanandani wrote:
Context is the draft - http://www.ietf.org/internet-drafts/draft-mahesh-persist-timeout-00.txt

John Heffner wrote:
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
John,

The issue with Netkill or any other application trying to kill connections is that they cannot distinguish between connections that are held up because of network issues where packets are getting dropped and connections that are in persist state because the client refuses to open the zero window. TCP can distinguish between the connections and determine which ones need to go. Wouldn't you agree?

m/

That's going back a ways.  I think I've paged the original thread back in to memory. ;)

It may be important to distinguish between recovery and persist (the ESTATS MIB will do this).  I mention netkill because it is pretty effective at running the attacked system out of buffer memory without using the persist state.  I think a more general defense is better located at the operating system level (either a daemon or in the kernel), since that is the point where resource contention is resolved and policy enforced.

Thanks,
  -John
General defense - yes. Operating system can enforce a maximum number of resource allocation to TCP to prevent it from exhausting all the buffers. Let us further assume that the operating system enforces a per connection buffer utilization count.

Now suppose one was to write a resource contention daemon or do this as part of the kernel. What would be the information it would need? It would need per connection buffer utilization, how long the buffers have been on that connection, what is the state of the connection (assume it gets it from the MIB, which BTW gets it from TCP), how many times the connection has entered or exited this condition (in case someone is trying to fool the system), information that is part of TCP. So you can peek into the TCP connection table, extract all the information needed to make the determination or let TCP manage the buffers that it has borrowed from the operating system and is ultimately responsible for.

Without that intimate knowledge of each connection, I can think of at least two scenarios that can stump an operating system.
  • Large number of connections with one buffer each in persist condition, where the total number of buffers exceed the amount set as the upper limit set by the operating system. Without the OS knowing that the connection is in persist condition AND for how long (after all you do not want to whack a connection just because it entered persist condition), how does it determine if the connection should be torn down or not.
  • Fewer than a large number of connection mentioned above each in persist condition, where the numbers are short of the max. buffers per connection but the total number of buffers by all connections exceeds the max. count set by the OS for all of TCP. Now the sender can run out of buffers sooner and with fewer connection setups.
This all assumes that TCP always runs as part of an operating system. Is that assumption always true?
--------------000301070604020009000002-- --===============0961435540== 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 --===============0961435540==-- From tcpm-bounces@ietf.org Tue Jul 24 19:39:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDTy6-0002Li-7S; Tue, 24 Jul 2007 19:39:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDTy5-0002Lc-8L for tcpm@ietf.org; Tue, 24 Jul 2007 19:39:05 -0400 Received: from smtpout.mac.com ([17.250.248.186]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDTy4-0001Ag-Os for tcpm@ietf.org; Tue, 24 Jul 2007 19:39:05 -0400 Received: from mac.com (smtpin04-en2 [10.13.10.149]) by smtpout.mac.com (Xserve/smtpout16/MantshX 4.0) with ESMTP id l6ONd10F006977; Tue, 24 Jul 2007 16:39:01 -0700 (PDT) Received: from [130.129.32.125] (dhcp-207d.ietf69.org [130.129.32.125]) (authenticated bits=0) by mac.com (Xserve/smtpin04/MantshX 4.0) with ESMTP id l6ONcVGC023660; Tue, 24 Jul 2007 16:38:40 -0700 (PDT) In-Reply-To: <20070710205906.3299725CF9E@lawyers.icir.org> References: <20070710205906.3299725CF9E@lawyers.icir.org> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5d38d027a8a0e2c0753ae24d652103e7@mac.com> Content-Transfer-Encoding: 7bit From: Sally Floyd Subject: Re: [tcpm] Chicago agenda Date: Tue, 24 Jul 2007 16:38:33 -0700 To: mallman@icir.org X-Mailer: Apple Mail (2.624) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes 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 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org My slides for TCPM are here: Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets, http://www.icir.org/floyd/talks/ecnsyn-jul07.pdf, .ppt Adding Acknowledgement Congestion Control to TCP, http://www.icir.org/floyd/talks/ackcc-jul07.pdf, .ppt Should RFC 2861 on TCP Congestion Window Validation move towards Proposed Standard? http://www.icir.org/floyd/talks/rfc2861-jul07.pdf, .ppt - Sally http://www.icir.org/floyd/ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jul 24 19:54:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDUCk-0003Xn-6A; Tue, 24 Jul 2007 19:54:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDUCj-0003Xi-5m for tcpm@ietf.org; Tue, 24 Jul 2007 19:54:13 -0400 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDUCi-0001NY-Oi for tcpm@ietf.org; Tue, 24 Jul 2007 19:54:13 -0400 Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.64]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 00:54:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Jul 2007 00:54:22 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TCPM Agenda Chicago Thread-Index: AcfOTfT17yR4afZKR5W0Y8oIk8OKUw== From: To: X-OriginalArrivalTime: 24 Jul 2007 23:54:11.0943 (UTC) FILETIME=[EEE97770:01C7CE4D] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: tcpm@ietf.org Subject: [tcpm] TCPM Agenda Chicago 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="===============0444425085==" Errors-To: tcpm-bounces@ietf.org This is a multi-part message in MIME format. --===============0444425085== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7CE4D.EEB1CAB0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7CE4D.EEB1CAB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My presentation for Chicago IETF is here (PPT and PDF): http://www.cs.ucl.ac.uk/staff/B.Briscoe/present.html#0707tcpm-rcv-cheat Toby Moncaster=20 ________________________________________________________________________ ____ Toby Moncaster, Networks Research Centre, BT Research B54/70 Adastral Park, Martlesham Heath, Ipswich, IP53RE, UK. +44 1473 648734=20 ------_=_NextPart_001_01C7CE4D.EEB1CAB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable TCPM Agenda Chicago

My presentation for Chicago IETF is = here (PPT and PDF):

http://www.cs.ucl.ac.uk/staff/B.Briscoe/present.html#0707t= cpm-rcv-cheat

Toby Moncaster
____________________________________________________________________= ________
Toby Moncaster, = <toby.moncaster@bt.com> Networks Research Centre, BT = Research
B54/70 Adastral Park, Martlesham = Heath, Ipswich, IP53RE, UK.  +44 1473 648734=20

------_=_NextPart_001_01C7CE4D.EEB1CAB0-- --===============0444425085== 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 --===============0444425085==-- From tcpm-bounces@ietf.org Wed Jul 25 11:30:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDioR-0006GQ-Be; Wed, 25 Jul 2007 11:30:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDioQ-0006GK-Dw for tcpm@ietf.org; Wed, 25 Jul 2007 11:30:06 -0400 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDioP-0001j1-Nb for tcpm@ietf.org; Wed, 25 Jul 2007 11:30:06 -0400 Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.700.0; Wed, 25 Jul 2007 08:30:01 -0700 Received: from NA-EXMSG-C110.redmond.corp.microsoft.com ([157.54.62.150]) by tk1-exhub-c104.redmond.corp.microsoft.com ([157.56.116.117]) with mapi; Wed, 25 Jul 2007 08:30:00 -0700 From: Murari Sridharan To: Sally Floyd , "iyengar@cis.udel.edu" Date: Wed, 25 Jul 2007 08:29:58 -0700 Subject: RE: [tcpm] taking RFC 2861 (Congestion Window Validation) to Proposed Standard? Thread-Topic: [tcpm] taking RFC 2861 (Congestion Window Validation) to Proposed Standard? Thread-Index: AcfE34x4/kaoy+I9QP6mb/us7yMztgJ8FhxQ Message-ID: References: <46770412.8090307@psc.edu> <46ffa03042528d92a9ea2875e1764b19@mac.com> <4685BEA0.8070705@mail.eecis.udel.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: -8.0 (--------) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Jitu Padhye , tcpm , Mark Handley 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 Most modern stacks use fairly high-resolution timers to track Rtt and hence= Rto which means Rto's can be small (although usually there is a minimum en= forced). Given that is the case, this may be disadvantageous to application= s that don't react "fast" enough. We have had code to decay cwnd on idle pe= riods for a while now, but it has been disabled by default. -----Original Message----- From: Sally Floyd [mailto:sallyfloyd@mac.com] Sent: Thursday, July 12, 2007 4:51 PM To: iyengar@cis.udel.edu Cc: Murari Sridharan; Mark Handley; Jitu Padhye; tcpm Subject: Re: [tcpm] taking RFC 2861 (Congestion Window Validation) to Propo= sed Standard? > I'm generally happy enough with RFC 2861 to support it to go to > Proposed Standard. But, if we do not know more (or enough) about the > implications of CWV than we did when RFC2861 was published, on what > basis do we recommend that it change status? > > A show of hands by folks who know that it is used and has not caused > complaints would also be very useful, IMHO. Yes, I agree. - Sally http://www.icir.org/floyd/ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jul 25 14:16:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDlPI-00074b-2K; Wed, 25 Jul 2007 14:16:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDlPG-00070p-1O for tcpm@ietf.org; Wed, 25 Jul 2007 14:16:18 -0400 Received: from smtpout.mac.com ([17.250.248.172]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDlPF-0004ts-L8 for tcpm@ietf.org; Wed, 25 Jul 2007 14:16:17 -0400 Received: from mac.com (smtpin05-en2 [10.13.10.150]) by smtpout.mac.com (Xserve/smtpout02/MantshX 4.0) with ESMTP id l6PIGBfr013871; Wed, 25 Jul 2007 11:16:11 -0700 (PDT) Received: from [130.129.20.179] (dhcp-14b3.ietf69.org [130.129.20.179]) (authenticated bits=0) by mac.com (Xserve/smtpin05/MantshX 4.0) with ESMTP id l6PIEYrb022730; Wed, 25 Jul 2007 11:16:10 -0700 (PDT) In-Reply-To: References: <46770412.8090307@psc.edu> <46ffa03042528d92a9ea2875e1764b19@mac.com> <4685BEA0.8070705@mail.eecis.udel.edu> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <07cf5bd5e81ca05dcb6eab4592ef8300@mac.com> Content-Transfer-Encoding: 7bit From: Sally Floyd Subject: Re: [tcpm] taking RFC 2861 (Congestion Window Validation) to Proposed Standard? Date: Wed, 25 Jul 2007 11:16:12 -0700 To: Murari Sridharan X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: "iyengar@cis.udel.edu" , Jitu Padhye , tcpm , Mark Handley 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 Murari - > Most modern stacks use fairly high-resolution timers to track Rtt and > hence Rto which means Rto's can be small (although usually there is a > minimum enforced). Given that is the case, this may be disadvantageous > to applications that don't react "fast" enough. We have had code to > decay cwnd on idle periods for a while now, but it has been disabled > by default. Many thanks. - Sally http://www.icir.org/floyd/ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jul 25 20:40:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDrOj-0001hP-Dh; Wed, 25 Jul 2007 20:40:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDrOh-0001hH-PI for tcpm@ietf.org; Wed, 25 Jul 2007 20:40:07 -0400 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 1IDrOg-0008CK-7m for tcpm@ietf.org; Wed, 25 Jul 2007 20:40:07 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6Q0doWr014384; Thu, 26 Jul 2007 03:39:55 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jul 2007 03:39:49 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jul 2007 03:39:49 +0300 Received: from [172.28.168.100] ([10.241.58.179]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jul 2007 03:39:49 +0300 In-Reply-To: <20070710205906.3299725CF9E@lawyers.icir.org> References: <20070710205906.3299725CF9E@lawyers.icir.org> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <45C4FCA4-D90B-47BA-884C-4F4F49CB727C@nokia.com> From: Pasi Sarolahti Subject: Re: [tcpm] Chicago agenda Date: Wed, 25 Jul 2007 19:39:41 -0500 To: mallman@icir.org X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 26 Jul 2007 00:39:49.0282 (UTC) FILETIME=[78E80020:01C7CF1D] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) 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: , Content-Type: multipart/mixed; boundary="===============0308406607==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0308406607== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-53-944751417" Content-Transfer-Encoding: 7bit This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-53-944751417 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Jul 10, 2007, at 15:59, ext Mark Allman wrote: > Below is the current agenda for the TCPM meeting in Chicago. We do > not > expect any major changes at this time, but one never knows. Our slides for "Advancing RFC 4138" are available at: http://www.iki.fi/pasi.sarolahti/talks/ietf69-tcpm-frto.pdf - Pasi --Apple-Mail-53-944751417 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGp+1NoNa7NH1G2csRAh/JAKDMcrhjkw7t3q6GOqLMjZoeuwMyGgCfbncU wIJpRk42HpBhWVbVuW71qu0= =7FZk -----END PGP SIGNATURE----- --Apple-Mail-53-944751417-- --===============0308406607== 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 --===============0308406607==-- From tcpm-bounces@ietf.org Thu Jul 26 10:41:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE4XH-0000D4-GU; Thu, 26 Jul 2007 10:41:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE4XG-0000Co-Bd for tcpm@ietf.org; Thu, 26 Jul 2007 10:41:50 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IE4XF-0006K3-VX for tcpm@ietf.org; Thu, 26 Jul 2007 10:41:50 -0400 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 l6QEfmHa008314 for ; Thu, 26 Jul 2007 07:41:49 -0700 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 0F23ED45C5A for ; Thu, 26 Jul 2007 10:41:43 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id C681026E0F7 for ; Thu, 26 Jul 2007 10:41:33 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Take It to the Limit MIME-Version: 1.0 Date: Thu, 26 Jul 2007 10:41:33 -0400 Message-Id: <20070726144133.C681026E0F7@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [tcpm] meeting logistics 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="===============0289728613==" Errors-To: tcpm-bounces@ietf.org --===============0289728613== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Info for today's meeting ... allman Slides: https://datatracker.ietf.org/meeting/69/materials.html Audio stream: http://videolab.uoregon.edu/events/ietf/ Jabber room: tsvwg@jabber.ietf.org --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGqLKdWyrrWs4yIs4RAhT5AJ9AWhDiNsMv8rBUdEYTXx4noX6kLACfQTdm TouyqQqOzR5EkCmb4iUd9iI= =pJDs -----END PGP SIGNATURE----- --=_bOundary-- --===============0289728613== 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 --===============0289728613==-- From tcpm-bounces@ietf.org Thu Jul 26 10:43:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE4YQ-00023I-TV; Thu, 26 Jul 2007 10:43:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE4YK-0001ia-Vn; Thu, 26 Jul 2007 10:42:57 -0400 Received: from mail2.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IE4YK-0006O4-Hs; Thu, 26 Jul 2007 10:42:56 -0400 Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.700.0; Thu, 26 Jul 2007 07:42:55 -0700 Received: from NA-EXMSG-C110.redmond.corp.microsoft.com ([157.54.62.150]) by tk5-exhub-c103.redmond.corp.microsoft.com ([157.54.70.186]) with mapi; Thu, 26 Jul 2007 07:42:55 -0700 From: Murari Sridharan To: tsvwg WG Date: Thu, 26 Jul 2007 07:42:42 -0700 Subject: RE: [Tsvwg] Re: [tcpm] Revision of draft-larsen-tsvwg-port-randomization Thread-Topic: [Tsvwg] Re: [tcpm] Revision of draft-larsen-tsvwg-port-randomization Thread-Index: Ace+JxXMdyd0r6m8RjWOhYwptpupIgRazzkA Message-ID: References: <200702111621.l1BGL6mw029875@venus.xmundo.net> <0E46EBE9-1C13-44B6-9C04-476D418F5A6D@nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ext, "tcpm@ietf.org" , DCCP mailing list , Fernando Gont , TSV Dir 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 this context I wanted to bring up a related issue that might also streng= then this sort of a port randomization proposal. Today the 64k port limitation is starting to become a huge problem and most= often admins add ip addresses to increase the scalability. Given that most= often the destination port (and sometimes the destination address) is well= known, the only scalability left is the source address. Increasing ip addr= esses to improve scalability seems a fairly round about approach and frankl= y doesn't scale well. Given that the 64k limit is not fundamental why not p= rovide a scaling factor similar to the receive window to scale the number o= f usable ports. This also makes randomization much more meaningful because = in certain proxy scenarios the number of connections quickly exhausts the a= vailable ports and at that point the attacker can simply use any port assum= ing he can guess the source address. Murari -----Original Message----- From: Lars Eggert [mailto:lars.eggert@nokia.com] Sent: Wednesday, July 04, 2007 3:35 AM To: tsvwg WG Cc: tcpm@ietf.org; DCCP mailing list; ext Fernando Gont; TSV Dir Subject: Re: [Tsvwg] Re: [tcpm] Revision of draft-larsen-tsvwg-port-randomi= zation On 2007-5-31, at 17:51, ext Lars Eggert wrote: > The concepts in this draft are likely relevant to most of our > transport protocols, and hence would be in scope for TSVWG. The > TSVWG chairs are interested in comments on whether there is group > interest in this draft - please comment on tsvwg@ietf.org. We've received some positive feedback on adopting this draft, but I'd like to see a stronger show of support, because this draft impacts several of our transport protocols at the same time. Please comment on tsvwg@ietf.org - reply-to set accordingly. Lars _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jul 26 10:56:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE4lF-0003WT-V4; Thu, 26 Jul 2007 10:56:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE4lD-0003Vq-8c; Thu, 26 Jul 2007 10:56:15 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IE4lC-0006rb-K5; Thu, 26 Jul 2007 10:56:15 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 26 Jul 2007 07:56:14 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAOBSqEarR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,584,1175497200"; d="scan'208"; a="189078335:sNHT30437271" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l6QEuDb2015410; Thu, 26 Jul 2007 07:56:13 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6QEuD6C019840; Thu, 26 Jul 2007 14:56:13 GMT 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, 26 Jul 2007 07:56:13 -0700 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: [Tsvwg] Re: [tcpm] Revision ofdraft-larsen-tsvwg-port-randomization Date: Thu, 26 Jul 2007 07:56:11 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5803B6C62F@xmb-sjc-21c.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Tsvwg] Re: [tcpm] Revision ofdraft-larsen-tsvwg-port-randomization Thread-Index: Ace+JxXMdyd0r6m8RjWOhYwptpupIgRazzkAAABLFiA= From: "Anantha Ramaiah \(ananth\)" To: "Murari Sridharan" , "tsvwg WG" X-OriginalArrivalTime: 26 Jul 2007 14:56:13.0474 (UTC) FILETIME=[1C457820:01C7CF95] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3405; t=1185461773; x=1186325773; 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[Tsvwg]=20Re=3A=20[tcpm]=20Revision=20ofdraft-larsen- tsvwg-port-randomization |Sender:=20; bh=L5QW9CIDUvaUFTMQwpAlzY/qEeLRhkkbm8X7R/GiTBs=; b=aw8TaeFatxIgO/4c/S0HMabKl3mWRzbegkef4E7wxcB/bm4Bebov2MCZhS7m9iIwlr9YhrEr j8eB/Wao4juChzpjpfphdsMboHdDX5bbVoStSNh9NPR2y2lMG/ukjYO6; 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: 31247fb3be228bb596db9127becad0bc Cc: ext@cisco.com, tcpm@ietf.org, DCCP mailing list , Fernando Gont , TSV Dir 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 Murari, I agree it is good idea to have an extended port range. But dearth of ports is one such issue. We could argue the same about TCP options (there are few drafts which never moved forward, AFAIK). Also you can argue he same about TCP seq#/ack# for better security reasons. I think Mark Allman wrote a document TCPx2 (or something) which basically doubles the TCP header (64 bit seq/ack, 32 ports etc.,) So some of the questions which might come up (aka possible ways of achieving this) - why not have complete change to TCP header ?(like Mark's draft is suggesting). Obviously it almost like "TCP v6". Lots of change needed everywhere :-) - or do it in piecemeal, first buy more TCP option space, standardize any one of the proposals for extending the TCP option space. Then have an extended port option like yu suggest below. Then think about other TCP fields requiring extension. Just a few thoughts. -Anantha > -----Original Message----- > From: Murari Sridharan [mailto:muraris@microsoft.com]=20 > Sent: Thursday, July 26, 2007 7:43 AM > To: tsvwg WG > Cc: ext@cisco.com; tcpm@ietf.org; DCCP mailing list; Fernando=20 > Gont; TSV Dir > Subject: RE: [Tsvwg] Re: [tcpm] Revision=20 > ofdraft-larsen-tsvwg-port-randomization >=20 > In this context I wanted to bring up a related issue that=20 > might also strengthen this sort of a port randomization proposal. >=20 > Today the 64k port limitation is starting to become a huge=20 > problem and most often admins add ip addresses to increase=20 > the scalability. Given that most often the destination port=20 > (and sometimes the destination address) is well known, the=20 > only scalability left is the source address. Increasing ip=20 > addresses to improve scalability seems a fairly round about=20 > approach and frankly doesn't scale well. Given that the 64k=20 > limit is not fundamental why not provide a scaling factor=20 > similar to the receive window to scale the number of usable=20 > ports. This also makes randomization much more meaningful=20 > because in certain proxy scenarios the number of connections=20 > quickly exhausts the available ports and at that point the=20 > attacker can simply use any port assuming he can guess the=20 > source address. >=20 > Murari >=20 > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com] > Sent: Wednesday, July 04, 2007 3:35 AM > To: tsvwg WG > Cc: tcpm@ietf.org; DCCP mailing list; ext Fernando Gont; TSV Dir > Subject: Re: [Tsvwg] Re: [tcpm] Revision of=20 > draft-larsen-tsvwg-port-randomization >=20 > On 2007-5-31, at 17:51, ext Lars Eggert wrote: > > The concepts in this draft are likely relevant to most of our=20 > > transport protocols, and hence would be in scope for TSVWG.=20 > The TSVWG=20 > > chairs are interested in comments on whether there is group=20 > interest=20 > > in this draft - please comment on tsvwg@ietf.org. >=20 > We've received some positive feedback on adopting this draft,=20 > but I'd like to see a stronger show of support, because this=20 > draft impacts several of our transport protocols at the same time. >=20 > Please comment on tsvwg@ietf.org - reply-to set accordingly. >=20 > Lars >=20 >=20 >=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 Thu Jul 26 11:05:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE4tt-0001Y4-Fw; Thu, 26 Jul 2007 11:05:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE4tr-0001Wl-Gp; Thu, 26 Jul 2007 11:05:11 -0400 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IE4tq-0008PL-8q; Thu, 26 Jul 2007 11:05:11 -0400 Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.700.0; Thu, 26 Jul 2007 08:05:09 -0700 Received: from NA-EXMSG-C110.redmond.corp.microsoft.com ([157.54.62.150]) by tk1-exhub-c104.redmond.corp.microsoft.com ([157.56.116.117]) with mapi; Thu, 26 Jul 2007 08:05:09 -0700 From: Murari Sridharan To: "Anantha Ramaiah (ananth)" , tsvwg WG Date: Thu, 26 Jul 2007 08:05:08 -0700 Subject: RE: [Tsvwg] Re: [tcpm] Revision ofdraft-larsen-tsvwg-port-randomization Thread-Topic: [Tsvwg] Re: [tcpm] Revision ofdraft-larsen-tsvwg-port-randomization Thread-Index: Ace+JxXMdyd0r6m8RjWOhYwptpupIgRazzkAAABLFiAAAJKnUA== Message-ID: References: <0C53DCFB700D144284A584F54711EC5803B6C62F@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC5803B6C62F@xmb-sjc-21c.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: -8.0 (--------) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: "tcpm@ietf.org" , mailing list , Fernando Gont , TSV Dir , "ext@cisco.com" , DCCP 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 We'll I guess we need things to be incrementally deployable so I think piec= emeal is more practical. Having said that I am very cautious about any exte= nsibility proposal, primarily around non-compliant devices which makes even= incremental deployment slow down to a crawl, like the problems we are seei= ng with enabling WS by default. Given this option has been around forever a= nd still causes significant connectivity problems so piecemeal options are = not a cake walk either. -----Original Message----- From: Anantha Ramaiah (ananth) [mailto:ananth@cisco.com] Sent: Thursday, July 26, 2007 7:56 AM To: Murari Sridharan; tsvwg WG Cc: ext@cisco.com; tcpm@ietf.org; DCCP mailing list; Fernando Gont; TSV Dir Subject: RE: [Tsvwg] Re: [tcpm] Revision ofdraft-larsen-tsvwg-port-randomiz= ation Murari, I agree it is good idea to have an extended port range. But dearth of ports is one such issue. We could argue the same about TCP options (there are few drafts which never moved forward, AFAIK). Also you can argue he same about TCP seq#/ack# for better security reasons. I think Mark Allman wrote a document TCPx2 (or something) which basically doubles the TCP header (64 bit seq/ack, 32 ports etc.,) So some of the questions which might come up (aka possible ways of achieving this) - why not have complete change to TCP header ?(like Mark's draft is suggesting). Obviously it almost like "TCP v6". Lots of change needed everywhere :-) - or do it in piecemeal, first buy more TCP option space, standardize any one of the proposals for extending the TCP option space. Then have an extended port option like yu suggest below. Then think about other TCP fields requiring extension. Just a few thoughts. -Anantha > -----Original Message----- > From: Murari Sridharan [mailto:muraris@microsoft.com] > Sent: Thursday, July 26, 2007 7:43 AM > To: tsvwg WG > Cc: ext@cisco.com; tcpm@ietf.org; DCCP mailing list; Fernando > Gont; TSV Dir > Subject: RE: [Tsvwg] Re: [tcpm] Revision > ofdraft-larsen-tsvwg-port-randomization > > In this context I wanted to bring up a related issue that > might also strengthen this sort of a port randomization proposal. > > Today the 64k port limitation is starting to become a huge > problem and most often admins add ip addresses to increase > the scalability. Given that most often the destination port > (and sometimes the destination address) is well known, the > only scalability left is the source address. Increasing ip > addresses to improve scalability seems a fairly round about > approach and frankly doesn't scale well. Given that the 64k > limit is not fundamental why not provide a scaling factor > similar to the receive window to scale the number of usable > ports. This also makes randomization much more meaningful > because in certain proxy scenarios the number of connections > quickly exhausts the available ports and at that point the > attacker can simply use any port assuming he can guess the > source address. > > Murari > > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com] > Sent: Wednesday, July 04, 2007 3:35 AM > To: tsvwg WG > Cc: tcpm@ietf.org; DCCP mailing list; ext Fernando Gont; TSV Dir > Subject: Re: [Tsvwg] Re: [tcpm] Revision of > draft-larsen-tsvwg-port-randomization > > On 2007-5-31, at 17:51, ext Lars Eggert wrote: > > The concepts in this draft are likely relevant to most of our > > transport protocols, and hence would be in scope for TSVWG. > The TSVWG > > chairs are interested in comments on whether there is group > interest > > in this draft - please comment on tsvwg@ietf.org. > > We've received some positive feedback on adopting this draft, > but I'd like to see a stronger show of support, because this > draft impacts several of our transport protocols at the same time. > > Please comment on tsvwg@ietf.org - reply-to set accordingly. > > Lars > > > > _______________________________________________ > 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 Jul 26 11:29:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE5HA-0005NU-MR; Thu, 26 Jul 2007 11:29:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE5H8-0005MT-Vc for tcpm@ietf.org; Thu, 26 Jul 2007 11:29:15 -0400 Received: from smtp.microsoft.com ([131.107.115.214]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IE5H8-0007qA-Ib for tcpm@ietf.org; Thu, 26 Jul 2007 11:29:14 -0400 Received: from tk1-exhub-c102.redmond.corp.microsoft.com (157.56.116.113) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.700.0; Thu, 26 Jul 2007 08:29:10 -0700 Received: from NA-EXMSG-C110.redmond.corp.microsoft.com ([157.54.62.150]) by tk1-exhub-c102.redmond.corp.microsoft.com ([157.56.116.113]) with mapi; Thu, 26 Jul 2007 08:29:09 -0700 From: Murari Sridharan To: "iccrg@cs.ucl.ac.uk" , "tcpm@ietf.org" , "'lars.eggert@nokia.com'" , "weddy@grc.nasa.gov" Date: Thu, 26 Jul 2007 08:29:07 -0700 Subject: RE: [tcpm] Compound TCP: draft-sridharan-tcpm-ctcp-00.txt Thread-Topic: [tcpm] Compound TCP: draft-sridharan-tcpm-ctcp-00.txt Thread-Index: AcfJtlAH8WAvXe+FTUmOGlMZvB6iJAF4oBwA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 Cc: "Deepak Bansal \(NETWORKING\)" , Dave Thaler 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="===============1110314049==" Errors-To: tcpm-bounces@ietf.org --===============1110314049== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_FCA794787FDE0D4DBE9FFA11053ECEB60C26A161DCNAEXMSGC110re_" --_000_FCA794787FDE0D4DBE9FFA11053ECEB60C26A161DCNAEXMSGC110re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Posting our IETF presentation and few papers (as requested by iccrg) in pdf= format http://research.microsoft.com/users/dthaler/IETF%20-%20Compound%20TCP.pdf http://research.microsoft.com/users/dthaler/ctcp-infocom06.pdf this is the paper that greatly improves the TCP fairness problems in low-bu= ffered links by automatically tuning the gamma parameter. http://research.microsoft.com/users/dthaler/ctcp-tube.pdf From: Murari Sridharan [mailto:muraris@microsoft.com] Sent: Wednesday, July 18, 2007 8:39 PM To: iccrg@cs.ucl.ac.uk; tcpm@ietf.org; 'lars.eggert@nokia.com'; weddy@grc.n= asa.gov Cc: Deepak Bansal (NETWORKING); Dave Thaler Subject: [tcpm] Compound TCP: draft-sridharan-tcpm-ctcp-00.txt Folks, We have written a Experimental RFC for Compound TCP. You can find the curre= nt draft at http://research.microsoft.com/users/dthaler/draft-sridharan-tcp= m-ctcp-00.txt This is to kick off the process outlined in Lars' cc-alt ION. We will also = be presenting Compound TCP at the ICCRG meeting in Chicago next week. Thanks --_000_FCA794787FDE0D4DBE9FFA11053ECEB60C26A161DCNAEXMSGC110re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Posting our IETF present= ation and few papers (as requested by iccrg) in pdf format

 =

http://research.microsoft.com/users/dthaler/IETF%20-%20Compound%20T= CP.pdf

 =

htt= p://research.microsoft.com/users/dthaler/ctcp-infocom06.pdf<= /span>

 =

this is the paper that g= reatly improves the TCP fairness problems in low-buffered links by automatically tuning the gamma parameter.

http://r= esearch.microsoft.com/users/dthaler/ctcp-tube.pdf

 =

 =

 

From: Murari Sridha= ran [mailto:muraris@microsoft.com]
Sent: Wednesday, July 18, 2007 8:39 PM
To: iccrg@cs.ucl.ac.uk; tcpm@ietf.org; 'lars.eggert@nokia.com'; weddy@grc.nasa.gov
Cc: Deepak Bansal (NETWORKING); Dave Thaler
Subject: [tcpm] Compound TCP: draft-sridharan-tcpm-ctcp-00.txt<= /o:p>

 

Folks,

 

We have written a Experimental RFC for Compound TCP. Y= ou can find the current draft at http://research.microsoft.com/users/dthaler/draft-sridharan-tcpm= -ctcp-00.txt

This is to kick off the process outlined in Lars’ cc-alt = ION. We will also be presenting Compound TCP at the ICCRG meeting in Chicago nex= t week.

 

Thanks

 

 

--_000_FCA794787FDE0D4DBE9FFA11053ECEB60C26A161DCNAEXMSGC110re_-- --===============1110314049== 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 --===============1110314049==-- From tcpm-bounces@ietf.org Thu Jul 26 14:58:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE8Xd-0005jR-Kp; Thu, 26 Jul 2007 14:58:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE8XZ-0005iX-71; Thu, 26 Jul 2007 14:58:25 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IE8XY-0005GP-Kp; Thu, 26 Jul 2007 14:58:25 -0400 Received: from [130.129.37.253] (dhcp-25fd.ietf69.org [130.129.37.253]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l6QIw7rU003696; Thu, 26 Jul 2007 11:58:07 -0700 (PDT) Message-ID: <46A8EEB8.2000304@isi.edu> Date: Thu, 26 Jul 2007 11:58:00 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Murari Sridharan Subject: Re: [Tsvwg] Re: [tcpm] Revision of draft-larsen-tsvwg-port-randomization References: <200702111621.l1BGL6mw029875@venus.xmundo.net> <0E46EBE9-1C13-44B6-9C04-476D418F5A6D@nokia.com> In-Reply-To: X-Enigmail-Version: 0.95.2 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: TSV Dir , "tcpm@ietf.org" , DCCP mailing list , tsvwg WG , 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: , Content-Type: multipart/mixed; boundary="===============0387152500==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0387152500== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig60A748F66CFB270C55011486" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig60A748F66CFB270C55011486 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Murari Sridharan wrote: > In this context I wanted to bring up a related issue that might also strengthen this sort of a port randomization proposal. >=20 > Today the 64k port limitation is starting to become a huge problem > and > most often admins add ip addresses to increase the scalability. Given > that most often the destination port (and sometimes the destination > address) is well known, the only scalability left is the source address= =2E > Increasing ip addresses to improve scalability seems a fairly round > about approach and frankly doesn't scale well. Given that the 64k limit= > is not fundamental why not provide a scaling factor similar to the > receive window to scale the number of usable ports. This also makes > randomization much more meaningful because in certain proxy scenarios > the number of connections quickly exhausts the available ports and at > that point the attacker can simply use any port assuming he can guess > the source address. Scale works for windows because of two things: 1) the scale increases the granularity of the window info 2) the scale factor can be negotiated during SYN exchange Neither is true for ports. 1-p) ports are specific numbers; extended fields could be provided in options, but that's equivalent to having the port number itself in an option anyway 2-p) we can negotiate the use of these extended port ranges with endpoints, but it will break NATs Portnames is a step in these directions, but is currently experimental at best. See http://www.isi.edu/touch/pubs/draft-touch-tcp-portnames-00.txt (to be updated shortly). Joe --=20 ---------------------------------------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment Postel Center Director & Research Assoc. Prof., USC/ISI --------------enig60A748F66CFB270C55011486 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 iD8DBQFGqO64E5f5cImnZrsRAoCrAJ0UzQJFZPNm3s3bghkL5if/nK9uEgCgueg9 xyb0fVt33Nz2HWxHQ9uoBAY= =JPbR -----END PGP SIGNATURE----- --------------enig60A748F66CFB270C55011486-- --===============0387152500== 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 --===============0387152500==-- From tcpm-bounces@ietf.org Thu Jul 26 14:59:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE8Yw-0008M3-LC; Thu, 26 Jul 2007 14:59:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE8Yt-00086V-Lp; Thu, 26 Jul 2007 14:59:47 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IE8Ys-0006Rq-Ab; Thu, 26 Jul 2007 14:59:47 -0400 Received: from [130.129.37.253] (dhcp-25fd.ietf69.org [130.129.37.253]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l6QIxTJt004053; Thu, 26 Jul 2007 11:59:30 -0700 (PDT) Message-ID: <46A8EF0A.1040400@isi.edu> Date: Thu, 26 Jul 2007 11:59:22 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" Subject: Re: [Tsvwg] Re: [tcpm] Revision ofdraft-larsen-tsvwg-port-randomization References: <0C53DCFB700D144284A584F54711EC5803B6C62F@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC5803B6C62F@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.2 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: tcpm@ietf.org, tsvwg WG , DCCP mailing list , Fernando Gont , TSV Dir , ext@cisco.com, Murari Sridharan 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="===============1953143161==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1953143161== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig203C0F0FD98BF13F0706B39E" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig203C0F0FD98BF13F0706B39E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anantha Ramaiah (ananth) wrote: > Murari, =2E.. > - or do it in piecemeal, first buy more TCP option space, standardize > any one of the proposals for extending the TCP option space. Then have > an extended port option like yu suggest below. Then think about other > TCP fields requiring extension. The problem is that buying more option space is equivalent to requiring a whole new TCP header - it has the same problems with backward compatibility. Previous attempts explored this space, and I think this was Mark's motivation for a doubled-field TCP header. Joe --=20 ---------------------------------------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment Postel Center Director & Research Assoc. Prof., USC/ISI --------------enig203C0F0FD98BF13F0706B39E 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 iD8DBQFGqO8KE5f5cImnZrsRAmZtAJ9Bu9hfqG1vIYT1LZlPVmURnSI1cACg9Sl/ fDrPJ04LFu9zqIpxgZN8eJE= =w/YC -----END PGP SIGNATURE----- --------------enig203C0F0FD98BF13F0706B39E-- --===============1953143161== 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 --===============1953143161==-- From tcpm-bounces@ietf.org Thu Jul 26 15:14:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE8me-0002ci-T9; Thu, 26 Jul 2007 15:14:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE8mc-0002by-JO; Thu, 26 Jul 2007 15:13:58 -0400 Received: from mailc.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IE8mb-0006kD-AZ; Thu, 26 Jul 2007 15:13:58 -0400 Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.700.0; Thu, 26 Jul 2007 12:13:56 -0700 Received: from NA-EXMSG-C110.redmond.corp.microsoft.com ([157.54.62.150]) by tk1-exhub-c101.redmond.corp.microsoft.com ([157.56.116.111]) with mapi; Thu, 26 Jul 2007 12:13:54 -0700 From: Murari Sridharan To: Joe Touch Date: Thu, 26 Jul 2007 12:13:54 -0700 Subject: RE: [Tsvwg] Re: [tcpm] Revision of draft-larsen-tsvwg-port-randomization Thread-Topic: [Tsvwg] Re: [tcpm] Revision of draft-larsen-tsvwg-port-randomization Thread-Index: AcfPtvQxDsL76unxSIOdk+kp1iUnigAAP8TQ Message-ID: References: <200702111621.l1BGL6mw029875@venus.xmundo.net> <0E46EBE9-1C13-44B6-9C04-476D418F5A6D@nokia.com> <46A8EEB8.2000304@isi.edu> In-Reply-To: <46A8EEB8.2000304@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: -8.0 (--------) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: "tcpm@ietf.org" , tsvwg WG , list , Fernando Gont , TSV Dir , DCCP 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 Agree on the NAT part. However whether or not its negotiated during SYN exchange would depend on h= ow it gets specified. For instance (again I really am thinking real-time an= d aloud here not fully thought thru) we could do something like the followi= ng. On the SYN packet, the sender picks a port (unscaled)and tries to negot= iate a scaling option, (NATs that do packet inspection are free to strip th= is option out) and the destination picks a port and may respond to the scal= ing. If both sides agreed, then the scaled ports are used for the 4-tupe, i= f not the unscaled version is used. The only caveat is that while a connect= ion attempt is in progress to a destination, we cannot be trying the same l= ocal port, since till the 3-way handshake completes you wont know whether t= he scaled or the unscaled version is going to be used. I am not suggesting that scaling ports is a good option, just a thought. I = will look at the portnames draft. -----Original Message----- From: Joe Touch [mailto:touch@ISI.EDU] Sent: Thursday, July 26, 2007 11:58 AM To: Murari Sridharan Cc: tsvwg WG; tcpm@ietf.org; DCCP mailing list; Fernando Gont; TSV Dir Subject: Re: [Tsvwg] Re: [tcpm] Revision of draft-larsen-tsvwg-port-randomi= zation Murari Sridharan wrote: > In this context I wanted to bring up a related issue that might also strengthen this sort of a port randomization proposal. > > Today the 64k port limitation is starting to become a huge problem and > most often admins add ip addresses to increase the scalability. Given > that most often the destination port (and sometimes the destination > address) is well known, the only scalability left is the source address. > Increasing ip addresses to improve scalability seems a fairly round > about approach and frankly doesn't scale well. Given that the 64k > limit is not fundamental why not provide a scaling factor similar to > the receive window to scale the number of usable ports. This also > makes randomization much more meaningful because in certain proxy > scenarios the number of connections quickly exhausts the available > ports and at that point the attacker can simply use any port assuming > he can guess the source address. Scale works for windows because of two things: 1) the scale increases the granularity of the window info 2) the scale factor can be negotiated during SYN exchange Neither is true for ports. 1-p) ports are specific numbers; extended fields could be provided in optio= ns, but that's equivalent to having the port number itself in an option any= way 2-p) we can negotiate the use of these extended port ranges with endpoints,= but it will break NATs Portnames is a step in these directions, but is currently experimental at b= est. See http://www.isi.edu/touch/pubs/draft-touch-tcp-portnames-00.txt (to= be updated shortly). Joe -- ---------------------------------------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment Postel Center Director & Research Assoc. Prof., USC/ISI _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jul 26 15:17:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE8pZ-0004bw-8m; Thu, 26 Jul 2007 15:17:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE8pY-0004bq-6d for tcpm@ietf.org; Thu, 26 Jul 2007 15:17:00 -0400 Received: from mx1.grc.nasa.gov ([128.156.11.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IE8pW-0006nu-Q7 for tcpm@ietf.org; Thu, 26 Jul 2007 15:17:00 -0400 Received: from lombok-fi.grc.nasa.gov (seraph.grc.nasa.gov [128.156.10.10]) by mx1.grc.nasa.gov (Postfix) with ESMTP id EC642C3A0 for ; Thu, 26 Jul 2007 15:16:57 -0400 (EDT) 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 l6QJGvPD002313; Thu, 26 Jul 2007 15:16:57 -0400 (EDT) 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 l6QJGvGF012103; Thu, 26 Jul 2007 15:16:57 -0400 (EDT) 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 uo9lgV4QkJ3s; Thu, 26 Jul 2007 15:16:56 -0400 (EDT) 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 l6QJGsIT012088; Thu, 26 Jul 2007 15:16:54 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501) id E387E4FE6A; Thu, 26 Jul 2007 15:13:07 -0400 (EDT) Date: Thu, 26 Jul 2007 15:13:07 -0400 From: Wesley Eddy To: Joe Touch Subject: Re: [Tsvwg] Re: [tcpm]Revision ofdraft-larsen-tsvwg-port-randomization Message-ID: <20070726191307.GB9242@grc.nasa.gov> References: <0C53DCFB700D144284A584F54711EC5803B6C62F@xmb-sjc-21c.amer.cisco.com> <46A8EF0A.1040400@isi.edu> Mime-Version: 1.0 In-Reply-To: <46A8EF0A.1040400@isi.edu> User-Agent: Mutt/1.5.5.1i X-Spam-Score: -4.0 (----) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ext@cisco.com, Murari Sridharan , tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" 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: , Content-Type: multipart/mixed; boundary="===============1539450793==" Errors-To: tcpm-bounces@ietf.org --===============1539450793== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hHWLQfXTYDoKhP50" Content-Disposition: inline --hHWLQfXTYDoKhP50 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 26, 2007 at 11:59:22AM -0700, Joe Touch wrote: >=20 > The problem is that buying more option space is equivalent to requiring > a whole new TCP header - it has the same problems with backward > compatibility. Previous attempts explored this space, and I think this > was Mark's motivation for a doubled-field TCP header. >=20 If by "backwards compatibility", you mean falling back to the normal (small) amount of options space when the other side doesn't support jumbo-options, this can be acheived. Maybe you mean something else though. By the way, this expired nearly 2 years ago, but's still online for some reason ...: http://www.ietf.org/internet-drafts/draft-eddy-tcp-loo-03.txt --=20 Wesley M. Eddy Verizon Federal Network Systems --hHWLQfXTYDoKhP50 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGqPJDzBuYqbnj3IwRAlcvAJ9TFtjVke/T1vJkhv/3dgBflk6aewCfUQLK rF+gUU27Du0tYvAoqsHFZ6Y= =Usbk -----END PGP SIGNATURE----- --hHWLQfXTYDoKhP50-- --===============1539450793== 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 --===============1539450793==-- From tcpm-bounces@ietf.org Thu Jul 26 15:18:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE8rC-00088a-Sp; Thu, 26 Jul 2007 15:18:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE8rA-000879-HY; Thu, 26 Jul 2007 15:18:40 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IE8rA-0005gV-2r; Thu, 26 Jul 2007 15:18:40 -0400 Received: from [130.129.37.253] (dhcp-25fd.ietf69.org [130.129.37.253]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l6QJIQYF008992; Thu, 26 Jul 2007 12:18:26 -0700 (PDT) Message-ID: <46A8F37A.8070508@isi.edu> Date: Thu, 26 Jul 2007 12:18:18 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Murari Sridharan Subject: Re: [Tsvwg] Re: [tcpm] Revision of draft-larsen-tsvwg-port-randomization References: <200702111621.l1BGL6mw029875@venus.xmundo.net> <0E46EBE9-1C13-44B6-9C04-476D418F5A6D@nokia.com> <46A8EEB8.2000304@isi.edu> In-Reply-To: X-Enigmail-Version: 0.95.2 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: TSV Dir , "tcpm@ietf.org" , DCCP mailing list , tsvwg WG , 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: , Content-Type: multipart/mixed; boundary="===============1785978800==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1785978800== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA7FCCDE046A38DBE94473D1B" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA7FCCDE046A38DBE94473D1B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Murari Sridharan wrote: > Agree on the NAT part. >=20 > However whether or not its negotiated during SYN exchange would > depend > on how it gets specified. For instance (again I really am thinking > real-time and aloud here not fully thought thru) we could do something > like the following. On the SYN packet, the sender picks a port > (unscaled)and tries to negotiate a scaling option, (NATs that do packet= > inspection are free to strip this option out) and the destination picks= > a port and may respond to the scaling. If both sides agreed, then the > scaled ports are used for the 4-tupe, if not the unscaled version is > used. The only caveat is that while a connection attempt is in progress= > to a destination, we cannot be trying the same local port, since till > the 3-way handshake completes you wont know whether the scaled or the > unscaled version is going to be used. It can't get negotiated during the SYN; NATs wouldn't track that, and will break the connection if it 'moves' to another port. Even if it is in the SYN, it won't allow two hosts to share a port through a NAT. It's worth looking at the alternatives which are discussed in Mark's ID and mine, too. Joe --=20 ---------------------------------------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment Postel Center Director & Research Assoc. Prof., USC/ISI --------------enigA7FCCDE046A38DBE94473D1B 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 iD8DBQFGqPN7E5f5cImnZrsRAi9xAKCHR6WObc01W6PhM6VGPkXASx4BoQCg0wDt /kfsP+3lUkTHr2VBZihoHPg= =IMrz -----END PGP SIGNATURE----- --------------enigA7FCCDE046A38DBE94473D1B-- --===============1785978800== 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 --===============1785978800==-- From tcpm-bounces@ietf.org Thu Jul 26 15:27:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE8zc-0008FV-VC; Thu, 26 Jul 2007 15:27:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE8za-0008FD-Qb for tcpm@ietf.org; Thu, 26 Jul 2007 15:27:22 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IE8za-0005ws-Bs for tcpm@ietf.org; Thu, 26 Jul 2007 15:27:22 -0400 Received: from [130.129.37.253] (dhcp-25fd.ietf69.org [130.129.37.253]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l6QJRA7C011157; Thu, 26 Jul 2007 12:27:10 -0700 (PDT) Message-ID: <46A8F587.8060709@isi.edu> Date: Thu, 26 Jul 2007 12:27:03 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: weddy@grc.nasa.gov Subject: Re: [Tsvwg] Re: [tcpm]Revision ofdraft-larsen-tsvwg-port-randomization References: <0C53DCFB700D144284A584F54711EC5803B6C62F@xmb-sjc-21c.amer.cisco.com> <46A8EF0A.1040400@isi.edu> <20070726191307.GB9242@grc.nasa.gov> In-Reply-To: <20070726191307.GB9242@grc.nasa.gov> X-Enigmail-Version: 0.95.2 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: ext@cisco.com, Murari Sridharan , 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="===============0084037671==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0084037671== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7A081E8A70ADD99BB8A5C2B2" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7A081E8A70ADD99BB8A5C2B2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Wesley Eddy wrote: > On Thu, Jul 26, 2007 at 11:59:22AM -0700, Joe Touch wrote: >> The problem is that buying more option space is equivalent to requirin= g >> a whole new TCP header - it has the same problems with backward >> compatibility. Previous attempts explored this space, and I think this= >> was Mark's motivation for a doubled-field TCP header. >> >=20 >=20 > If by "backwards compatibility", you mean falling back to the normal > (small) amount of options space when the other side doesn't support > jumbo-options, this can be acheived. Maybe you mean something else > though. The place you really need the space is the SYN (in general, and for ports in particular); it's impossible to extend a packet with an option in the SYN because participation in those options has not been negotiated= =2E I don't agree that the SLO variant, described in the doc below, is useful in that regard. That would require NATs track the SLO option to parse the port. Joe > By the way, this expired nearly 2 years ago, but's still online for > some reason ...: > http://www.ietf.org/internet-drafts/draft-eddy-tcp-loo-03.txt >=20 --=20 ---------------------------------------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment Postel Center Director & Research Assoc. Prof., USC/ISI --------------enig7A081E8A70ADD99BB8A5C2B2 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 iD8DBQFGqPWHE5f5cImnZrsRAsReAJ43YM3dl78L7HX1gs7pr+EQPT/K7QCgszDs 8ZwSKWt8SMkCVZSiBj5zGnI= =8FB/ -----END PGP SIGNATURE----- --------------enig7A081E8A70ADD99BB8A5C2B2-- --===============0084037671== 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 --===============0084037671==-- From tcpm-bounces@ietf.org Thu Jul 26 15:30:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE92e-0005EK-U5; Thu, 26 Jul 2007 15:30:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE92c-0005Ct-I0; Thu, 26 Jul 2007 15:30:30 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IE92c-00061s-4d; Thu, 26 Jul 2007 15:30:30 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 26 Jul 2007 12:30:30 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CABiTqEarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,584,1175497200"; d="scan'208"; a="388472749:sNHT29476488" 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 l6QJUQqf003177; Thu, 26 Jul 2007 12:30:29 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6QJUL6E014948; Thu, 26 Jul 2007 19:30:25 GMT 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, 26 Jul 2007 12:30:22 -0700 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: [Tsvwg] Re: [tcpm] Revision ofdraft-larsen-tsvwg-port-randomization Date: Thu, 26 Jul 2007 12:30:21 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5803B6C80C@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <46A8EF0A.1040400@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Tsvwg] Re: [tcpm] Revision ofdraft-larsen-tsvwg-port-randomization Thread-Index: AcfPtx4aHH3a2racRCq9/ufURPV1EAAAHRcA From: "Anantha Ramaiah \(ananth\)" To: "Joe Touch" X-OriginalArrivalTime: 26 Jul 2007 19:30:22.0576 (UTC) FILETIME=[68B33F00:01C7CFBB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1505; t=1185478229; x=1186342229; 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[Tsvwg]=20Re=3A=20[tcpm]=20Revision=09ofdraft-larsen- tsvwg-port-randomization |Sender:=20; bh=0obXvOAr+C6z6dOaJp9TBgiJVgWCEUa5YavxVW5IymQ=; b=EXfJKeRkt4VcHWXiwVXQjCJcFnEC6gCPNVVgnAT7PAq+2F7bTGejdAC8nF53uLOMNdzGKRun aff42b6SYV8oDBD9p4NKjw4hdh93ExMu4784CzB6NqmqWZucctuuUo6T; 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: cab78e1e39c4b328567edb48482b6a69 Cc: tcpm@ietf.org, tsvwg WG , DCCP mailing list , Fernando Gont , TSV Dir , ext@cisco.com, Murari Sridharan 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 Lars had sent an email to retain focus on the port randomization and hence this is going to my last comment... Pl see inline.. =20 >=20 >=20 > Anantha Ramaiah (ananth) wrote: > > Murari, > ... > > - or do it in piecemeal, first buy more TCP option space,=20 > standardize=20 > > any one of the proposals for extending the TCP option=20 > space. Then have=20 > > an extended port option like yu suggest below. Then think=20 > about other=20 > > TCP fields requiring extension. >=20 > The problem is that buying more option space is equivalent to=20 > requiring a whole new TCP header - it has the same problems=20 > with backward compatibility. Previous attempts explored this=20 New TCP header =3D=3D "Mountain" , IMO this is equivalent to using SCTP = in some sense. TCP option space =3D=3D "Molehill" , this is a "minimal" change with = "some" backward compat issues which can be addressed. If I take your above para seriously, then you are in a way implying that there is no new TCP options possible :-( or in other words users of TCP would be rationed to use only a few options in the initial SYN exchange. -Anantha > space, and I think this was Mark's motivation for a=20 > doubled-field TCP header. >=20 > Joe >=20 > -- > ---------------------------------------------------------------------- > Joe Touch Sr. Network Engineer, USAF TSAT Space Segment > Postel Center Director & Research Assoc. Prof., USC/ISI >=20 >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jul 26 15:36:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE98c-0002Eh-K2; Thu, 26 Jul 2007 15:36:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE98a-0002DA-H8; Thu, 26 Jul 2007 15:36:40 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IE98a-0006DR-1W; Thu, 26 Jul 2007 15:36:40 -0400 Received: from [130.129.37.253] (dhcp-25fd.ietf69.org [130.129.37.253]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l6QJaJkw013673; Thu, 26 Jul 2007 12:36:19 -0700 (PDT) Message-ID: <46A8F7AC.5030807@isi.edu> Date: Thu, 26 Jul 2007 12:36:12 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <0C53DCFB700D144284A584F54711EC5803B6C80C@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC5803B6C80C@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.2 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: tcpm@ietf.org, tsvwg WG , DCCP mailing list , Fernando Gont , TSV Dir , Murari Sridharan Subject: [tcpm] discussion of TCP option space 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="===============1796381261==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1796381261== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB40FE59FF3E3FEDED7902CED" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB40FE59FF3E3FEDED7902CED Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable changing the thread as Lars suggested... Anantha Ramaiah (ananth) wrote: > Lars had sent an email to retain focus on the port randomization and > hence this is going to my last comment... Pl see inline.. > =20 >> >> Anantha Ramaiah (ananth) wrote: >>> Murari, >> ... >>> - or do it in piecemeal, first buy more TCP option space,=20 >> standardize=20 >>> any one of the proposals for extending the TCP option=20 >> space. Then have=20 >>> an extended port option like yu suggest below. Then think=20 >> about other=20 >>> TCP fields requiring extension. >> The problem is that buying more option space is equivalent to=20 >> requiring a whole new TCP header - it has the same problems=20 >> with backward compatibility. Previous attempts explored this=20 >=20 > New TCP header =3D=3D "Mountain" , IMO this is equivalent to using SCTP= in > some sense. >=20 > TCP option space =3D=3D "Molehill" , this is a "minimal" change with "s= ome" > backward compat issues which can be addressed. See my other post; it's impossible to extend TCP option space for SYNs, and SYNs are where they matter. > If I take your above para seriously, then you are in a way implying tha= t > there is no new TCP options possible :-( or in other words users of TCP= > would be rationed to use only a few options in the initial SYN exchange= =2E New options are possible, but only if they are OPTIONAL and we expect their use to be mutually exclusive with likely SYN options (SACK, timestamps) or other proposed options. Or we should start making progress to Mark's idea of just breaking things now. Joe --=20 ---------------------------------------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment Postel Center Director & Research Assoc. Prof., USC/ISI --------------enigB40FE59FF3E3FEDED7902CED 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 iD8DBQFGqPesE5f5cImnZrsRAs4KAKDCwXcYK24XS/Zcd6JuC6PIqRdJGgCfRRuO btwmijyobcA6XclS2XPAWbQ= =u06P -----END PGP SIGNATURE----- --------------enigB40FE59FF3E3FEDED7902CED-- --===============1796381261== 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 --===============1796381261==-- From tcpm-bounces@ietf.org Mon Jul 30 17:28:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFcmH-0003k1-9v; Mon, 30 Jul 2007 17:27:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFcmB-0003VA-Pc; Mon, 30 Jul 2007 17:27:39 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFcm9-0001kK-FQ; Mon, 30 Jul 2007 17:27:39 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 27D7CF0C46E; Mon, 30 Jul 2007 18:27:07 -0300 (ART) Received: from fgont.gont.com.ar (200.61.43.18.static.telmex.net.ar [200.61.43.18] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id l6ULQopg029773; Mon, 30 Jul 2007 18:27:00 -0300 Message-Id: <7.0.1.0.0.20070730030538.076fd2a8@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 30 Jul 2007 03:14:54 -0300 To: Murari Sridharan , tsvwg WG From: Fernando Gont Subject: RE: [Tsvwg] Re: [tcpm] Revision of draft-larsen-tsvwg-port-randomization In-Reply-To: References: <200702111621.l1BGL6mw029875@venus.xmundo.net> <0E46EBE9-1C13-44B6-9C04-476D418F5A6D@nokia.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]); Mon, 30 Jul 2007 18:27:06 -0300 (ART) X-Spam-Score: 1.8 (+) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: "tcpm@ietf.org" , DCCP mailing list , TSV Dir 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 11:42 26/07/2007, Murari Sridharan wrote: >In this context I wanted to bring up a related issue that might also >strengthen this sort of a port randomization proposal. > >Today the 64k port limitation is starting to become a huge problem >and most often admins add ip addresses to increase the scalability. >Given that most often the destination port (and sometimes the >destination address) is well known, the only scalability left is the >source address. Increasing ip addresses to improve scalability seems >a fairly round about approach and frankly doesn't scale well. Given >that the 64k limit is not fundamental why not provide a scaling >factor similar to the receive window to scale the number of usable >ports. This also makes randomization much more meaningful because in >certain proxy scenarios the number of connections quickly exhausts >the available ports and at that point the attacker can simply use >any port assuming he can guess the source address. While I may agree with increasing the range of port numbers, I think this is out of the scope of the port randomization draft we have authored. There are a few things that may be worth noting: * The port randomization approaches discussed in the port randomization draft are independent of the range of ephemeral ports. That is, even if at some point we decide to scale the port numbers (or whatever), the approaches discussed in the port randomization draft would still apply. * Most TCP implementations use for the ephemeral ports a very small subspace eg, ports 1024-4999) of the available port number space. That is, you may be using 1/10th of the range you have available. In this respect, our port randomization draft advises to increase the port number range used for ephemeral ports. This may help a bit in the scenarios you are describing. Kind 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 Mon Jul 30 21:06:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFgBT-00012f-Ht; Mon, 30 Jul 2007 21:05:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFgBQ-00012K-Jf; Mon, 30 Jul 2007 21:05:56 -0400 Received: from bosco.isi.edu ([128.9.168.207]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFgBP-00005k-9k; Mon, 30 Jul 2007 21:05:55 -0400 Received: by bosco.isi.edu (Postfix, from userid 70) id 964DBDAFD5; Mon, 30 Jul 2007 18:03:31 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20070731010331.964DBDAFD5@bosco.isi.edu> Date: Mon, 30 Jul 2007 18:03:31 -0700 (PDT) X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: tcpm@ietf.org, rfc-editor@rfc-editor.org Subject: [tcpm] RFC 4953 on Defending TCP Against Spoofing Attacks 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 Request for Comments is now available in online RFC libraries. RFC 4953 Title: Defending TCP Against Spoofing Attacks Author: J. Touch Status: Informational Date: July 2007 Mailbox: touch@isi.edu Pages: 28 Characters: 72756 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tcpm-tcp-antispoof-06.txt URL: http://www.rfc-editor.org/rfc/rfc4953.txt 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, and 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. This memo provides information for the Internet community. This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm