From tcpm-bounces@ietf.org Wed Feb 01 15:21:51 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4OUB-0003gE-8R; Wed, 01 Feb 2006 15:21:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4OU9-0003ck-El for tcpm@megatron.ietf.org; Wed, 01 Feb 2006 15:21:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02675 for ; Wed, 1 Feb 2006 15:20:12 -0500 (EST) Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4OfN-0004TV-AF for tcpm@ietf.org; Wed, 01 Feb 2006 15:33:26 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 01 Feb 2006 12:21:26 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.01,245,1136188800"; d="scan'208"; a="524991757:sNHT21482164" Received: from [172.25.42.162] ([172.25.42.162] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Feb 2006 15:21:30 -0500 Message-ID: <43E11848.10809@juniper.net> Date: Wed, 01 Feb 2006 15:21:28 -0500 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tcpm@ietf.org X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Feb 2006 20:21:30.0968 (UTC) FILETIME=[1689B580:01C6276D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Subject: [tcpm] draft-bonica-tcp-auth-04 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Folks, Please review the draft at the following URL: http://www.ietf.org/internet-drafts/draft-bonica-tcp-auth-04.txt An abstract follows: "This memo describes a TCP extension that enhances security for BGP, LDP and other TCP-based protocols. It is intended for applications where secure administrative access to both the end-points of the TCP connection is normally available. TCP peers can use this extension to authenticate messages passed between one another. The strategy described herein improves upon current practice, which is described in RFC 2385. Using this new strategy, TCP peers can update authentication keys during the lifetime of a TCP connection. TCP peers can also use stronger authentication algorithms to authenticate routing messages." Ron _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Feb 06 19:55:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6H8z-0003PV-ND; Mon, 06 Feb 2006 19:55:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6H8p-0003LO-Ry for tcpm@megatron.ietf.org; Mon, 06 Feb 2006 19:55:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00087 for ; Mon, 6 Feb 2006 19:53:45 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6HKx-0006MO-6W for tcpm@ietf.org; Mon, 06 Feb 2006 20:08:08 -0500 Received: from [128.89.80.73] (lion.bbn.com [128.89.80.73]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id k170spIB023702; Mon, 6 Feb 2006 19:54:51 -0500 (EST) Message-ID: <43E7EFDB.8030007@bbn.com> Date: Mon, 06 Feb 2006 19:54:51 -0500 From: "Armando L. Caro, Jr." User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050819) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Janardhan Iyengar Subject: Re: [tcpm] draft on congestion window limiting References: <20060111200955.E91D53A6584@lawyers.icir.org> <1138225861.16702.36.camel@viivi> In-Reply-To: X-Enigmail-Version: 0.92.0.0 OpenPGP: id=A9CE816E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: Ethan Blanton , Pasi Sarolahti , tcpm@ietf.org, Mark Allman 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Jana, I finally got around to reading this draft. I don't have much to add to the discussion. I agree that experimenting should be done. I wonder how much micro-bursts are a concern given that macro-bursts exist. Are micro-bursts just a little bit of noise in the bigger scheme of things, or do they really add up when you aggregate many TCP flows? I also have some comments below... Janardhan Iyengar wrote: > As far as the buggy receiver is concerned, I'm not sure that we should > aim to demonstrate trade-offs in such cases. But, IIUC, your core point > is that under the same conditions, a sender with burst-mitigation might > be at a disadvantage with respect to a sender without burst-mitigation. > There is also the possibility that a sender without burst-mitigation > loses packets in the network due to the burst when a sender with > burst-mitigation does not. So, I agree that there is a tradeoff. And > that we should write it out clearly. Well, this tradeoff is fairly obvious I think. You could include for completeness I suppose. I'm not too concerned about this topic, because we always face this tradeoff when dealing with correct congestion control. Correct congestion control almost always trades off a sender's throughput with the network's health. So, if sender's wanted to be greedy, they COULD avoid congestion control altogether. However, we don't see this as a default behavior in major operating systems. Nit picky comments... First sentence in Section 2: your missing the word "sender" after "TCP". Second paragraph in Section 3: I would end add another sentence to the end of the paragraph: "Also, CWV is unnecessary if CWL is used." Second paragraph in the first bullet of Section 3: I find this paragraph confusing. The sentence "An additional drawback..." seems out of place here. What's the other drawback? The beginning of the paragraph goes back and forth of whether two controls are good or not, so this sentence threw me off. Again, I think that experimenting should be done to determine whether micro-bursts are an issue or not. Unfortunately, I don't have suggestions of where to start. I'll need to think more on that topic... -- Armando _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Feb 07 15:36:33 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6ZZh-0008IX-Eb; Tue, 07 Feb 2006 15:36:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6ZZf-0008Dg-MC for tcpm@megatron.ietf.org; Tue, 07 Feb 2006 15:36:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27623 for ; Tue, 7 Feb 2006 15:34:49 -0500 (EST) Received: from mailer1.psc.edu ([128.182.58.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6Zm6-0006EI-3b for tcpm@ietf.org; Tue, 07 Feb 2006 15:49:24 -0500 Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by mailer1.psc.edu (8.13.4/8.13.3) with ESMTP id k17KaK54005068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Feb 2006 15:36:20 -0500 (EST) Received: from homer.psc.edu (homer.psc.edu [128.182.61.117]) by dexter.psc.edu (8.13.1/8.12.10) with ESMTP id k17KaKn3008281; Tue, 7 Feb 2006 15:36:20 -0500 FCC: imap://jheffner@dexter.psc.edu/mail/sent-mail X-Identity-Key: id1 X-Account-Key: account2 Date: Tue, 7 Feb 2006 15:36:17 -0500 From: John Heffner X-Mozilla-Draft-Info: internal/draft; vcard=0; receipt=0; uuencode=0 User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Janardhan Iyengar Subject: Re: [tcpm] draft on congestion window limiting References: <20060111200955.E91D53A6584@lawyers.icir.org> <1138225861.16702.36.camel@viivi> In-Reply-To: X-Length: 2307 X-UID: 754 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200602071536.17959.jheffner@psc.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: Ethan Blanton , Pasi Sarolahti , tcpm@ietf.org, Mark Allman 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Janardhan Iyengar wrote: > Pasi, > > Thank you for your comments, and for spending your time on this document. > >> I believe experimenting with burst mitigation algorithms in real >> networks could be possible for many of us. At least Linux has >> implemented a similar scheme for years, though I don't know what's the >> status of TCP in the latest kernel versions. > > > Thank you for this bit of information. The scheme mentioned in the paper > looks like the "Use it or Lose it" scheme mentioned in the draft. I did > probe the Linux community recently about whether a micro-burst > mitigation scheme was deployed in Linux. The response I got was that > there wasn't any such scheme currently deployed, but patches were > available. I am not sure at this time if there is or isn't a scheme in > Linux (I haven't looked at the code myself yet). I would be happy if > someone could confirm for me which one is currently the case. Linux does implement a somewhat similar scheme, with the primary differences being that it only applies the burst limit upon exit from a reorder/recovery state rather than on every ack, and it does not set ssthresh when reducing cwnd. This actually makes its behavior substantially different. One issue I see is if the delayed ack factor is greater than BLimit/MSS this breaks. Or for that matter, if there are persistent stretch-acks, say, from a cpu-bound receiver or reordering on the reverse path. Actually, I think persistent reordering on the forward path also causes problems. I'm wondering if setting BLimit to the initial window may be too conservative. If I have a 1000 segment window, most likely a burst of 5 segments isn't going to hurt too much. As for (dis)inscentives, some of this competing bursting/non-bursting senders issue is described in "Understanding the Performance of TCP Pacing" by Aggarwall, et. al. (http://www-cse.ucsd.edu/~savage/papers/Infocom2000pacing.pdf). Though this isn't pacing as they describe it, I think some of the issues are very similar. -John _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Feb 08 02:25:34 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6jhm-0003Xf-Nx; Wed, 08 Feb 2006 02:25:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6jhk-0003Pq-5k for tcpm@megatron.ietf.org; Wed, 08 Feb 2006 02:25:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23424 for ; Wed, 8 Feb 2006 02:23:43 -0500 (EST) Received: from fep01-0.kolumbus.fi ([193.229.0.41] helo=fep01-app.kolumbus.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6juA-00088n-6Q for tcpm@ietf.org; Wed, 08 Feb 2006 02:38:23 -0500 Received: from a84-230-92-128.elisa-laajakaista.fi ([84.230.92.128]) by fep01-app.kolumbus.fi with ESMTP id <20060208072512.VPSS15721.fep01-app.kolumbus.fi@a84-230-92-128.elisa-laajakaista.fi>; Wed, 8 Feb 2006 09:25:12 +0200 Subject: Re: [tcpm] draft on congestion window limiting From: Pasi Sarolahti To: "Armando L. Caro, Jr." In-Reply-To: <43E7EFDB.8030007@bbn.com> References: <20060111200955.E91D53A6584@lawyers.icir.org> <1138225861.16702.36.camel@viivi> <43E7EFDB.8030007@bbn.com> Date: Wed, 08 Feb 2006 09:25:00 +0200 Message-Id: <1139383500.6857.47.camel@viivi> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Ethan Blanton , tcpm@ietf.org, Janardhan Iyengar , Mark Allman 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="===============1902176596==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1902176596== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-pWu9s2DjScB0cTXN/Us3" --=-pWu9s2DjScB0cTXN/Us3 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2006-02-06 at 19:54 -0500, Armando L. Caro, Jr. wrote: > > As far as the buggy receiver is concerned, I'm not sure that we should > > aim to demonstrate trade-offs in such cases. But, IIUC, your core point > > is that under the same conditions, a sender with burst-mitigation might > > be at a disadvantage with respect to a sender without burst-mitigation. > > There is also the possibility that a sender without burst-mitigation > > loses packets in the network due to the burst when a sender with > > burst-mitigation does not. So, I agree that there is a tradeoff. And > > that we should write it out clearly. >=20 > Well, this tradeoff is fairly obvious I think. You could include for > completeness I suppose. I'm not too concerned about this topic, because > we always face this tradeoff when dealing with correct congestion > control. Correct congestion control almost always trades off a sender's > throughput with the network's health. So, if sender's wanted to be > greedy, they COULD avoid congestion control altogether. However, we > don't see this as a default behavior in major operating systems. Well, this is an experimental modification that makes TCP sender behaviour more conservative than "correct congestion control" by reducing cwnd after FlightSize drops suddenly. So it might be worthwhile to think about possible scenarios for a while, to figure out if there are cases (due to network behaviour, or due to behaviour of the other end) where this approach could be unnecessarily disadvantageous compared to the standard and "legal" TCP flows. Buggy receivers was not the best of examples, but I was looking for a possible case where FlightSize would be frequently reduced by more than BLimit for some reason, and thereby TCP sender would not be able to increase its cwnd in a normal way. Some nonconventional SACK flavor, or a buggy delayed ack implementation is obviously a problem that receiver itself should fix, but on the other hand, at the same time your neighbour might be able to deliver the data effectively just by following the standard congestion control rules. The other side of the trade-off is that it is unknown how harmful transient micro-bursts are, and whether they are better dealt with Active Queue Management, Rate-based pacing, or some other mechanism. - Pasi --=-pWu9s2DjScB0cTXN/Us3 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBD6ZzMoNa7NH1G2csRAsSuAKCk85nt6lpyHaJiCdwnb2ZQCBThlACg5Wa7 eQ/y+5+u5nf3VxX4Bm9ZRFU= =aLHd -----END PGP SIGNATURE----- --=-pWu9s2DjScB0cTXN/Us3-- --===============1902176596== 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 --===============1902176596==-- From tcpm-bounces@ietf.org Wed Feb 15 15:50:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9TbP-0000Mt-Ur; Wed, 15 Feb 2006 15:50:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9TbJ-0000Iz-R7; Wed, 15 Feb 2006 15:50:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00199; Wed, 15 Feb 2006 15:48:25 -0500 (EST) Received: from cypress.neustar.com ([209.173.57.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9TpM-00083K-UR; Wed, 15 Feb 2006 16:04:47 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k1FKo10e014521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Feb 2006 20:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1F9Tb7-0005lL-T9; Wed, 15 Feb 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 15 Feb 2006 15:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-tcp-dcr-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org 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 the Robustness of TCP to Non-Congestion Events Author(s) : S. Bhandarkar, et al. Filename : draft-ietf-tcpm-tcp-dcr-07.txt Pages : 18 Date : 2006-2-15 This document specifies Non-Congestion Robustness (NCR) for TCP. In the absence of explicit congestion notification from the network TCP uses loss as an indication of congestion. One of the ways TCP detects loss is using the arrival of three duplicate acknowledgments. However, this heuristic is not always correct, notably in the case when network paths reorder segments (for whatever reason), resulting in degraded performance. TCP-NCR is designed to mitigate this degraded performance by increasing the number of duplicate acknowledgments required to trigger loss recovery, based on the current state of the connection, in an effort to better disambiguate true segment loss from segment reordering. This document specifies the changes to TCP, as well as the costs and benefits of these modifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-dcr-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tcpm-tcp-dcr-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tcpm-tcp-dcr-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-2-15123710.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-tcp-dcr-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-dcr-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-15123710.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 Wed Feb 15 15:50:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9TbX-0000Ut-VO; Wed, 15 Feb 2006 15:50:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9TbK-0000Jh-OY; Wed, 15 Feb 2006 15:50:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00213; Wed, 15 Feb 2006 15:48:26 -0500 (EST) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9TpN-00083H-8r; Wed, 15 Feb 2006 16:04:48 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k1FKo1BX031061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Feb 2006 20:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1F9Tb7-0005lV-UQ; Wed, 15 Feb 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 15 Feb 2006 15:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-tcpsecure-04.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: , Sender: tcpm-bounces@ietf.org 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) : R. Stewart, M. Dalal Filename : draft-ietf-tcpm-tcpsecure-04.txt Pages : 27 Date : 2006-2-15 A recent study indicates that some types of TCP connections have an increased vulnerability to spoofed packet injection attacks than previously believed [SITW]. TCP has historically been considered protected against spoofed packet injection attacks by relying on the fact that it is difficult to guess the 4-tuple (the source and destination IP addresses and the source and destination ports) in combination with the 32 bit sequence number(s). A combination of increasing window sizes and applications using a longer term connections (e.g. H-323 or Border Gateway Protocol [RFC1771]) have left modern TCP implementation more vulnerable to these types of spoofed packet injection attacks. Note: Both [SITW] and [DTASA] provide charts which can give the reader an idea as to the time it takes to penetrate an unprotected system. 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 carefly crafting the sequence number of the spoofed segment to be in the current receive window. This can cause the connection to either abort or possibly cause data corruption. This document proposes small modifications to the way TCP handles inbound segments that can reduce the probability of such an attack. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-04.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-04.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-04.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: <2006-2-15124005.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-tcpsecure-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-tcpsecure-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-15124005.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 Wed Feb 15 17:26:14 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9V6E-0000ck-Pq; Wed, 15 Feb 2006 17:26:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9V6D-0000bE-4W for tcpm@megatron.ietf.org; Wed, 15 Feb 2006 17:26:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12510 for ; Wed, 15 Feb 2006 17:24:26 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9VKH-0004yO-IM for tcpm@ietf.org; Wed, 15 Feb 2006 17:40:48 -0500 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k1FMOks21516; Wed, 15 Feb 2006 14:24:46 -0800 (PST) Message-ID: <43F3AA2F.5070301@isi.edu> Date: Wed, 15 Feb 2006 14:24:47 -0800 From: Joe Touch User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tcpm@ietf.org Subject: Re: [tcpm] I-D ACTION:draft-ietf-tcpm-tcpsecure-04.txt References: In-Reply-To: X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Internet-Drafts@ietf.org wrote: > 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) : R. Stewart, M. Dalal > Filename : draft-ietf-tcpm-tcpsecure-04.txt > Pages : 27 > Date : 2006-2-15 Some of the document is incomplete; the ACKs section in particular is cutoff in mid-sentence. Also, the pointer to my ID is very old (it's been at -02 since Oct 2005), and the reference to Watson is incomplete (this was pointed out before). Any chance of posting a correction to these (the former might indicate other text problems throughout) very shortly? Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD86ovE5f5cImnZrsRAjvhAJwKQ6QyjKLv1fNsnt8i0QYjEoXixACePTh2 ycDg2MtvX9oIrUoMMfkDegQ= =XCBO -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Feb 16 09:51:51 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9kU3-0000j1-Ca; Thu, 16 Feb 2006 09:51:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9kU1-0000hZ-Gh for tcpm@megatron.ietf.org; Thu, 16 Feb 2006 09:51:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29546 for ; Thu, 16 Feb 2006 09:50:00 -0500 (EST) Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9kiF-0008Gh-PH for tcpm@ietf.org; Thu, 16 Feb 2006 10:06:32 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id k1GEpctp049841; Thu, 16 Feb 2006 06:51:43 -0800 (PST) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id BE6A077A6F5; Thu, 16 Feb 2006 09:51:37 -0500 (EST) To: "Duke, Martin" From: Mark Allman Subject: Re: [tcpm] RFC2581bis In-Reply-To: <8C7C41A176AC0B468BEFB2EFD9BDAB99CFB01F@XCH-NW-5V2.nw.nos.boeing.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Given to Fly MIME-Version: 1.0 Date: Thu, 16 Feb 2006 09:51:37 -0500 Message-Id: <20060216145137.BE6A077A6F5@guns.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: Ethan Blanton , tcpm@ietf.org, vern@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0992719615==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0992719615== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Folks- > I have concerns about setting ssthresh after multiple timeouts > (Equation 5). My initial feeling is that cutting ssthresh in half > each time is too conservative. > > [...] > > So as an alternative, perhaps we should leave ssthresh unchanged after > the first retransmit. Vern, Ethan and I have been chatting about this proposal. We're a little bit torn here because: * Our intent was to revise RFC 2581 for two reasons: (1) to roll in small changes to TCP that are already standards track (e.g., limited transmit and the larger initial window) and (2) to fix bugs identified in 2581. It seems to us that the above is outside the scope of either of these tasks. * It seems to the three of us that setting ssthresh on the first RTO and then not adjusting it on subsequent RTOs for the same sequence number is safe and may well be a reasonable path. So, how to reconcile these things? Do we really want to require Martin (or someone) to write a standards track RFC for something so small such that it can someday be rolled into the main spec? That seems like a pretty high price. So, we're asking the WG whether (a) the change seems reasonable and (b) whether it is OK to include this small tweak into the current revision of RFC2581. (Note: (b) is being asked about this small change only. We still think that (1) and (2) should be the guiding principles for the revision. Although, of course, the WG can decide otherwise, as well.) Thanks! allman -- Mark Allman -- ICIR/ICSI -- http://www.icir.org/mallman/ --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFD9JF5WyrrWs4yIs4RAtxYAJ4zCnEHNw7rLwxWTQie+iSag7ybQgCeJuFv QRJBJN0glbP3QvTYkaYFE2M= =3b6d -----END PGP SIGNATURE----- --=_bOundary-- --===============0992719615== 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 --===============0992719615==-- From tcpm-bounces@ietf.org Thu Feb 16 10:27:09 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9l2D-000852-KH; Thu, 16 Feb 2006 10:27:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9l28-00084j-Gr for tcpm@megatron.ietf.org; Thu, 16 Feb 2006 10:27:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03127 for ; Thu, 16 Feb 2006 10:25:15 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9lGJ-0001Pe-G7 for tcpm@ietf.org; Thu, 16 Feb 2006 10:41:48 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k1GFftIc011994 for ; Thu, 16 Feb 2006 08:41:55 -0700 (MST) Received: from zuk35exm63.ds.mot.com (zuk35exm63.ea.mot.com [10.178.1.42]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k1GFfbYH013307 for ; Thu, 16 Feb 2006 09:41:37 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] RFC2581bis Date: Thu, 16 Feb 2006 15:26:56 -0000 Message-ID: Thread-Topic: [tcpm] RFC2581bis Thread-Index: AcYzCNoprPYnEhs4QTCktXY5zlStSgAAYkvQ From: "Gil Jose-josegil1" To: , "Duke, Martin" X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Cc: Ethan Blanton , tcpm@ietf.org, vern@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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org A) I agree with Martin. It is too conservative and overkills the throughput of the connection, especially in mobile cellular systems with which I am more familiar and I can say that given the high RTT (and RTO!) the impact on throughput is quite dramatic. Do we need to be a bit more precise? For example, what about a timeout during the loss recovery phase? At the time of the fast retransmit ssthresh is set to half the value of cwnd. But if before the end of the loss recovery phase there is a timeout then ssthresh is halved again as I understand it from RFC 2581. My opinion is that this is also too conservative. B) My opinion is that such small change fits very appropriately into RFC 2581. Jose >Folks- > I have concerns about setting ssthresh after multiple timeouts > (Equation 5). My initial feeling is that cutting ssthresh in half > each time is too conservative. > > [...] >=20 > So as an alternative, perhaps we should leave ssthresh unchanged after > the first retransmit. Vern, Ethan and I have been chatting about this proposal. We're a little bit torn here because: * Our intent was to revise RFC 2581 for two reasons: (1) to roll in small changes to TCP that are already standards track (e.g., limited transmit and the larger initial window) and (2) to fix bugs identified in 2581. It seems to us that the above is outside the scope of either of these tasks. * It seems to the three of us that setting ssthresh on the first RTO and then not adjusting it on subsequent RTOs for the same sequence number is safe and may well be a reasonable path. So, how to reconcile these things? Do we really want to require Martin (or someone) to write a standards track RFC for something so small such that it can someday be rolled into the main spec? That seems like a pretty high price. So, we're asking the WG whether (a) the change seems reasonable and (b) whether it is OK to include this small tweak into the current revision of RFC2581. (Note: (b) is being asked about this small change only. We still think that (1) and (2) should be the guiding principles for the revision. Although, of course, the WG can decide otherwise, as well.) Thanks! allman=20 -----Original Message----- From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Mark Allman Sent: 16 February 2006 14:52 To: Duke, Martin Cc: Ethan Blanton; tcpm@ietf.org; vern@icir.org Subject: Re: [tcpm] RFC2581bis=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Feb 16 10:43:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9lIO-00069Q-9N; Thu, 16 Feb 2006 10:43:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9lIM-00069H-CA for tcpm@megatron.ietf.org; Thu, 16 Feb 2006 10:43:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04883 for ; Thu, 16 Feb 2006 10:42:02 -0500 (EST) Received: from viefep11-int.chello.at ([213.46.255.27] helo=viefep19-int.chello.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9lWX-00026o-77 for tcpm@ietf.org; Thu, 16 Feb 2006 10:58:33 -0500 Received: from fun ([213.47.204.236]) by viefep19-int.chello.at (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with SMTP id <20060216154332.WGAS29983.viefep19-int.chello.at@fun>; Thu, 16 Feb 2006 16:43:32 +0100 Message-ID: <000501c63310$179398c0$0200a8c0@fun> From: "Michael Welzl" To: "Gil Jose-josegil1" , , "Duke, Martin" References: Subject: Re: [tcpm] RFC2581bis Date: Thu, 16 Feb 2006 16:46:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit Cc: Ethan Blanton , tcpm@ietf.org, vern@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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Hi all, I have no opinion about A) (i.e. I'd rather leave this to people who have some operational experience with this matter), but agree about B) (fits in the 2581 update). Cheers, Michael ----- Original Message ----- From: "Gil Jose-josegil1" To: ; "Duke, Martin" Cc: "Ethan Blanton" ; ; Sent: Thursday, February 16, 2006 4:26 PM Subject: RE: [tcpm] RFC2581bis A) I agree with Martin. It is too conservative and overkills the throughput of the connection, especially in mobile cellular systems with which I am more familiar and I can say that given the high RTT (and RTO!) the impact on throughput is quite dramatic. Do we need to be a bit more precise? For example, what about a timeout during the loss recovery phase? At the time of the fast retransmit ssthresh is set to half the value of cwnd. But if before the end of the loss recovery phase there is a timeout then ssthresh is halved again as I understand it from RFC 2581. My opinion is that this is also too conservative. B) My opinion is that such small change fits very appropriately into RFC 2581. Jose >Folks- > I have concerns about setting ssthresh after multiple timeouts > (Equation 5). My initial feeling is that cutting ssthresh in half > each time is too conservative. > > [...] > > So as an alternative, perhaps we should leave ssthresh unchanged after > the first retransmit. Vern, Ethan and I have been chatting about this proposal. We're a little bit torn here because: * Our intent was to revise RFC 2581 for two reasons: (1) to roll in small changes to TCP that are already standards track (e.g., limited transmit and the larger initial window) and (2) to fix bugs identified in 2581. It seems to us that the above is outside the scope of either of these tasks. * It seems to the three of us that setting ssthresh on the first RTO and then not adjusting it on subsequent RTOs for the same sequence number is safe and may well be a reasonable path. So, how to reconcile these things? Do we really want to require Martin (or someone) to write a standards track RFC for something so small such that it can someday be rolled into the main spec? That seems like a pretty high price. So, we're asking the WG whether (a) the change seems reasonable and (b) whether it is OK to include this small tweak into the current revision of RFC2581. (Note: (b) is being asked about this small change only. We still think that (1) and (2) should be the guiding principles for the revision. Although, of course, the WG can decide otherwise, as well.) Thanks! allman -----Original Message----- From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Mark Allman Sent: 16 February 2006 14:52 To: Duke, Martin Cc: Ethan Blanton; tcpm@ietf.org; vern@icir.org Subject: Re: [tcpm] RFC2581bis _______________________________________________ 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 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Feb 16 12:04:06 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9mY2-00046O-2F; Thu, 16 Feb 2006 12:04:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9mY0-000463-FE for tcpm@megatron.ietf.org; Thu, 16 Feb 2006 12:04:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12214 for ; Thu, 16 Feb 2006 12:02:17 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9mmE-0005JO-Ra for tcpm@ietf.org; Thu, 16 Feb 2006 12:18:49 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 16 Feb 2006 09:03:53 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k1GH3qWL019712; Thu, 16 Feb 2006 09:03:52 -0800 (PST) Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Feb 2006 09:03:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] RFC2581bis Date: Thu, 16 Feb 2006 09:03:52 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC58012E6C54@xmb-sjc-21c.amer.cisco.com> Thread-Topic: [tcpm] RFC2581bis Thread-Index: AcYzCNaIfjLAFilrSPa2ZJooW+AnsAACfuhQ From: "Anantha Ramaiah \(ananth\)" To: , "Duke, Martin" X-OriginalArrivalTime: 16 Feb 2006 17:03:52.0766 (UTC) FILETIME=[F6B1EDE0:01C6331A] X-Spam-Score: 2.2 (++) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Cc: Ethan Blanton , tcpm@ietf.org, vern@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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Regarding a) regarding the larger initial window, I think it makes sense to have it with RFC 2581. Have no opinion on the limited transmit making its reference in RFC 2581. Also I would think it is probably ok to go with option b) ie update the existing 2581. Since the changes doesn't involve a major re-write, only some handfull of changes..(though important) -Anantha > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Mark Allman > Sent: Thursday, February 16, 2006 6:52 AM > To: Duke, Martin > Cc: Ethan Blanton; tcpm@ietf.org; vern@icir.org > Subject: Re: [tcpm] RFC2581bis=20 >=20 >=20 > Folks- >=20 > > I have concerns about setting ssthresh after multiple timeouts=20 > > (Equation 5). My initial feeling is that cutting ssthresh in half=20 > > each time is too conservative. > > > > [...] > >=20 > > So as an alternative, perhaps we should leave ssthresh=20 > unchanged after=20 > > the first retransmit. >=20 > Vern, Ethan and I have been chatting about this proposal. =20 > We're a little bit torn here because: >=20 > * Our intent was to revise RFC 2581 for two reasons: (1) to roll in > small changes to TCP that are already standards track=20 > (e.g., limited > transmit and the larger initial window) and (2) to fix bugs > identified in 2581. It seems to us that the above is outside the > scope of either of these tasks. >=20 > * It seems to the three of us that setting ssthresh on the first RTO > and then not adjusting it on subsequent RTOs for the same sequence > number is safe and may well be a reasonable path. >=20 > So, how to reconcile these things? Do we really want to=20 > require Martin (or someone) to write a standards track RFC=20 > for something so small such that it can someday be rolled=20 > into the main spec? That seems like a pretty high price. >=20 > So, we're asking the WG whether (a) the change seems=20 > reasonable and (b) whether it is OK to include this small=20 > tweak into the current revision of RFC2581. >=20 > (Note: (b) is being asked about this small change only. We=20 > still think that (1) and (2) should be the guiding principles=20 > for the revision. > Although, of course, the WG can decide otherwise, as well.) >=20 > Thanks! >=20 > allman >=20 >=20 >=20 > -- > Mark Allman -- ICIR/ICSI -- http://www.icir.org/mallman/ >=20 >=20 >=20 >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Feb 16 14:23:23 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9oip-0006AD-8X; Thu, 16 Feb 2006 14:23:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9oil-00067v-Uz for tcpm@megatron.ietf.org; Thu, 16 Feb 2006 14:23:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24192 for ; Thu, 16 Feb 2006 14:21:32 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9ox3-0001vc-7G for tcpm@ietf.org; Thu, 16 Feb 2006 14:38:05 -0500 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k1GJLms20231; Thu, 16 Feb 2006 11:21:48 -0800 (PST) Message-ID: <43F4D0CE.7060500@isi.edu> Date: Thu, 16 Feb 2006 11:21:50 -0800 From: Joe Touch User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mallman@icir.org Subject: Re: [tcpm] RFC2581bis References: <20060216145137.BE6A077A6F5@guns.icir.org> In-Reply-To: <20060216145137.BE6A077A6F5@guns.icir.org> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Cc: Ethan Blanton , tcpm@ietf.org, vern@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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I agree with Mark: - the modification needed is beyond the scope of 2581bis The change should be documented as either proposed standard or experimental (the latter justified since it's out in the wild anyway), at which point 2581bis could cite it, but coupling these two documents (one in-hand, one not even drafted yet) would stall 2581bis far too long. There will always be mods to TCP that occur after any particular document revision; let's not hold one up over the other. Joe Mark Allman wrote: > Folks- > > >>I have concerns about setting ssthresh after multiple timeouts >>(Equation 5). My initial feeling is that cutting ssthresh in half >>each time is too conservative. >> >>[...] >> >>So as an alternative, perhaps we should leave ssthresh unchanged after >>the first retransmit. > > > Vern, Ethan and I have been chatting about this proposal. We're a > little bit torn here because: > > * Our intent was to revise RFC 2581 for two reasons: (1) to roll in > small changes to TCP that are already standards track (e.g., limited > transmit and the larger initial window) and (2) to fix bugs > identified in 2581. It seems to us that the above is outside the > scope of either of these tasks. > > * It seems to the three of us that setting ssthresh on the first RTO > and then not adjusting it on subsequent RTOs for the same sequence > number is safe and may well be a reasonable path. > > So, how to reconcile these things? Do we really want to require Martin > (or someone) to write a standards track RFC for something so small such > that it can someday be rolled into the main spec? That seems like a > pretty high price. > > So, we're asking the WG whether (a) the change seems reasonable and (b) > whether it is OK to include this small tweak into the current revision > of RFC2581. > > (Note: (b) is being asked about this small change only. We still think > that (1) and (2) should be the guiding principles for the revision. > Although, of course, the WG can decide otherwise, as well.) > > Thanks! > > allman > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD9NDNE5f5cImnZrsRAklwAKCKUIULpKYewPUrcvAZXwWW3LBlrQCgp6O1 1wiIp8GA/tBd96U+dl6Y7Go= =8FgN -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Feb 16 16:01:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9qG8-0005dK-Pq; Thu, 16 Feb 2006 16:01:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9qG7-0005bv-0n for tcpm@megatron.ietf.org; Thu, 16 Feb 2006 16:01:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06368 for ; Thu, 16 Feb 2006 16:00:02 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9qUK-0001M1-TY for tcpm@ietf.org; Thu, 16 Feb 2006 16:16:37 -0500 Received: from [128.89.80.73] (lion.bbn.com [128.89.80.73]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id k1GL1MIB007274; Thu, 16 Feb 2006 16:01:23 -0500 (EST) Message-ID: <43F4E822.2070403@bbn.com> Date: Thu, 16 Feb 2006 16:01:22 -0500 From: "Armando L. Caro, Jr." User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050819) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Touch Subject: Re: [tcpm] RFC2581bis References: <20060216145137.BE6A077A6F5@guns.icir.org> <43F4D0CE.7060500@isi.edu> In-Reply-To: <43F4D0CE.7060500@isi.edu> X-Enigmail-Version: 0.92.0.0 OpenPGP: id=A9CE816E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: Ethan Blanton , tcpm@ietf.org, vern@icir.org, 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org I agree with Joe. Not only would this change stall the 2581bis, but it would create a precedent that we might regret later. New ideas, regardless of how small they may seem, should follow the normal course of events. There will most likely be a 2581bis-bis later on down the road. -- Armando www.armandocaro.net Joe Touch wrote: > I agree with Mark: > > - the modification needed is beyond the scope of 2581bis > > The change should be documented as either proposed standard or > experimental (the latter justified since it's out in the wild anyway), > at which point 2581bis could cite it, but coupling these two documents > (one in-hand, one not even drafted yet) would stall 2581bis far too long. > > There will always be mods to TCP that occur after any particular > document revision; let's not hold one up over the other. > > Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Feb 16 16:19:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9qXI-0006Fh-8R; Thu, 16 Feb 2006 16:19:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9qXG-0006Eh-S9 for tcpm@megatron.ietf.org; Thu, 16 Feb 2006 16:19:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10862 for ; Thu, 16 Feb 2006 16:17:46 -0500 (EST) Received: from frantic-dmz.weston.borman.com ([206.196.54.22] helo=frantic.weston.borman.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9qlU-0003TY-LC for tcpm@ietf.org; Thu, 16 Feb 2006 16:34:21 -0500 Received: from [127.0.0.1] (frantic.weston.borman.com [206.196.45.33]) by frantic.weston.borman.com (8.12.5/8.12.5) with ESMTP id k1GLF9Nq020302; Thu, 16 Feb 2006 15:15:09 -0600 (CST) In-Reply-To: <20060216145137.BE6A077A6F5@guns.icir.org> References: <20060216145137.BE6A077A6F5@guns.icir.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <57E07B3A-00BE-4E98-B8C8-A525918C809E@weston.borman.com> Content-Transfer-Encoding: 7bit From: David Borman Subject: Re: [tcpm] RFC2581bis Date: Thu, 16 Feb 2006 15:19:04 -0600 To: mallman@icir.org X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Cc: Ethan Blanton , tcpm@ietf.org, vern@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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org How about adding it as an appendix or a discussion item? That would document the issue and the proposed solution, but defer making it part of the standard. -David Borman On Feb 16, 2006, at 8:51 AM, Mark Allman wrote: > > Folks- > >> I have concerns about setting ssthresh after multiple timeouts >> (Equation 5). My initial feeling is that cutting ssthresh in half >> each time is too conservative. >> >> [...] >> >> So as an alternative, perhaps we should leave ssthresh unchanged >> after >> the first retransmit. > > Vern, Ethan and I have been chatting about this proposal. We're a > little bit torn here because: > > * Our intent was to revise RFC 2581 for two reasons: (1) to roll in > small changes to TCP that are already standards track (e.g., > limited > transmit and the larger initial window) and (2) to fix bugs > identified in 2581. It seems to us that the above is outside the > scope of either of these tasks. > > * It seems to the three of us that setting ssthresh on the first RTO > and then not adjusting it on subsequent RTOs for the same sequence > number is safe and may well be a reasonable path. > > So, how to reconcile these things? Do we really want to require > Martin > (or someone) to write a standards track RFC for something so small > such > that it can someday be rolled into the main spec? That seems like a > pretty high price. > > So, we're asking the WG whether (a) the change seems reasonable and > (b) > whether it is OK to include this small tweak into the current revision > of RFC2581. > > (Note: (b) is being asked about this small change only. We still > think > that (1) and (2) should be the guiding principles for the revision. > Although, of course, the WG can decide otherwise, as well.) > > Thanks! > > allman > > > > -- > Mark Allman -- ICIR/ICSI -- http://www.icir.org/mallman/ > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Feb 16 16:28:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9qft-0006Gp-U6; Thu, 16 Feb 2006 16:28:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9qfs-0006Fc-LH for tcpm@megatron.ietf.org; Thu, 16 Feb 2006 16:28:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11961 for ; Thu, 16 Feb 2006 16:26:40 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9quA-00048U-Ti for tcpm@ietf.org; Thu, 16 Feb 2006 16:43:15 -0500 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k1GLQfs06196; Thu, 16 Feb 2006 13:26:41 -0800 (PST) Message-ID: <43F4EE13.1020806@isi.edu> Date: Thu, 16 Feb 2006 13:26:43 -0800 From: Joe Touch User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Borman Subject: Re: [tcpm] RFC2581bis References: <20060216145137.BE6A077A6F5@guns.icir.org> <57E07B3A-00BE-4E98-B8C8-A525918C809E@weston.borman.com> In-Reply-To: <57E07B3A-00BE-4E98-B8C8-A525918C809E@weston.borman.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7bit Cc: Ethan Blanton , tcpm@ietf.org, vern@icir.org, 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Borman wrote: > How about adding it as an appendix or a discussion item? That would > document the issue and the proposed solution, but defer making it part > of the standard. > > -David Borman It could/should be listed as an open issue, under "pending mods that are not covered by this document". (I'd avoid an appendix devoted to this issue; IMO, the issue should be covered elsewhere in detail, not in this doc). Joe > > On Feb 16, 2006, at 8:51 AM, Mark Allman wrote: > >> >> Folks- >> >>> I have concerns about setting ssthresh after multiple timeouts >>> (Equation 5). My initial feeling is that cutting ssthresh in half >>> each time is too conservative. >>> >>> [...] >>> >>> So as an alternative, perhaps we should leave ssthresh unchanged after >>> the first retransmit. >> >> >> Vern, Ethan and I have been chatting about this proposal. We're a >> little bit torn here because: >> >> * Our intent was to revise RFC 2581 for two reasons: (1) to roll in >> small changes to TCP that are already standards track (e.g., limited >> transmit and the larger initial window) and (2) to fix bugs >> identified in 2581. It seems to us that the above is outside the >> scope of either of these tasks. >> >> * It seems to the three of us that setting ssthresh on the first RTO >> and then not adjusting it on subsequent RTOs for the same sequence >> number is safe and may well be a reasonable path. >> >> So, how to reconcile these things? Do we really want to require Martin >> (or someone) to write a standards track RFC for something so small such >> that it can someday be rolled into the main spec? That seems like a >> pretty high price. >> >> So, we're asking the WG whether (a) the change seems reasonable and (b) >> whether it is OK to include this small tweak into the current revision >> of RFC2581. >> >> (Note: (b) is being asked about this small change only. We still think >> that (1) and (2) should be the guiding principles for the revision. >> Although, of course, the WG can decide otherwise, as well.) >> >> Thanks! >> >> allman >> >> >> >> -- >> Mark Allman -- ICIR/ICSI -- http://www.icir.org/mallman/ >> >> >> >> _______________________________________________ >> 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD9O4TE5f5cImnZrsRApLxAKCLvkR3yLA6Qhwu6xxuj91bVr5mPwCfRZ/A dz+dkeJ/o3ecDjyZ/mZn4SA= =l0Bz -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Feb 17 11:09:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA8Ax-0007mu-16; Fri, 17 Feb 2006 11:09:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA8Av-0007mm-A6 for tcpm@megatron.ietf.org; Fri, 17 Feb 2006 11:09:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05127 for ; Fri, 17 Feb 2006 11:07:52 -0500 (EST) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FA8PI-0002OP-UL for tcpm@ietf.org; Fri, 17 Feb 2006 11:24:37 -0500 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA27426; Fri, 17 Feb 2006 10:09:06 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k1HG95N14169; Fri, 17 Feb 2006 10:09:05 -0600 (CST) Received: from XCH-NW-5V2.nw.nos.boeing.com ([130.247.55.45]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Feb 2006 08:08:59 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] RFC2581bis Date: Fri, 17 Feb 2006 08:08:58 -0800 Message-ID: <8C7C41A176AC0B468BEFB2EFD9BDAB99CFB071@XCH-NW-5V2.nw.nos.boeing.com> Thread-Topic: [tcpm] RFC2581bis Thread-Index: AcYzRFmMB7cGxVOySLC484ukCYW4VgAlsLJA From: "Duke, Martin" To: "Joe Touch" , "David Borman" X-OriginalArrivalTime: 17 Feb 2006 16:08:59.0281 (UTC) FILETIME=[7609C010:01C633DC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Content-Transfer-Encoding: quoted-printable Cc: Ethan Blanton , tcpm@ietf.org, vern@icir.org, 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org I'm not sure I agree that this is outside the scope of the task at hand, largely because I don't think that this is a change in what 2581 specifies.=20 I believe that the current specification can be interpreted two ways, and in fact, Linux and BSD interpret them differently. If we're going to clarify the intent, as the last draft of 2581bis seems to do, I think we should clarify it in the way that best prepares TCP to function in the future with minimum modification. Excerpt from the text of both documents is below. Martin (1) Original 2581 text: "When a TCP sender detects segment loss using the retransmission timer, the value of ssthresh MUST be set to no more than the value given in equation 3: ssthresh =3D max (FlightSize / 2, 2*SMSS) (3) As discussed above, FlightSize is the amount of outstanding data in the network. Implementation Note: an easy mistake to make is to simply use cwnd, rather than FlightSize, which in some implementations may incidentally increase well beyond rwnd." Flightsize is described as: "FLIGHT SIZE: The amount of data that has been sent but not yet acknowledged." But does that include data that has timed out? (2) 2581bis adds the following explanatory text: "On the other hand, when a TCP sender detects segment loss using the retransmission timer and the given segment has already been retransmitted at least once, the value of ssthresh MUST be set to no more than the value given in equation 5: ssthresh =3D max (ssthresh / 2, 2*SMSS) (5) In other words, upon the first retransmission of a segment the value of ssthresh should be set to half the amount of outstanding data in the network, whereas on subsequent retransmissions the value of ssthresh should simply be halved." -----Original Message----- From: Joe Touch [mailto:touch@ISI.EDU]=20 Sent: Thursday, February 16, 2006 1:27 PM To: David Borman Cc: Ethan Blanton; tcpm@ietf.org; vern@icir.org; mallman@icir.org Subject: Re: [tcpm] RFC2581bis -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Borman wrote: > How about adding it as an appendix or a discussion item? That would=20 > document the issue and the proposed solution, but defer making it =20 > part of the standard. >=20 > -David Borman It could/should be listed as an open issue, under "pending mods that are not covered by this document". (I'd avoid an appendix devoted to this issue; IMO, the issue should be covered elsewhere in detail, not in this doc). Joe >=20 > On Feb 16, 2006, at 8:51 AM, Mark Allman wrote: >=20 >> >> Folks- >> >>> I have concerns about setting ssthresh after multiple timeouts=20 >>> (Equation 5). My initial feeling is that cutting ssthresh in half=20 >>> each time is too conservative. >>> >>> [...] >>> >>> So as an alternative, perhaps we should leave ssthresh unchanged =20 >>> after the first retransmit. >> >> >> Vern, Ethan and I have been chatting about this proposal. We're a=20 >> little bit torn here because: >> >> * Our intent was to revise RFC 2581 for two reasons: (1) to roll in >> small changes to TCP that are already standards track (e.g., limited >> transmit and the larger initial window) and (2) to fix bugs >> identified in 2581. It seems to us that the above is outside the >> scope of either of these tasks. >> >> * It seems to the three of us that setting ssthresh on the first RTO >> and then not adjusting it on subsequent RTOs for the same sequence >> number is safe and may well be a reasonable path. >> >> So, how to reconcile these things? Do we really want to require =20 >> Martin (or someone) to write a standards track RFC for something so=20 >> small such that it can someday be rolled into the main spec? That=20 >> seems like a pretty high price. >> >> So, we're asking the WG whether (a) the change seems reasonable and =20 >> (b) whether it is OK to include this small tweak into the current=20 >> revision of RFC2581. >> >> (Note: (b) is being asked about this small change only. We still =20 >> think that (1) and (2) should be the guiding principles for the revision. >> Although, of course, the WG can decide otherwise, as well.) >> >> Thanks! >> >> allman >> >> >> >> -- >> Mark Allman -- ICIR/ICSI -- http://www.icir.org/mallman/ >> >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www1.ietf.org/mailman/listinfo/tcpm >=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD9O4TE5f5cImnZrsRApLxAKCLvkR3yLA6Qhwu6xxuj91bVr5mPwCfRZ/A dz+dkeJ/o3ecDjyZ/mZn4SA=3D =3Dl0Bz -----END PGP SIGNATURE----- _______________________________________________ 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 Fri Feb 17 11:38:39 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA8cw-0007Vc-Vp; Fri, 17 Feb 2006 11:38:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA8cv-0007VQ-Mf for tcpm@megatron.ietf.org; Fri, 17 Feb 2006 11:38:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08233 for ; Fri, 17 Feb 2006 11:36:48 -0500 (EST) Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FA8rI-0003lE-3p for tcpm@ietf.org; Fri, 17 Feb 2006 11:53:34 -0500 Received: from [128.9.176.73] ([128.9.176.73]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k1HGbYq17448; Fri, 17 Feb 2006 08:37:34 -0800 (PST) Message-ID: <43F5FBC9.7090004@isi.edu> Date: Fri, 17 Feb 2006 08:37:29 -0800 From: Joe Touch User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Duke, Martin" Subject: Re: [tcpm] RFC2581bis References: <8C7C41A176AC0B468BEFB2EFD9BDAB99CFB071@XCH-NW-5V2.nw.nos.boeing.com> In-Reply-To: <8C7C41A176AC0B468BEFB2EFD9BDAB99CFB071@XCH-NW-5V2.nw.nos.boeing.com> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: David Borman , tcpm@ietf.org, mallman@icir.org, Ethan Blanton , vern@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="===============0935284607==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0935284607== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig88F7D76424DE2E75E8EC39F1" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig88F7D76424DE2E75E8EC39F1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Duke, Martin wrote: > I'm not sure I agree that this is outside the scope of the task at hand= , > largely because I don't think that this is a change in what 2581 > specifies.=20 >=20 > I believe that the current specification can be interpreted two ways, > and in fact, Linux and BSD interpret them differently. If we're going > to clarify the intent, as the last draft of 2581bis seems to do, I thin= k > we should clarify it in the way that best prepares TCP to function in > the future with minimum modification. >=20 > Excerpt from the text of both documents is below. >=20 > Martin >=20 > (1) Original 2581 text: > "When a TCP sender detects segment loss using the retransmission > timer, the value of ssthresh MUST be set to no more than the value > given in equation 3: >=20 > ssthresh =3D max (FlightSize / 2, 2*SMSS) (3) >=20 > As discussed above, FlightSize is the amount of outstanding data in > the network. >=20 > Implementation Note: an easy mistake to make is to simply use cwnd, > rather than FlightSize, which in some implementations may > incidentally increase well beyond rwnd." >=20 > Flightsize is described as: > "FLIGHT SIZE: The amount of data that has been sent but not yet > acknowledged." > But does that include data that has timed out? Send but timed out is still sent. You can't 'unsend' it. It can still get there - and sometimes does. Trying to reinterpret that recommendation to accommodate what *might* happen in *some* contexts is speculation. Joe --------------enig88F7D76424DE2E75E8EC39F1 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.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD9fvJE5f5cImnZrsRAkcqAJ4w9/YCh6QaUWhKsccyOzykcQCxkQCg11/g A1DcPh2bUquVPuzvds+beV4= =AWEF -----END PGP SIGNATURE----- --------------enig88F7D76424DE2E75E8EC39F1-- --===============0935284607== 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 --===============0935284607==-- From tcpm-bounces@ietf.org Fri Feb 17 12:03:39 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA919-0006L5-KC; Fri, 17 Feb 2006 12:03:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA917-0006Kq-LS for tcpm@megatron.ietf.org; Fri, 17 Feb 2006 12:03:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10532 for ; Fri, 17 Feb 2006 12:01:48 -0500 (EST) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FA9FY-0004rZ-Ea for tcpm@ietf.org; Fri, 17 Feb 2006 12:18:35 -0500 Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id JAA06000; Fri, 17 Feb 2006 09:03:17 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k1HH3GN01389; Fri, 17 Feb 2006 11:03:16 -0600 (CST) Received: from XCH-NW-5V2.nw.nos.boeing.com ([130.247.55.45]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Feb 2006 09:03:15 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] RFC2581bis Date: Fri, 17 Feb 2006 09:03:14 -0800 Message-ID: <8C7C41A176AC0B468BEFB2EFD9BDAB99CFB073@XCH-NW-5V2.nw.nos.boeing.com> Thread-Topic: [tcpm] RFC2581bis Thread-Index: AcYz4mfdoZ4m+QinRZmG0Q0e4tNSHQAATXhw From: "Duke, Martin" To: "Joe Touch" X-OriginalArrivalTime: 17 Feb 2006 17:03:15.0534 (UTC) FILETIME=[0AEA86E0:01C633E4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Cc: David Borman , tcpm@ietf.org, mallman@icir.org, Ethan Blanton , vern@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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Exactly. I interpret the definition of FlightSize the same way. If FlightSize does not decrease with consecutive retransmission timeouts, then ssthresh will only be halved after the first consecutive timeout. That's the behavior that I advocate, which is NOT the behavior in 2581bis.=20 Martin > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU]=20 > Sent: Friday, February 17, 2006 8:37 AM > To: Duke, Martin Duke, Martin wrote: > >=20 > > ssthresh =3D max (FlightSize / 2, 2*SMSS) (3) > >=20 > > As discussed above, FlightSize is the amount of=20 > > outstanding data in the network. > > Flightsize is described as: > > "FLIGHT SIZE: The amount of data that has been sent but not yet > > acknowledged." > > But does that include data that has timed out? >=20 > Send but timed out is still sent. You can't 'unsend' it. It=20 > can still get there - and sometimes does. >=20 > Trying to reinterpret that recommendation to accommodate what=20 > *might* happen in *some* contexts is speculation. >=20 > Joe >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Feb 18 16:45:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAZtO-0003fb-9I; Sat, 18 Feb 2006 16:45:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAZtM-0003fW-R3 for tcpm@ietf.org; Sat, 18 Feb 2006 16:45:24 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAZtM-0008IO-AB for tcpm@ietf.org; Sat, 18 Feb 2006 16:45:24 -0500 Received: from [192.168.1.47] (pool-71-106-130-244.lsanca.dsl-w.verizon.net [71.106.130.244]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k1ILiaq25833; Sat, 18 Feb 2006 13:44:36 -0800 (PST) Message-ID: <43F7953F.6060106@isi.edu> Date: Sat, 18 Feb 2006 13:44:31 -0800 From: Joe Touch User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Pekka Savola Subject: Re: [tcpm] comments on draft-ietf-tcpm-tcp-antispoof-02 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Hi, all, Sorry for the long delay; I had been incorporating Ted's extensive comments, and had not noted how these were handled yet. An update (03) has been submitted with those and the following mods addressed as noted below: Pekka Savola wrote: > My comments below. There are still some things to fix, but most of the > below should be straightforward. > > substantial > ----------- > > 1) the receiver buffer sizing assumption does not seem realistic in > sufficiently many cases so that I think it should not be made. ... > I just checked; Cisco has by default around 4 KB for BGP (for others, > 32KB), > and it isn't even possible to config it up to more than 128K. Juniper > has by default 16KB, and AFAICS there is no way to configure it. > > .... Maybe what needs to be done > is calculate two tables: one where the buffers are adjusted so that the > bandwidth can be used in a maximum manner and where the buffers are capped > at (say) 16, 32 or 64 kB. That would give realistic calculations in > either case without having to > make assumptions about the buffers. Done. > (This same is in the first sentence of section 3.1.5.) > > 2) I think the address filtering (section 3.2.1) is still a bit lacking. Updated. > b) TTL checking problem with tunnels is still inaccurate. Updated. > c) At the beginning of section 3.2, you say "filtering is an indirect > system which relies on other parties to filter packets ..." which is > correct in the general case but not when examining the sessions inside a > border (where you can _yourself_ do the filtering, without relying on > anyone > else). This distinction is important depending on what kind of sessions > you're interested in protecting and how large area your borders cover. The text has been updated to clarify its original intent. I disagree that "you can _yourself_ do the filting, without relying on anyone else", except in trivial multiconnected stub network cases. > 3) the processing complexity comparison between transport vs network > solutions seems assumptive. The section where this is mentioned talks about the processing comparison of network and transport authentication; both are forms of authentication with similar computational complexity. That's why this section focuses on the other issues, such as demultiplexing and storage. > 4) network layer solution may not be able to cope with on-path ICMP. Section 4 was updated to clarify this point. > 5) BTNS applicability is slightly too simplistic > > Alternative mechanisms are under development to address this > limitation, to allow publicly-accessible servers to secure > connections to clients not known in advance, or to allow unilateral > relaxation of identity validation so that the remaining protections > of IPsec to be available [38][39]. In particular, these mechanisms > can prevent a client (but without knowing who that client is) from > being affected by spoofing from other clients, even when the > attackers are on the communications path. > > ==> AFAICS, "are on the communications path" is assumptive or simplistic. > Either you must > have a previously established relation (which you know is MITM-free) to > a peer, or you meant something like "would later, after establishing > the session, get on the communications path". After all, BTNS does not > protect from MITM if the MITM was there when the session was set up and > you don't have prior knowledge of the peer. The text above says "without knowing who the client is". It isn't meaningful to talk about MITM in those cases - the MITM is the client at that point. IMO, the text already has the sufficient caveat, and sufficiently explains the protection provided. > 6) The description why IPsec is not used to protect router-to-router > communications fails to address the added IPsec processing requirements, > which are typically prohibitive. Updated earlier in sec 5.2 as to computational complexity. > IPsec, although widely available both in commercial routers and > commodity end-systems, is not often utilized except between parties > that already have a preexisting relationship (employee/employer, > between two ISPs, etc.) Servers to anonymous clients (e.g., customer/ > business) or more open services (e.g., BGP, where routers may have > large numbers of peers) are unmanageable, due to the breadth and flux > of CAs. [...] > > ==> This is too simplistic description of why IPsec isn't used between > routers. While management of certificates is a major issue, at least as > important for me as an operator are the processing requirements of > IPsec. If you don't have dedicated hardware for the task, I'd rather spend > the routing engine's CPU cycles on processing the BGP update packets (and > other control data) rather than encryption, decryption, hashing, etc. This paragraph is talking about key distribution; it is the earlier one that talks about computation. > Let me say this clearly: BTNS/Anonsec will not be used by routers unless > they have dedicated IPsec hardware (and the vast majority of them won't in > the short term at least). (Hopefully this will be appropriately > reflected in the BTNS problem statement as well.) Dedicated IPsec hardware is very cheap (e.g., for 100Mbps streams), and IMO should be added to routers to protect their management CPUs from computational overload. We have another draft in progress to talk about reducing the CPU overload of IPsec, esp. for DOS attacks, but that was already deemed out of scope for BTNS. I.e., computational effort was taken off the table there during the BOF stages (despite my efforts to the contrary ;-) > 7) not sure if I agree with conclusions because we haven't yet reached > consensus on the body yet (this is a placeholder :) The document makes comparisons and recommendations in those contexts throughout; I don't know if it's feasible to summarize them in a single paragraph at the end. ... > ==> not sure if I completely agree with these conclusions here (and > in section 5), but when/if we get to agreement on the main body of the > doc, it should be easier to get to consensus on the recommendations as > well. The recommendations have been there in several revisions with WG opportunity to comment, and have been revised accordingly several times already. > editorial > --------- > > This, coupled with the lack of sufficient address filtering to drop > such spoofed traffic, can increase the potential for off-path third- > party spoofing attacks. > > ==> you include refs later in the doc for this, so maybe they should be > here as well. Done. > [...] even when not > fixed, there are only 65,384 valid source ports which may be > exhaustively attacked. > > ==> how do you get that specific number? Why this isn't 2^16 ? Typo. Fixed as "approximately 65,000", which is sufficient for this doc. I didn't want to get deep into which numbers cannot be used as source ports (it seemed like unassigned ones shouldn't, but I couldn't verify that). > protocol, although emerging as standard practice, unnecessarily > complicates the design and implementation of new protocols [28] As > new attacks are discovered (SYN floods, RSTs, etc.), each protocol > > ==> missing a period here. Fixed. > In addition, many networks filter all ICMP packets because validation > may not be possible, especially because they can be injected from any > point on a path, and so cannot be selectively address filtered. > > ==> actually, the problem with ICMP is that they can be injected from any > point *at all*, not just restricted to the path, and regular address > filtering doesn't help there (whereas address filtering could help with TCP > RSTs in some cases). Fixed. > Network solutions are computationally intensive and require pervasive > registration of certificate authorities with every possible endpoint. > This section explains these observations further. > > ==> after the addition of address filtering in section 3.2, this needs > to be > updated to refer to just the ipsec part of network solutions. Fixed. > 4. the entire body of the packet is secured > > 5. security associations are established only where identity is > authenticated by a know certificate authority or other pre-shared > key > > 6. both on-path and off-path third-party spoofing attacks must be > defeated > > ==> these should be numbered from 1 to 3, as you're referring to (1) and > (2) > in the text below... fixed. > [2] Baker, F. and P. Savola, "Ingress Filtering for Multihomed > Networks," RFC 2827 / BCP 84, March 2004. > > [12] Ferguson, P. and D. Senie, Network Ingress Ingress Filt > Defeating Denial of Service Attacks which employ IP Add > Spoofing," RFC 2267 / BCP 38, May 2000. > > ==> BCP 84 is RFC 3704 while BCP 38 is 2827; earlier version of BCP 38 was > 2267. Fixed (thanks for the catch). > [38] Touch, J., "ANONsec: Anonymous Security to Defend Again > Spoofing Attacks," draft-touch-anonsec-00 (work in prog > May 2004. > > [5] Better Than Nothing Security [BTNS] BOF, IETF-61, Wash. DC., > http://www.ietf.org/ietf/04nov/btns.txt > > ==> these (and the text where they're referred to) have since been somewhat > obsoleted. Maybe it would be sufficient to refer to the latest BTNS WG > docs and/or the BTNS charter? Fixed. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Feb 20 16:05:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBIDU-0002qM-84; Mon, 20 Feb 2006 16:05:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBIDS-0002pi-Nn for tcpm@ietf.org; Mon, 20 Feb 2006 16:05:06 -0500 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBIDQ-0005Oi-8f for tcpm@ietf.org; Mon, 20 Feb 2006 16:05:06 -0500 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id E4C491EA; Mon, 20 Feb 2006 15:47:54 -0500 (EST) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 48C75E2; Mon, 20 Feb 2006 15:47:52 -0500 (EST) Date: Mon, 20 Feb 2006 15:47:52 -0500 (EST) From: Janardhan Iyengar X-X-Sender: iyengar@stimpy.eecis.udel.edu To: Sally Floyd In-Reply-To: <200601300622.k0U6Mvvq065454@cougar.icir.org> Message-ID: References: <200601300622.k0U6Mvvq065454@cougar.icir.org> X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on louie.udel.edu X-Spam-Level: X-Spam-Status: No, score=-3.8 required=4.1 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm, v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Cc: Ethan Blanton , tcpm@ietf.org, Mark Allman Subject: [tcpm] Re: draft-iyengar-burst-mitigation-01.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 Sally, (Resonse to: http://www1.ietf.org/mail-archive/web/tcpm/current/msg01671.html) Thank you very much for spending time on this draft, and thank you for your comments! I am sorry that I am quite late in replying. Hope this email addresses your concerns, if not, then generates further discussion. > * The network's tolerance of burstiness: [...] I have added some text (based on your suggestions) that now seems more appropriate in the Discussion section (Section 4). I have also changed the tone somewhat... I do not stress the fact that increased deployment of AQM is happening (which I think was one of your points, correct me if I read wrong). The reason I changed the tone was to maintain focus on micro-burst mitigation, while mentioning the parallel effects of AQM. Let me know if you think the following captures it, or if you'd suggest mods. We emphasize that the question of whether or not micro-bursts need mitigation remains open. While use of micro-burst mitigation can reduce stress on network queues, congested routers may, in parallel, use some form of Active Queue Management (AQM) to better handle stress on network queues. Use of AQM in a router allows for better congestion control through better congestion signals (i.e., signals other than packet drops) and enables queues to accomodate transient bursts in the aggregate incoming traffic. Micro-burst mitigation may still provide some respite by reducing the amount of transient burstiness in the traffic aggregate at a queue. > * Rate-based pacing: > [...] I think it would be worth it to say that there are many cases > where rate-based pacing should be a big win over CWL, or over MaxBurst, > in terms of traffic dynamics. [...] I have modified the para in the Related Work Section (Section 3) to reflect your suggestions. Also see the following argument. * Rate-Based Pacing [VH97] imposes a limitation on the rate of sending, and prevent bursts by pacing data into the network until the ACK clock is established. Although this solution can be very effective in burst mitigation in some cases, it requires a new timer and parameters for pacing out the data segments. Further, as shown in [AB05], there are cases where there is no natural "lull" in the connection into which segments can be nicely paced, and as shown in [AST00], the tradeoffs involved in using pacing are not clear. While the exact application of pacing clearly requires more research, there are several cases where pacing can be expected to mitigate bursts better than CWL (or MaxBurst or UI/LI). For instance, where CWL (also MaxBurst and UI/LI) will not be able to handle bursts caused by slow start, pacing could work well and prevent these transient bursts. Pacing can potentially also have a bigger impact on traffic aggregates, possibly significantly reducing burstiness in the aggregate at several timescales. > E.g., in a short connection with only BLimit + 1 more packets to send, > but when only one ack will be arriving, due to ACK losses. I do not use this example, because I am not sure how RBP will be in short connections, i.e., I am not clear on the tradeoffs here---for instance, what happens if the RTT value is seeded incorrectly in such a small connection? But I believe the larger point you wanted to convey has been captured in the para above. Let me know if not. > But my suggestion would be to be more explicit about the potential > advantages of rate-based pacing, and to say something about it a little > earlier in the document. I hope that para was able to capture it, but I'm not sure about saying something earlier in the document. This section is the first place that the other algorithms are mentioned and the pros and cons discussed. Do you think the entire section should appear earlier? > * Security: > I think that the security issues raised in Section 5 are pretty > important, and could use more discussion. This is another case > where rate-based pacing would be more robust than CWL, I think. I'll try to add more discussion on that point. Do you have anything specific in mind that you might want to suggest? While I suspect that rate-based pacing may be more robust than CWL under ack loss, it is difficult for me to make a strong comparative statement without knowing what exactly would be used for rate-based pacing. Depending on the exact details, I suspect that rate-based pacing *could also possibly* be (differently) susceptible to issues such as ack loss. So, I am not sure that we should say anything about how the mentioned security issue applies to rate-based pacing. > * Causes of micro-bursts: ACK-compression can also be a cause of > micro-bursts. (That is, ACK-compression can cause micro-bursts as well > as macro-bursts.) How so? I am thinking about it, but cannot figure out how that could be. A micro-burst is defined as a burst sent in response to one ACK. In time, I suppose ACK-compression could cause bursts at the same timescale. In other words, some macro-burst phenomena could occur at the timescales that the bursts resemble micro-bursts. Maybe we should state that explicitly in the discussion about macro-bursts. Something like "Note that some macro-bursts could occur at the timescales of micro-bursts---for instance, back-to-back ACKs due to extreme ACK-compression could cause the consequent data burst to resemble a micro-burst from the network's point of view." What do you think? > * Section 2, step (1): > "the only case where a micro-burst will not occur" -> > "the only case where a micro-burst will not occur, if steps (2) > and (3) aren't used". I am thinking of taking that entire sentence out---it does not add much value, but the cost of parsing it is high (and is getting higher). Unless someone sees enough value in it, that is. > * "BLimit SHOULD be chosen such that bursts are no larger than those > allowed by [RFC3390]." > > Why is this? It is not obvious to me. I was thinking about a fixed burst limit that one could apply for line-rate bursts, and it seemed reasonable to use 3390 as a basis. My (simplistic) reasoning was that since bursts from starting TCP connections should be absorbable by the network, 3390-defined bursts should be acceptable in general. > For example, four-packet bursts, for 1500-byte packets, might be > perfectly acceptable, for a connection that has a sufficiently large > congestion window to send that many packets. And there is a cost to > BLimit being at most three 1500-byte packets. I'm not sure I'm following. A large cwnd does not mean more segments can be sent (at line-rate) in response to _each ack_. BLimit is meant to impose that limit, not to limit the overall cwnd size. IMHO, having a large cwnd does not mean that a large burst is acceptable. Yes, I agree that there is a cost to having BLimit at what it is. But is there a situation that demands larger line-rate bursts? What do you think is a reasonable limit (static/dynamic)? I may not be following what you are saying; if so, let me know. > * Maxburst: > "An additional drawback of MaxBurst ...". > What was the first drawback? Introducing a separate control? But > the earlier sentence says that "using two different controls may > make sense". New text: However, a drawback with MaxBurst is that adding a second control brings with it the possibility of the two transmission controllers interacting poorly to cause undesirable side effects. > "the two transmission controllers may interact poorly, causing > undesirable side effects." > Do you have any examples of this? Or citations? Or anything > else to back this up? Not really. The idea was to suggest that there is the possibility of poor interaction due to the introduction of a new control. Maybe the new text (see above) captures this more effectively? > "When BLimit == MaxBurst, CWL and MaxBurst perform similarly [AB05]." > I don't see how CWL and MaxBurst can perform similarly, and at > the same time you can prefer one over the other. I think it would > be useful to look a little more closely for performance differences, > or to say that there aren't any. (I'm checking with my co-authors on this one. Will get back to you asap.) > Depending on how it is implemented, MaxBurst could be made to work > quite well with re-ordering, where each duplicate ack packet (possibly > from reordering of data packets) could be responded-to with up to > MaxBurst data packets (if allowed by the congestion window). > (E.g., Aggressive MaxBurst from [AB05].) > Can something like this be done with CWL as well? Hmm. Offhand, I do not see how this can be done with CWL, but I will think about it more. This is a good point though. Maybe we should mention this in the related work section where we discuss pros and cons of MaxBurst. Thanks again! - jana -------------------- Janardhan R. Iyengar http://www.cis.udel.edu/~iyengar Protocol Engineering Lab, University of Delaware _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Feb 22 11:27:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBwqF-0004MF-AA; Wed, 22 Feb 2006 11:27:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBwqE-0004M4-5v; Wed, 22 Feb 2006 11:27:50 -0500 Received: from [156.154.16.129] (helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBwqD-0002pK-SZ; Wed, 22 Feb 2006 11:27:50 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k1MGRjvP001598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Feb 2006 16:27:46 GMT Received: from mirror by ietf.org with local (Exim 4.43) id 1FBwq9-0003Ms-Uj; Wed, 22 Feb 2006 11:27:45 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: IETF Announcement list From: IESG Secretary Message-Id: Date: Wed, 22 Feb 2006 11:27:45 -0500 X-Spam-Score: -2.3 (--) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: tcpm@ietf.org, Ted Faber , Mark Allman Subject: [tcpm] WG Action: RECHARTER: TCP Maintenance and Minor Extensions (tcpm) 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 charter of the TCP Maintenance and Minor Extensions (tcpm) working group in the Transport Area of the IETF has been updated. For additional information, please contact the Area Directors or the working group Chairs. +++ TCP Maintenance and Minor Extensions (tcpm) ============================================= Current Status: Active Working Group Chair(s): Ted Faber Mark Allman Transport Area Director(s): Allison Mankin Jon Peterson Transport Area Advisor: Jon Peterson Mailing Lists: General Discussion: tcpm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/tcpm Archive: http://www.ietf.org/mail-archive/web/tcpm/index.html Description of Working Group: TCP is currently the Internet's predominant transport protocol. To maintain TCP's utility the IETF has regularly updated both the protocol itself and the congestion control algorithms implemented by the protocol that are crucial for the stability of the Internet. These changes reflect our evolving understanding of transport protocols, congestion control and new needs presented by an ever-changing network. The TCPM WG will provide a venue within the IETF to work on these issues. The WG will serve several purposes: * The WG will mostly focus on maintenance issues (e.g., bug fixes) and modest changes to the protocol and algorithms that maintain TCP's utility. * The WG will be a venue for moving current TCP specifications along the standards track (as community energy is available for such efforts). * The WG will write a document that outlines "what is TCP". This document will be a roadmap of sorts to the various TCP specifications in the RFC series. TCPM will take a subset of the work which has been conducted in the Transport Area WG over the past several years. Specifically, some of the WG's initial work will be moved from the Transport Area WG (tsvwg). TCPM is expected to be the working group within the IETF to handle TCP changes. Proposals for additional TCP work items should be brought up within the working group. While fundamental changes to TCP or its congestion control algorithms (e.g., departure from loss-based congestion control) should be brought through TCPM, it is expected that such large changes will ultimately be handled by the Transport Area WG (tsvwg). All additional work items for TCPM will, naturally, require the approval of the Transport Services Area Area Directors and the IESG. TCP's congestion control algorithms are the model followed by alternate transports (e.g., SCTP and (in some cases) DCCP). In addition, the IETF has recently worked on several documents about algorithms that are specified for multiple protocols (e.g., TCP and SCTP) in the same document. Which WG shepherds such documents in the future will determined on a case-by-case basis. In any case, the TCPM WG will remain in close contact with other relevant WGs working on these protocols to ensure openness and stringent review from all angles. Specific Goals: * A document specifying a way to share the local "User TimeOut" value with the peer such that TCP connections can withstand long periods of disconnection. * The WG is working on an experimental technique to add robustness to TCP against packet reordering having a negative impact on performance. * The WG is coming to grips with how to deal with spoofed segments that can tear down connections, cause data corruption or performance problems. To this end the WG is generating an overview document as well as a scheme that mitigates some of the spoofed segment issues using a challenge-response scheme to reduce the probabilities of a connection being impacted. * The WG is writing an informational document about the ways in which TCPs can handle ICMP "soft errors". * The WG is updating the specification for Explicit Congestion Notification to allow for the use of ECN during part of TCP's three-way handshake to aid performance for short transfers. Milestones: Apr 06 Submit NCR Reordering Mitigation draft to the IESG for publication as an Experimental RFC. Apr 06 Submit ECN-SYN document to the IESG for publication as a Proposed Standard RFC. May 06 Submit overview of spoofing attacks against TCP to IESG for publication as an Informational RFC. May 06 Submit In-Window Attack draft to IESG for publication as a Proposed Standard RFC. May 06 Submit User TimeOut option document to the IESG for publication as a Proposed Standard RFC. May 06 Submit soft errors document to the IESG for publication as an Informational RFC. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Feb 22 15:50:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC0w0-000539-E9; Wed, 22 Feb 2006 15:50:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC0vy-00050s-Ue; Wed, 22 Feb 2006 15:50:02 -0500 Received: from [156.154.16.129] (helo=cypress.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC0vy-00070W-5u; Wed, 22 Feb 2006 15:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k1MKo10e014625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Feb 2006 20:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FC0vx-0004Pg-Of; Wed, 22 Feb 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 22 Feb 2006 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-tcp-antispoof-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Defending TCP Against Spoofing Attacks Author(s) : J. Touch Filename : draft-ietf-tcpm-tcp-antispoof-03.txt Pages : 27 Date : 2006-2-22 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 guess a viable RST sequence number. The susceptibility to attack increases as the square of the bandwidth, thus presents a significant vulnerability for recent high-speed networks. This document addresses this vulnerability, discussing proposed solutions at the transport level and their inherent challenges, as well as existing network level solutions and the feasibility of their deployment. This document focuses on vulnerabilities due to spoofed TCP segments, and includes a discussion of related ICMP spoofing attacks on TCP connections. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-antispoof-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tcpm-tcp-antispoof-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tcpm-tcp-antispoof-03.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: <2006-2-22123448.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-tcp-antispoof-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-antispoof-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-22123448.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 Wed Feb 22 19:09:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC436-0000ls-K7; Wed, 22 Feb 2006 19:09:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC435-0000ln-0j for tcpm@ietf.org; Wed, 22 Feb 2006 19:09:35 -0500 Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC434-0002U9-DM for tcpm@ietf.org; Wed, 22 Feb 2006 19:09:34 -0500 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.11/8.12.11) with ESMTP id k1N09Mfm050803; Wed, 22 Feb 2006 16:09:22 -0800 (PST) (envelope-from floyd@cougar.icir.org) Message-Id: <200602230009.k1N09Mfm050803@cougar.icir.org> To: Janardhan Iyengar From: Sally Floyd Date: Wed, 22 Feb 2006 16:09:22 -0800 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Cc: Ethan Blanton , tcpm@ietf.org, Mark Allman Subject: [tcpm] Re: draft-iyengar-burst-mitigation-01.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 >> * The network's tolerance of burstiness: [...] > >I have added some text (based on your suggestions) that now seems more >appropriate in the Discussion section (Section 4). I have also changed the >tone somewhat... I do not stress the fact that increased deployment of AQM >is happening (which I think was one of your points, correct me if I read >wrong). The reason I changed the tone was to maintain focus on micro-burst >mitigation, while mentioning the parallel effects of AQM. Let me know if >you think the following captures it, or if you'd suggest mods. > > We emphasize that the question of whether or not micro-bursts need > mitigation remains open. While use of micro-burst mitigation can > reduce stress on network queues, congested routers may, in parallel, > use some form of Active Queue Management (AQM) to better handle > stress on network queues. Use of AQM in a router allows for better > congestion control through better congestion signals (i.e., signals > other than packet drops) and enables queues to accomodate transient > bursts in the aggregate incoming traffic. Micro-burst mitigation may > still provide some respite by reducing the amount of transient > burstiness in the traffic aggregate at a queue. Yep, that sounds good to me. >> * Rate-based pacing: >> [...] I think it would be worth it to say that there are many cases >> where rate-based pacing should be a big win over CWL, or over MaxBurst, >> in terms of traffic dynamics. [...] > >I have modified the para in the Related Work Section (Section 3) to >reflect your suggestions. Also see the following argument. > > * Rate-Based Pacing [VH97] imposes a limitation on the rate of > sending, and prevent bursts by pacing data into the network until the ACK clock is established. Although this solution can > be very effective in burst mitigation in some cases, it requires > a new timer and parameters for pacing out the data segments. > Further, as shown in [AB05], there are cases where there is no > natural "lull" in the connection into which segments can be > nicely paced, and as shown in [AST00], the tradeoffs involved in > using pacing are not clear. While the exact application of > pacing clearly requires more research, there are several cases > where pacing can be expected to mitigate bursts better than CWL > (or MaxBurst or UI/LI). For instance, where CWL (also MaxBurst and > UI/LI) will not be able to handle bursts caused by slow start, > pacing could work well and prevent these transient > bursts. Pacing can potentially also have a bigger impact on > traffic aggregates, possibly significantly reducing burstiness in > the aggregate at several timescales. > >> E.g., in a short connection with only BLimit + 1 more packets to send, >> but when only one ack will be arriving, due to ACK losses. > >I do not use this example, because I am not sure how RBP will be in short >connections, i.e., I am not clear on the tradeoffs here---for instance, >what happens if the RTT value is seeded incorrectly in such a small >connection? But I believe the larger point you wanted to convey has been >captured in the para above. Let me know if not. That sounds fine to me. >> But my suggestion would be to be more explicit about the potential >> advantages of rate-based pacing, and to say something about it a little >> earlier in the document. > >I hope that para was able to capture it, but I'm not sure about saying >something earlier in the document. This section is the first place that >the other algorithms are mentioned and the pros and cons discussed. Do you >think the entire section should appear earlier? No, I think it is fine. >> * Security: >> I think that the security issues raised in Section 5 are pretty >> important, and could use more discussion. This is another case >> where rate-based pacing would be more robust than CWL, I think. > >I'll try to add more discussion on that point. Do you have anything >specific in mind that you might want to suggest? Nope, not really. >While I suspect that rate-based pacing may be more robust than CWL under >ack loss, it is difficult for me to make a strong comparative statement >without knowing what exactly would be used for rate-based pacing. >Depending on the exact details, I suspect that rate-based pacing *could >also possibly* be (differently) susceptible to issues such as ack loss. >So, I am not sure that we should say anything about how the mentioned >security issue applies to rate-based pacing. I disagree. The point of this paper is not be be a used-car salesman for CWL (sorry), the point is to evaluate CWL as fairly as you are able, including considering its weaknesses, and considering when alternate proposals might be more robust in some particular respects. If you "suspect that rate-based pacing may be more robust than CWL under ack loss", or under reordering of data or acks, then I think it would be good to think about it a bit, and to say something. The question isn't whether it would be *possible* to design a rate-based pacing mechanism that would share the same weaknesses, but whether it would be *possible* to design a rate-based pacing mechanism that didn't. In my opinion. >> * Causes of micro-bursts: ACK-compression can also be a cause of >> micro-bursts. (That is, ACK-compression can cause micro-bursts as well >> as macro-bursts.) > >How so? I am thinking about it, but cannot figure out how that could be. >A micro-burst is defined as a burst sent in response to one ACK. In time, >I suppose ACK-compression could cause bursts at the same timescale. In >other words, some macro-burst phenomena could occur at the timescales that >the bursts resemble micro-bursts. Maybe we should state that explicitly in >the discussion about macro-bursts. Something like > >"Note that some macro-bursts could occur at the timescales of >micro-bursts---for instance, back-to-back ACKs due to extreme >ACK-compression could cause the consequent data burst to resemble a >micro-burst from the network's point of view." > >What do you think? My advice would be to broaden your definition of micro-bursts to include bursts on small time scales due to ACK compression. Then you could talk about which mechanisms do or don't ameliorate the bursts due to ACK compression... ... >> * "BLimit SHOULD be chosen such that bursts are no larger than those >> allowed by [RFC3390]." >> >> Why is this? It is not obvious to me. > >I was thinking about a fixed burst limit that one could apply for >line-rate bursts, and it seemed reasonable to use 3390 as a basis. My >(simplistic) reasoning was that since bursts from starting TCP connections >should be absorbable by the network, 3390-defined bursts should be >acceptable in general. I might be worth talking about the potential costs of an unnecessarily-small burst limit, so that it is clear that it is a case of making a tradeoff somewhere. >> For example, four-packet bursts, for 1500-byte packets, might be >> perfectly acceptable, for a connection that has a sufficiently large >> congestion window to send that many packets. And there is a cost to >> BLimit being at most three 1500-byte packets. > >I'm not sure I'm following. A large cwnd does not mean more segments can >be sent (at line-rate) in response to _each ack_. BLimit is meant to >impose that limit, not to limit the overall cwnd size. IMHO, having a >large cwnd does not mean that a large burst is acceptable. When you say that "BLimit SHOULD be chosen such that bursts are no larger than those allowed by [RFC3390]", you are saying that BLimit should not allow micro-bursts of four 1500-byte packets, but should only allow micro-bursts of three 1500-byte packets, right? I am just asking what is wrong with a micro-burst of four 1500-byte packets? (For a connection that has a congestion window large enough to send four 1500-byte packets.) I understand that BLimit doesn't limit the overall cwnd size. >Yes, I agree that there is a cost to having BLimit at what it is. But is >there a situation that demands larger line-rate bursts? Yep, consider a connection with only four 1500-byte packets left to send, but only one ACK coming in (because delayed ACKs are used, and one of the last two ACKs was dropped or reordered). >What do you think is a reasonable limit (static/dynamic)? I may not be >following what you are saying; if so, let me know. My own vote would be to set BLimit to at least four packets, regardless of packet size. Maybe even five packets... >> * Maxburst: >> "An additional drawback of MaxBurst ...". >> What was the first drawback? Introducing a separate control? But >> the earlier sentence says that "using two different controls may >> make sense". > >New text: >However, a drawback with >MaxBurst is that adding a second control brings with it the >possibility of the two transmission controllers interacting >poorly to cause undesirable side effects. I still don't buy it. You have said elsewhere that "When BLimit == MaxBurst, CWL and MaxBurst perform similarly [AB05]." Except that you think that MaxBurst might have a fatal flaw not shared by CWL, you just haven't run across it yet? Because you can bring up the language of "two controllers interacting" for MaxBurst? I don't buy it. [Just as an aside, after the sentence above, you could mention Aggressive MaxBurst, which improves on CWL by being robust to reordering.] >> "the two transmission controllers may interact poorly, causing >> undesirable side effects." >> Do you have any examples of this? Or citations? Or anything >> else to back this up? > >Not really. The idea was to suggest that there is the possibility of poor >interaction due to the introduction of a new control. Maybe the new text >(see above) captures this more effectively? As I said above, I don't buy it... ... >> Depending on how it is implemented, MaxBurst could be made to work >> quite well with re-ordering, where each duplicate ack packet (possibly >> from reordering of data packets) could be responded-to with up to >> MaxBurst data packets (if allowed by the congestion window). >> (E.g., Aggressive MaxBurst from [AB05].) >> Can something like this be done with CWL as well? > >Hmm. Offhand, I do not see how this can be done with CWL, but I will think >about it more. This is a good point though. Maybe we should mention this >in the related work section where we discuss pros and cons of MaxBurst. I think that would be good. Regards, - Sally _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Feb 22 19:55:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC4l5-00066z-Ao; Wed, 22 Feb 2006 19:55:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC1iI-0003D0-V9; Wed, 22 Feb 2006 16:39:58 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC1aB-0003hO-64; Wed, 22 Feb 2006 16:31:38 -0500 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k1MLUas05627; Wed, 22 Feb 2006 13:30:36 -0800 (PST) Message-ID: <43FCD7FD.90204@isi.edu> Date: Wed, 22 Feb 2006 13:30:37 -0800 From: Joe Touch User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Internet-Drafts@ietf.org Subject: Re: [tcpm] I-D ACTION:draft-ietf-tcpm-tcp-antispoof-03.txt References: In-Reply-To: X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: tcpm@ietf.org, i-d-announce@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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This version includes all pending feedback based on Ted (provided and addressed privately) and Pekka (posted recently). I would like to try to get this wrapped up soon - perhaps the chairs can suggest how to proceed. Joe Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. > > Title : Defending TCP Against Spoofing Attacks > Author(s) : J. Touch > Filename : draft-ietf-tcpm-tcp-antispoof-03.txt > Pages : 27 > Date : 2006-2-22 > > 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 guess a viable RST > sequence number. The susceptibility to attack increases as the > square of the bandwidth, thus presents a significant vulnerability > for recent high-speed networks. This document addresses this > vulnerability, discussing proposed solutions at the transport level > and their inherent challenges, as well as existing network level > solutions and the feasibility of their deployment. This document > focuses on vulnerabilities due to spoofed TCP segments, and includes > a discussion of related ICMP spoofing attacks on TCP connections. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-antispoof-03.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-tcpm-tcp-antispoof-03.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-tcpm-tcp-antispoof-03.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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD/Nf9E5f5cImnZrsRAvSFAKDwRDZMI+ZEkS7E52QFfe+0b/VteQCfUoLn XSqSB7lV9XzNYT//5XaCd2s= =opsF -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Feb 23 00:22:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC8va-0007SF-W3; Thu, 23 Feb 2006 00:22:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC8vZ-0007S7-PA for tcpm@ietf.org; Thu, 23 Feb 2006 00:22:09 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC8vY-0007Y5-F7 for tcpm@ietf.org; Thu, 23 Feb 2006 00:22:09 -0500 Received: from [192.168.1.47] (pool-71-106-130-244.lsanca.dsl-w.verizon.net [71.106.130.244]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k1N5L5q12216; Wed, 22 Feb 2006 21:21:05 -0800 (PST) Message-ID: <43FD463B.30003@isi.edu> Date: Wed, 22 Feb 2006 21:20:59 -0800 From: Joe Touch User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Sally Floyd Subject: Re: [tcpm] Re: draft-iyengar-burst-mitigation-01.txt References: <200602230009.k1N09Mfm050803@cougar.icir.org> In-Reply-To: <200602230009.k1N09Mfm050803@cougar.icir.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Ethan Blanton , tcpm@ietf.org, Janardhan Iyengar , Mark Allman 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: ... > My own vote would be to set BLimit to at least four packets, regardless > of packet size. Maybe even five packets... The reason we chose that number is documented in our earlier ID. IMO, much of that discussion is directly relevant to this work. In fact, I can't see why this algorithm was derived from CWL vs BOL. ... >> in the related work section where we discuss pros and cons of MaxBurst. That too would be a good place to consider the discussion in the earlier ID. IMO, it would be useful to merge those two documents to move forward, since that doc had a much more detailed discussion of these alternatives. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Feb 23 10:41:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCIao-00021I-CF; Thu, 23 Feb 2006 10:41:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCIan-00020o-3c for tcpm@ietf.org; Thu, 23 Feb 2006 10:41:21 -0500 Received: from server.frh.utn.edu.ar ([170.210.17.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCIak-0002dr-O9 for tcpm@ietf.org; Thu, 23 Feb 2006 10:41:21 -0500 Received: (qmail 32539 invoked from network); 23 Feb 2006 15:41:51 -0000 Received: from ftp.frh.utn.edu.ar (HELO fgont.gont.com.ar) (gont-fernando@170.210.17.150) by server.frh.utn.edu.ar with SMTP; 23 Feb 2006 15:41:51 -0000 Message-Id: <7.0.1.0.0.20060223071700.059c6f40@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 23 Feb 2006 07:39:31 -0800 To: tcpm@ietf.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Subject: [tcpm] Revision of the TCP soft errors 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 Folks, I have submitted a revision of the tcp soft errors draft (now draft-ietf-tcpm-tcp-soft-errors-00.txt). The draft will be on the internet-drafts repository very soon. In the mean time, you can access it from: http://www.gont.com.ar/drafts/draft-ietf-tcpm-tcp-soft-errors-00.txt I think the draft is pretty stable now. The latest feedback addresses was miscellaneous editorial changes proposed by Pekka Savola. It would be very appreciated to receive feedback on this version. The Abstract of the draft is: ---- cut here ---- This document discusses problems that may arise due to TCP's reaction to soft errors. In particular, it discusses the problem of long delays in connection establishment attempts that may arise when dual stack nodes that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 environments. The purpose of this document is to discuss this potential problem, and analyze the ways in which it could be worked around. It does not to try to specify whether IPv6 should be enabled by default or not. ---- cut here ---- The course of the draft was basically this: * draft-gont-tcpm-tcp-soft-errors-00.txt proposed the alternative processing of ICMP soft errors to avoid long delay between connection-establishment attempts. The WG agreed more discussion was needed on the pros and cons. * draft-gont-tcpm-tcp-soft-errors-01.txt included alternative ways to avoid the long delays between connection establishment attempts (several connections issued in parallel, etc.), and a discussion of the pros and cons of the proposed mechanism. The WG agreed to take the document as a WG item, provided it just discussed the alternative processing of ICMP soft errors, rather than "proposing" it. * draft-gont-tcpm-tcp-soft-errors-02.txt addressed those comments. This version of the draft does not propose the change, but rather limits itself to describe it and analyze its pros and cons. * draft-ietf-tcpm-tcp-soft-errors-00.txt basically makes some miscellaneous editorial changes proposed by Pekka. (All previous versions of the draft are available at: http://www.gont.com.ar/drafts/tcp-soft-errors.html) Again, comments on the draft will be more than welcome. Thanks! -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Feb 24 15:50:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCjt4-00023r-Rs; Fri, 24 Feb 2006 15:50:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCjt4-00023R-4N; Fri, 24 Feb 2006 15:50:02 -0500 Received: from [156.154.16.129] (helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCjt3-0000Bf-S6; Fri, 24 Feb 2006 15:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k1OKo1vP003105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 Feb 2006 20:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FCjt3-0002V7-El; Fri, 24 Feb 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 24 Feb 2006 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-tcp-soft-errors-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: , Errors-To: tcpm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : TCP's Reaction to Soft Errors Author(s) : F. Gont Filename : draft-ietf-tcpm-tcp-soft-errors-00.txt Pages : 14 Date : 2006-2-24 This document discusses the problem of long delays between connection establishment attempts that may arise in a number of scenarios, including that in which dual stack nodes that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 environments. Additionally, it describes a modification to TCP's reaction to soft errors that has been implemented in a variety of TCP/IP stacks to help overcome this problem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-soft-errors-00.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-00.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-00.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: <2006-2-24140749.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-tcp-soft-errors-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-soft-errors-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-24140749.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 Sat Feb 25 18:52:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD9D2-0004QE-To; Sat, 25 Feb 2006 18:52:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD9D1-0004PD-Ui for tcpm@ietf.org; Sat, 25 Feb 2006 18:52:19 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FD9D1-0000xR-HL for tcpm@ietf.org; Sat, 25 Feb 2006 18:52:19 -0500 Received: from [192.168.1.47] (pool-71-106-130-244.lsanca.dsl-w.verizon.net [71.106.130.244]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k1PNp9q07306; Sat, 25 Feb 2006 15:51:09 -0800 (PST) Message-ID: <4400ED66.10909@isi.edu> Date: Sat, 25 Feb 2006 15:51:02 -0800 From: Joe Touch User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Ron Bonica Subject: Re: [tcpm] draft-bonica-tcp-auth-04 References: <43E11848.10809@juniper.net> In-Reply-To: <43E11848.10809@juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 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 Ron Bonica wrote: > Folks, > > Please review the draft at the following URL: > > http://www.ietf.org/internet-drafts/draft-bonica-tcp-auth-04.txt > Overall, this document still doesn't address the significant concerns that Ted and I raised in on the -00 version, in particular, this seems too much like a patch of TCP/MD5 without addressing the lack of a keying mechanism. In particular, it focuses too much (IMO) on time-based key rotation rather than relying on secure, in-band rekeying. Some particular comments follow: key-chain is a TCP-EA data structure, not a TCP one keys should NOT be used for both inbound and outbound simultaneously what is the purpose of parsing the TCP header before validating the segment? (the header has no meaning until validated) why should routers log errors? they terminate TCP connections only when acting as hosts anyway; it seems like all hosts should do this TCP uses state and relative time (timeouts); this protocol uses absolute time. the document AGAIN fails to discuss the security implications of relying on absolute time (this was raised at the WG meeting in Vancouver) FWIW, RFC3562's reference to key lifetimes is NOT an endorsement of using absolute time to change keys; that doc is referring to rekeying over time (i.e., sec 16 is incorrect IMO - 3562 never mentions 'schedules') I noted before that time-based keychains are not typical; it would be useful to explain why such a complex mechanism is being added, rather than a true rekeying protocol (which is more typical, and would address initial keying as well) at least one key selection algorithm MUST be supported. if all MAYs are dropped, the result MUST (IMO) be complete enough to work regarding the MAC, are any fields padded if not word-aligned? (that needs to be noted, either way) when omitting the TCP options, does that also omit the TCP-EA option? (it should not) the algorithm does NOT need to be encoded in the header; the key ID can easily include that information (like in IPsec) the header could be much more compact: kind 8 bits length 6 bits (40 is max value) K-bit 1 bit resv'd 1 bit FYI - this MUST be set to zero in current impl's AND MUST be ignored on receipt ("MUST be equal to zero" implies the receiver will check it, and that will kill its use for extensions) IMO, use all 16 bits remaining for the key ID (there are performance reasons to make the key ID space large and harder to guess off-path; I can discuss this at the WG meeting if anyone likes) sec 11 should be calleed extensions, since this option is already named an enahancement; however - this section MUST be completed for this doc to have any impact. 'poor clock sync' is to colloquial; if you depend on clock sync, you need: - to discuss how you will establish that with only TCP or will this run only in the presence of NTP? - to discuss exactly how this depends on NTP Errors in clock sync ARE errors detected here; that MAY be logged as a TCP-EA error (otherwise you'll never be able to debug this) the section on resets is incomplete; if you depend on time, you may never be able to clean up state even if you have keys. that can affect the ability to reuse port space. i.e., you may want to add something that helps TCP-EA connections clean up if idle past when ANY key would be valid (among other things) the section on performance is too colloqial, esp. since perfomance is one of the reasons TCP/MD5 is not widely used. it would help to have current examples of the impact of performance on utility, even if they change over time (FWIW, RFC1810 showed how they don't much) end of sec 12.4 - the remaining octets are for other options (if there are any others that fit in that space) or for larger hashes in the MACs of TCP-EA. sec 12.5 - if this is really intended to force exclusion of TCP/MD5, why not use the same option number and use a flag to redefine the rest of the header? sec 12.6 - this defends against only off-path ICMP attacks; ICMP messages can still be forged on-path with copies of valid packets and not be invalidated. sec 12.8 should be added - to describe relationship to IPsec/IKE sec 13 changes the valid time of an existing key; that MUST NOT be permitted, IMO. that sort of thing encourages key reuse, which defeats the key lifetime issues addressed in RFC3562. Along those lines, NO KEY should be able to have an expiration time that is more than a few weeks in the future. in particular, "INFINITY" MUST NOT be a valid time. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Feb 27 05:42:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDfpV-00087X-DR; Mon, 27 Feb 2006 05:42:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDfpT-00087G-IE for tcpm@ietf.org; Mon, 27 Feb 2006 05:42:11 -0500 Received: from server.frh.utn.edu.ar ([170.210.17.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDfpR-0004sO-Mv for tcpm@ietf.org; Mon, 27 Feb 2006 05:42:11 -0500 Received: (qmail 13793 invoked from network); 27 Feb 2006 10:42:35 -0000 Received: from ftp.frh.utn.edu.ar (HELO fgont.gont.com.ar) (gont-fernando@170.210.17.150) by server.frh.utn.edu.ar with SMTP; 27 Feb 2006 10:42:35 -0000 Message-Id: <7.0.1.0.0.20060226220302.027d3480@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 27 Feb 2006 05:59:31 -0300 To: tcpm@ietf.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [tcpm] Revision of the ICMP attacks 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 Folks, I have submitted a revision of the ICMP attacks draft. The draft will be on the internet-drafts repository very soon. In the mean time, you can access it from: http://www.gont.com.ar/drafts/draft-ietf-tcpm-icmp-attacks-00.txt The Abstract of the draft is: ---- cut here ---- This document discusses the use of the Internet Control Message Protocol (ICMP) to perform a variety of attacks against the Transmission Control Protocol (TCP) and other similar protocols. It proposes several counter-measures to eliminate or minimize the impact of these attacks. ---- cut here ---- draft-gont-tcpm-icmp-attacks-05.txt was accepted as a WG document, for the Informational path. This (draft-tcpm-icmp-attacks-00.txt) new revision of the draft addresses the feedback received on at the last IETF and on the mailing-list. Among the changes are: * RFC2119 wording was removed, to make the draft suitable for publication as an Informational RFC. * The rationale behind each check has (hopefully) been clarified. * Other checks that should be performed on the received ICMP messages (such as the checksum of the IP packet in the ICMP payload) are now included in the draft. This draft has been around for quite a while, and has benefited from a large amount of feedback provided by both the TCPM WG, the open source community, vendors in general, etc. Most systems implement at least a subset of the counter-measures proposed in the draft. Feedback on this revision of the draft will be more than welcome. Thanks! -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Feb 27 10:50:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDkdX-0006fK-1O; Mon, 27 Feb 2006 10:50:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDkdO-0006bt-Io; Mon, 27 Feb 2006 10:50:02 -0500 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDkdO-0007Fj-4o; Mon, 27 Feb 2006 10:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k1RFo19W006788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Feb 2006 15:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FDkdN-0003Tf-Sn; Mon, 27 Feb 2006 10:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 27 Feb 2006 10:50:01 -0500 X-Spam-Score: 0.3 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-icmp-attacks-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: , 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 : ICMP attacks against TCP Author(s) : F. Gont Filename : draft-ietf-tcpm-icmp-attacks-00.txt Pages : 36 Date : 2006-2-27 This document discusses the use of the Internet Control Message Protocol (ICMP) to perform a variety of attacks against the Transmission Control Protocol (TCP) and other similar protocols. It proposes several counter-measures to eliminate or minimize the impact of these attacks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-icmp-attacks-00.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-icmp-attacks-00.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-icmp-attacks-00.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: <2006-2-27092700.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-icmp-attacks-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-icmp-attacks-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-27092700.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --NextPart-- From tcpm-bounces@ietf.org Mon Feb 27 14:30:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDo4n-0003i0-PP; Mon, 27 Feb 2006 14:30:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDo4l-0003hp-QI for tcpm@ietf.org; Mon, 27 Feb 2006 14:30:31 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDo4k-0007Ma-Fr for tcpm@ietf.org; Mon, 27 Feb 2006 14:30:31 -0500 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k1RJTbu22562 for ; Mon, 27 Feb 2006 11:29:37 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.13.4/8.13.4/Submit) id k1RJTbns061361 for tcpm@ietf.org; Mon, 27 Feb 2006 11:29:37 -0800 (PST) (envelope-from faber) Date: Mon, 27 Feb 2006 11:29:37 -0800 From: Ted Faber To: tcpm@ietf.org Message-ID: <20060227192937.GH48644@hut.isi.edu> Mime-Version: 1.0 User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [tcpm] TCPM agenda requests 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="===============0135297023==" Errors-To: tcpm-bounces@ietf.org --===============0135297023== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="K1n7F7fSdjvFAEnM" Content-Disposition: inline --K1n7F7fSdjvFAEnM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi. Sorry to be so late with this, but if you're interested in presenting at the TCPM meeting in Dallas, please let Mark and me know before Thursday. We'll post an agenda Friday. Thanks! --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --K1n7F7fSdjvFAEnM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (FreeBSD) iD8DBQFEA1MhaUz3f+Zf+XsRAmIuAKC0Bk7SiIQe6Hw0wQaTEoxeBare1gCfWpaO Kqeh2w0qUP5wj2fPsy/s+88= =dnn1 -----END PGP SIGNATURE----- --K1n7F7fSdjvFAEnM-- --===============0135297023== 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 --===============0135297023==-- From tcpm-bounces@ietf.org Tue Feb 28 16:03:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEC0T-00011W-Ut; Tue, 28 Feb 2006 16:03:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEBpp-0000W8-EI; Tue, 28 Feb 2006 15:52:41 -0500 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEBnG-0001Z1-A5; Tue, 28 Feb 2006 15:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k1SKo19W027727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Feb 2006 20:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FEBnF-0000zh-RW; Tue, 28 Feb 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 28 Feb 2006 15:50:01 -0500 X-Spam-Score: 0.3 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-tcp-roadmap-06.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : A Roadmap for TCP Specification Documents Author(s) : M. Duke, et al. Filename : draft-ietf-tcpm-tcp-roadmap-06.txt Pages : 42 Date : 2006-2-28 This document contains a "roadmap" to the Requests for Comments (RFC) documents relating to the Internet's Transmission Control Protocol (TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in the RFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-roadmap-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-roadmap-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-roadmap-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-2-28142624.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-tcp-roadmap-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-roadmap-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-28142624.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--