From Michael.Scharf@alcatel-lucent.com Mon Aug 1 02:18:16 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 622CA21F8666 for ; Mon, 1 Aug 2011 02:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.217 X-Spam-Level: X-Spam-Status: No, score=-6.217 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7j0bwMgGZ3f5 for ; Mon, 1 Aug 2011 02:18:15 -0700 (PDT) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by ietfa.amsl.com (Postfix) with ESMTP id 90DCD21F8571 for ; Mon, 1 Aug 2011 02:18:15 -0700 (PDT) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id p719IJwg017264 for ; Mon, 1 Aug 2011 11:18:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 1 Aug 2011 11:18:17 +0200 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C0654BCDC@SLFSNX.rcs.alcatel-research.de> In-Reply-To: <4E35FD22.50006@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Request for feedback on WG adoptionof draft-cheng-tcpm-fastopen-00 Thread-Index: AcxP5+Y3y7SKKnqjQk+han17JLRCIwAPzMdA References: <133D9897FB9C5E4E9DF2779DC91E947C0654BBCE@SLFSNX.rcs.alcatel-research.de> <4E35FD22.50006@gmail.com> From: "SCHARF, Michael" To: "TCP Maintenance and Minor Extensions WG" X-Scanned-By: MIMEDefang 2.64 on 149.204.45.73 Subject: Re: [tcpm] Request for feedback on WG adoptionof draft-cheng-tcpm-fastopen-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 09:18:16 -0000 Please find two comments inline > On 7/27/11 1:01 PM, SCHARF, Michael wrote: > > In order to determine the WG consensus, the chairs ask for=20 > additional=20 > > feedback on that draft. Please provide feedback whether you=20 > find this=20 > > draft useful or not, and whether you think that it should=20 > become a WG=20 > > item. > > > Please note that I've previously stated that this is a really=20 > bad idea! >=20 > I was so irritated by this idea that I publicly posted an=20 > alternative (that had been privately baking for some time). =20 > It was forwarded to be published as Experimental some time=20 > ago -- still awaiting IESG review. > > I don't know how/why this was reconsidered at yet another=20 > meeting, as there were no updates fixing anything that was=20 > raised previously. Most conferences (or working groups)=20 > don't allow multiple presentations of the same paper. Well, the presentation apparently contains new material, as requested by the TCPM chairs. =20 > > Also, please let us know if there should be technical=20 > issues that are=20 > > not addressed so far by the draft and that would require further=20 > > discussion or analysis. > > > I could re-post my objections again, but really it boils down to: >=20 > 1) insecure, demonstrates very poor knowledge of security principles. >=20 > 2) doesn't work with commonly deployed middleboxen, degrades badly. It would help to technically substantiate these claims. draft-cheng-tcpm-fastopen-00 already explains some security issues and potential counter-measures. And if I correctly understand Michio Honda's comment during the TCPM meeting, his measurements don't confirm the second statement (but I have not seen these results and thus I might be wrong). Michael (TCPM co-chair) From william.allen.simpson@gmail.com Mon Aug 1 08:27:43 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3377421F8B17 for ; Mon, 1 Aug 2011 08:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.407 X-Spam-Level: X-Spam-Status: No, score=-3.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIzE7gQIOyPj for ; Mon, 1 Aug 2011 08:27:42 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6D221F8B14 for ; Mon, 1 Aug 2011 08:27:42 -0700 (PDT) Received: by iye7 with SMTP id 7so8360600iye.31 for ; Mon, 01 Aug 2011 08:27:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=gM74im11aloUwjt1EhwS0a4DgwXitNjJOHDCTzicgYg=; b=ArWOl7mhRBehikZJY+Q4ynFvrryqtzd3NUU/BCjfkOFE8zCaE2gj/P80z3dFZ8jPMF t2XfjdY9EBaVM8pnWIkfBepXcGPCFdYKs6FrlKwq+mOmK+5wKiAHgL94uh9duEhtsMHS daw5fQwyHx/Pn2OBf0A8QC4/Gn6/JV82UElRw= Received: by 10.42.158.129 with SMTP id h1mr3098821icx.195.1312212468679; Mon, 01 Aug 2011 08:27:48 -0700 (PDT) Received: from Wastrel-3.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id s6sm1456901ibs.3.2011.08.01.08.27.46 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 01 Aug 2011 08:27:47 -0700 (PDT) Message-ID: <4E36C5F1.9010904@gmail.com> Date: Mon, 01 Aug 2011 11:27:45 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: TCP Maintenance and Minor Extensions WG References: <133D9897FB9C5E4E9DF2779DC91E947C0654BBCE@SLFSNX.rcs.alcatel-research.de> <4E35FD22.50006@gmail.com> <133D9897FB9C5E4E9DF2779DC91E947C0654BCDC@SLFSNX.rcs.alcatel-research.de> In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C0654BCDC@SLFSNX.rcs.alcatel-research.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] Request for feedback on WG adoption of draft-cheng-tcpm-fastopen-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 15:27:43 -0000 On 8/1/11 5:18 AM, SCHARF, Michael wrote: > Please find two comments inline > >> I don't know how/why this was reconsidered at yet another >> meeting, as there were no updates fixing anything that was >> raised previously. Most conferences (or working groups) >> don't allow multiple presentations of the same paper. > > Well, the presentation apparently contains new material, as requested by > the TCPM chairs. > Ah, well then, perhaps they should publish the presentation as an RFC. Because really, presentations and going to conferences are what protocol designing is all about. :-( >>> Also, please let us know if there should be technical >> issues that are >>> not addressed so far by the draft and that would require further >>> discussion or analysis. >>> >> I could re-post my objections again, but really it boils down to: >> >> 1) insecure, demonstrates very poor knowledge of security principles. >> >> 2) doesn't work with commonly deployed middleboxen, degrades badly. > > It would help to technically substantiate these claims. > When I have more time, I'll re-post them again later. > draft-cheng-tcpm-fastopen-00 already explains some security issues and > potential counter-measures. And if I correctly understand Michio Honda's > comment during the TCPM meeting, his measurements don't confirm the > second statement (but I have not seen these results and thus I might be > wrong). > Since Cisco has likely sold a million (or more) ASA firewalls, I simply don't believe his measurements! :-( Since Cisco EoL'd it, and service contracts ended May 15, 2011, don't expect any more updates. Folks I've corresponded with haven't even deployed earlier updates, so we really shouldn't have high expectations. And that's just the most prevalent product. There seem to be plenty of others I've not successfully identified.... If I can find this stuff as an individual with just a few simple probes of the 'net and checking operations lists, I wonder how much effort this huge company put into testing, and/or what they've been smoking. Moreover, I told some of these folks at Google back in late January-early February of 2010 that their ideas wouldn't work, and added the (ab)use of Sack in TCPCT for them. I wish I'd charged them for wasting my time. [heavy sigh] From mallman@icir.org Tue Aug 2 05:26:22 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D73A21F8D73 for ; Tue, 2 Aug 2011 05:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWIZZM0sAtQy for ; Tue, 2 Aug 2011 05:26:22 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id F353321F85AB for ; Tue, 2 Aug 2011 05:26:21 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p72CQQQE007909 for ; Tue, 2 Aug 2011 05:26:26 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 7205646B447D for ; Tue, 2 Aug 2011 08:26:26 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman In-Reply-To: <20110307142951.B4B093436C51@lawyers.icir.org> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Rock and Roll Fantasy MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma60657-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 02 Aug 2011 08:26:26 -0400 Sender: mallman@icir.org Message-Id: <20110802122626.7205646B447D@lawyers.icir.org> Subject: Re: [tcpm] new ID on RTO considerations X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 12:26:22 -0000 ----------ma60657-1 Content-Type: text/plain Content-Disposition: inline Folks- > See draft-allman-tcpm-rto-consider-00.txt . Its rough, but I hope > gets the idea across. I see this document is expiring. I wonder if this is something folks think is useful or not. I am happy to polish it a bit based on the small amount of feedback it kicked up when I issued the I-D. My personal hit is that its a worthwhile four pager to basically say what the fundamental RTO principles are and hence guide future RTO mechanisms (in TCP and not [*]). That said, I have plenty of things to do and am happy to drop it, too. [*] There is really nothing in the document tied to TCP, so in retrospect perhaps TSVWG is a better place? allman ----------ma60657-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk437PIACgkQWyrrWs4yIs5M9ACfWyQzvaesHc9aU+UabEQ1J5D6 n70AnjfmkQd/hGPJU7HEqt0cbmGvUtMs =34Id -----END PGP SIGNATURE----- ----------ma60657-1-- From hagen@jauu.net Tue Aug 9 12:05:59 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 425B411E80DC for ; Tue, 9 Aug 2011 12:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[AWL=-0.327, BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZrVwdZLXdmO for ; Tue, 9 Aug 2011 12:05:58 -0700 (PDT) Received: from geheimer.internetendpunkt.de (alternativer.internetendpunkt.de [88.198.24.89]) by ietfa.amsl.com (Postfix) with ESMTP id 73A7C11E80E0 for ; Tue, 9 Aug 2011 12:05:58 -0700 (PDT) Received: by geheimer.internetendpunkt.de (Postfix, from userid 1000) id 6641EF44130; Tue, 9 Aug 2011 21:06:25 +0200 (CEST) Date: Tue, 9 Aug 2011 21:06:24 +0200 From: Hagen Paul Pfeifer To: tcpm@ietf.org Message-ID: <20110809190624.GC7618@nuttenaction> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Key-Id: 98350C22 X-Key-Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22 X-GPG-Key: gpg --recv-keys --keyserver wwwkeys.eu.pgp.net 98350C22 User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [tcpm] Thoughts about Fairness, Vendors and the Spirit of TCP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 19:05:59 -0000 Some thoughts about recent activity here at TCPM and some other places. Since several years vendors and web companies try to address web performance problems by adjusting TCP. Congestion control, slow start (IW10), timeouts and the like are addressed like a function of time: IW10 seems adequate for 2011, IW15 for 2013, IW20 for 2016 and so on. Timeouts are adjusted to current “consumer” networks. But the actual network characteristic is hardly a function of date, it is a function of the effective link characteristic between two endpoints in a packet switched networks with no a priori bandwidth guarantee. X.25, multi-hop sensor networks and low bandwidth radio links are _still employed_. Links with a BDP of a few thousands byte per second, links that cope with few packets in flight and with a large intrinsic jitter. These networks are still there. IW10, IW14, IWx are proposed to speed things up. Don't get me wrong: I am generally ok with IW10 - I believe that the (potential) negative impact is manageable, overshooting the link is unlikely. I believe that this window is in the lower range of noise, so that a flow - and all other flows - reach a stable equilibrium. But I am concerned about even larger IW values. Last but not least: I cherish the work of Jerry, Joe, Michael, Mark, Ilpo, Matt, Nandita at al. The argument that modern web browsers - or FTP client’s - actually open several parallel connections to speed up the process is no valid argument. It _make_ things worse, because it de-facto disable congestion control. I.e. in extreme to transfer 1Gbyte, a client *can* spawn 10000 TCP connections in parallel, but with each connection you make the global congestion control mechanism less effective. To forecast something: I don't believe that Chrome and Co disable the "parallel connection attempt" if IW10 is approved and becomes a standard track. In the end we will see several parallel connection attempts AND IW10: simultaneously open n connections and shortly after the three way handshake receive n*10 packets in one flush. Because clients can spawn several connection in parallel does not mean that they should or is fair regarding Jain's fairness index. Larger vendors should not try to modify TCP in their horizon - TCP is for everyone. To gain milliseconds on "their" side probably mean loss of several seconds on the "other" side. Modify TCP is a short term solution. The long term solution is somewhere else. HTTP for example could cache more information: nearly 95% of all web-pages on my daily basis are identical: images, logos, web-page text fragments, java script files and so on are identical. I download them over and over again. But it is easier for vendors to tune TCP. But tuning TCP will not scale infinitely, you have a limited bandwidth and with a packet switch network you have the probe the available bandwidth – that’s a fact. Consider this email as an plea to keep the spirit of a conservative TCP in the standardization body. Hagen From Michael.Scharf@alcatel-lucent.com Thu Aug 11 03:03:47 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40A8B21F886D for ; Thu, 11 Aug 2011 03:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.477 X-Spam-Level: X-Spam-Status: No, score=-5.477 tagged_above=-999 required=5 tests=[AWL=-0.717, BAYES_05=-1.11, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N23Gv2LrFmB9 for ; Thu, 11 Aug 2011 03:03:46 -0700 (PDT) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by ietfa.amsl.com (Postfix) with ESMTP id 1908D21F886A for ; Thu, 11 Aug 2011 03:03:44 -0700 (PDT) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id p7BA4HBI023922 for ; Thu, 11 Aug 2011 12:04:17 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 11 Aug 2011 12:04:16 +0200 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C0654BFE5@SLFSNX.rcs.alcatel-research.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft TCPM minutes for IETF 81 Thread-Index: AcxYDgebfTUWE0QLScKy+mAXDRlzSw== From: "SCHARF, Michael" To: "TCP Maintenance and Minor Extensions WG" X-Scanned-By: MIMEDefang 2.64 on 149.204.45.73 Subject: [tcpm] Draft TCPM minutes for IETF 81 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 10:03:47 -0000 Hi all, I uploaded draft minutes of the TCPM meeting in Quebec City: http://www.ietf.org/proceedings/81/minutes/tcpm.txt I'd like to thank Andrew his excellent notes, and Gorry for his help during the meeting. Please let me know if you have any comments or corrections. Thanks Michael From wes@mti-systems.com Mon Aug 15 21:42:10 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF81221F86B6 for ; Mon, 15 Aug 2011 21:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNhQ9IXeLSW2 for ; Mon, 15 Aug 2011 21:42:10 -0700 (PDT) Received: from omr4.networksolutionsemail.com (omr4.networksolutionsemail.com [205.178.146.54]) by ietfa.amsl.com (Postfix) with ESMTP id 5696C21F85B9 for ; Mon, 15 Aug 2011 21:42:10 -0700 (PDT) Received: from cm-omr8 (mail.networksolutionsemail.com [205.178.146.50]) by omr4.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p7G4gt3G027603 for ; Tue, 16 Aug 2011 00:42:55 -0400 Authentication-Results: cm-omr8 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [174.130.42.163] ([174.130.42.163:33737] helo=[192.168.1.103]) by cm-omr8 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id EF/A1-23389-E45F94E4; Tue, 16 Aug 2011 00:42:54 -0400 Message-ID: <4E49F54C.60200@mti-systems.com> Date: Tue, 16 Aug 2011 00:42:52 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [tcpm] proposal for additional experimental-use option kind numbers X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 04:42:11 -0000 I would be interested in the WG's feedback on this proposal to add more TCP option kind numbers designated for experimental-use: http://www.ietf.org/id/draft-eddy-tcpm-addl-exp-options-00.txt This would be intended to resolve the issue discovered with tcpcrypt recently, which Joe brought up and Mark explained and on the tsvwg list. The idea is to simply provide more experimental-use numbers so that this type of situation can be avoided, and to provide enough that multiple simultaneous experiments are possible, even if some of the new space happens to get accidentally populated with shipping products again. Particularly, I would like to know if there's WG consensus that this approach to solving the problem is the way to go, as I would hope this could be done by TCPM. Thanks in advance. -- Wes Eddy MTI Systems From touch@isi.edu Mon Aug 15 22:44:28 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3BE621F8B45 for ; Mon, 15 Aug 2011 22:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.402 X-Spam-Level: X-Spam-Status: No, score=-104.402 tagged_above=-999 required=5 tests=[AWL=2.197, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4C9mDZzfy04D for ; Mon, 15 Aug 2011 22:44:28 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6D21321F8B3D for ; Mon, 15 Aug 2011 22:44:28 -0700 (PDT) Received: from [192.168.1.85] (pool-71-105-81-169.lsanca.dsl-w.verizon.net [71.105.81.169]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p7G5ifoQ001967 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 15 Aug 2011 22:44:50 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Joe Touch In-Reply-To: <4E49F54C.60200@mti-systems.com> Date: Mon, 15 Aug 2011 22:44:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4AAE62C9-C2E8-4CEF-BB92-3F51DB500104@isi.edu> References: <4E49F54C.60200@mti-systems.com> To: Wesley Eddy X-Mailer: Apple Mail (2.1244.3) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] proposal for additional experimental-use option kind numbers X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 05:44:29 -0000 Hi, all, I disagree with this proposal. The two existing option values are more than sufficient. They can be = used with a short nonce selected arbitrarily that should suffice to keep = experiments distinct. The cost would be overhead and limited ability to = be used with many other options concurrently outside of a closed test = environment (where the nonce can be omitted). This overhead should be = acceptable for experiments. Any attempt to allocate additional numbers without use of this sort of = nonce (which I had suggested for all such experimental option values, = e.g., for the experimental port number codepoints) makes additional = allocations continually necessary; if we assume this sort of nonce, the = current pair of codepoints is more than sufficient. In the meantime EVERYONE using the current codepoints in deployed = products needs to be strongly encouraged to clean up the mess they've = created. And anyone using non-experimental codepoints (tcpcrypt - I'm = talking to YOU) needs to PULL THEIR CODE FROM THEIR DISTRIBUTION SERVER = **NOW**. If we're not going to do these last two things, let's just stop all this = wasted effort and just not run a codepoint registry at all. Joe On Aug 15, 2011, at 9:42 PM, Wesley Eddy wrote: > I would be interested in the WG's feedback on this proposal to > add more TCP option kind numbers designated for experimental-use: >=20 > http://www.ietf.org/id/draft-eddy-tcpm-addl-exp-options-00.txt >=20 >=20 > This would be intended to resolve the issue discovered with > tcpcrypt recently, which Joe brought up and Mark explained and > on the tsvwg list. >=20 > The idea is to simply provide more experimental-use numbers so > that this type of situation can be avoided, and to provide > enough that multiple simultaneous experiments are possible, > even if some of the new space happens to get accidentally > populated with shipping products again. >=20 > Particularly, I would like to know if there's WG consensus > that this approach to solving the problem is the way to go, > as I would hope this could be done by TCPM. >=20 > Thanks in advance. >=20 > --=20 > Wes Eddy > MTI Systems > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From internet-drafts@ietf.org Mon Aug 22 09:05:02 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 968DD21F8B2D; Mon, 22 Aug 2011 09:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdv0R8rsFE+7; Mon, 22 Aug 2011 09:05:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E2A21F8AE6; Mon, 22 Aug 2011 09:05:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.59 Message-ID: <20110822160502.25054.80981.idtracker@ietfa.amsl.com> Date: Mon, 22 Aug 2011 09:05:02 -0700 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-persist-05.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 16:05:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions = Working Group of the IETF. Title : Clarification of sender behavior in persist condition. Author(s) : Murali Bashyam Mahesh Jethanandani Anantha Ramaiah Filename : draft-ietf-tcpm-persist-05.txt Pages : 12 Date : 2011-08-22 This document clarifies the Zero Window Probes (ZWP) described in Requirements for Internet Hosts [RFC1122]. In particular, it clarifies the actions that can be taken on connections which are experiencing the ZWP condition. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-persist-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tcpm-persist-05.txt From fernando.gont.netbook.win@gmail.com Wed Aug 24 09:06:58 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB79721F8876 for ; Wed, 24 Aug 2011 09:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.395 X-Spam-Level: X-Spam-Status: No, score=-3.395 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QoDXblszsmZP for ; Wed, 24 Aug 2011 09:06:58 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6BFAA21F86CA for ; Wed, 24 Aug 2011 09:06:58 -0700 (PDT) Received: by yxj17 with SMTP id 17so1167814yxj.31 for ; Wed, 24 Aug 2011 09:08:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=05GAosKKVYkjpIjNYP00w+sSm+1PtAI+DbWT4Gme7nc=; b=G2kPQFBuBAhDEyhVEXYRNuxx8gYFHpUvltdCdOtO6OubUJQrQI/nrpJzh754Bf4Z2r eRlUfnrtPEH4Ru17rpBzPhBurl0N0f6O2HSyuC7IwFiL18/DdsZ1kJZN+JIr8HBhv1iY vjAP0zAM37+CzzjCaDsCUDYMRYhhCH5cPq9D8= Received: by 10.100.191.15 with SMTP id o15mr4948346anf.42.1314202089223; Wed, 24 Aug 2011 09:08:09 -0700 (PDT) Received: from [192.168.123.103] ([190.48.232.93]) by mx.google.com with ESMTPS id 9sm1003167and.51.2011.08.24.09.08.06 (version=SSLv3 cipher=OTHER); Wed, 24 Aug 2011 09:08:08 -0700 (PDT) Sender: Fernando Gont Message-ID: <4E54DF75.8050902@gont.com.ar> Date: Wed, 24 Aug 2011 08:24:37 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Joe Touch References: <4E49F54C.60200@mti-systems.com> <4AAE62C9-C2E8-4CEF-BB92-3F51DB500104@isi.edu> In-Reply-To: <4AAE62C9-C2E8-4CEF-BB92-3F51DB500104@isi.edu> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org Subject: Re: [tcpm] proposal for additional experimental-use option kind numbers X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 16:06:59 -0000 On 08/16/2011 02:44 AM, Joe Touch wrote: > In the meantime EVERYONE using the current codepoints in deployed > products needs to be strongly encouraged to clean up the mess they've > created. And anyone using non-experimental codepoints (tcpcrypt - I'm > talking to YOU) needs to PULL THEIR CODE FROM THEIR DISTRIBUTION > SERVER **NOW**. Without taking a stance with respect to the specific proposal and the other issues being discussed, I'd argue that "the cat is out of the bag" already. So I don't think the aforementioned "clean-up" is feasible (not that I like it, though). Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From touch@isi.edu Wed Aug 24 12:27:39 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8143521F8C72 for ; Wed, 24 Aug 2011 12:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.449 X-Spam-Level: X-Spam-Status: No, score=-103.449 tagged_above=-999 required=5 tests=[AWL=-0.850, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y14uK+dZ6KHr for ; Wed, 24 Aug 2011 12:27:39 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 0C83721F8C52 for ; Wed, 24 Aug 2011 12:27:39 -0700 (PDT) Received: from [207.151.143.121] ([207.151.143.121]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id p7OJSU1w027276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Aug 2011 12:28:33 -0700 (PDT) Message-ID: <4E5550DE.4060402@isi.edu> Date: Wed, 24 Aug 2011 12:28:30 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Fernando Gont References: <4E49F54C.60200@mti-systems.com> <4AAE62C9-C2E8-4CEF-BB92-3F51DB500104@isi.edu> <4E54DF75.8050902@gont.com.ar> In-Reply-To: <4E54DF75.8050902@gont.com.ar> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] proposal for additional experimental-use option kind numbers X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 19:27:39 -0000 On 8/24/2011 4:24 AM, Fernando Gont wrote: > On 08/16/2011 02:44 AM, Joe Touch wrote: >> In the meantime EVERYONE using the current codepoints in deployed >> products needs to be strongly encouraged to clean up the mess they've >> created. And anyone using non-experimental codepoints (tcpcrypt - I'm >> talking to YOU) needs to PULL THEIR CODE FROM THEIR DISTRIBUTION >> SERVER **NOW**. > > Without taking a stance with respect to the specific proposal and the > other issues being discussed, I'd argue that "the cat is out of the bag" > already. > > So I don't think the aforementioned "clean-up" is feasible (not that I > like it, though). That cannot be our approach. If it is, I *WILL* deploy code that uses all remaining option numbers in every protocol I can find, and we'll have none left for anyone. ;-) Seriously, ERRORS ARE ERRORS - they don't define the de-facto standards. The standard is that these codepoints are not yet assigned, and those who use them need to STOP. And - IMO - we as a community need to stop giving those who ignore our policies a mic at IETF meetings. Joe From shep@xplot.org Wed Aug 24 13:01:34 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2338321F8B1D for ; Wed, 24 Aug 2011 13:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94Nljs7SshDx for ; Wed, 24 Aug 2011 13:01:33 -0700 (PDT) Received: from www.xplot.org (www.xplot.org [66.92.66.146]) by ietfa.amsl.com (Postfix) with ESMTP id 8974E21F85F7 for ; Wed, 24 Aug 2011 13:01:33 -0700 (PDT) Received: from shep (helo=alva.home) by www.xplot.org with local-esmtp (Exim 3.36 #1 (Debian)) id 1QwJeU-00042d-00; Wed, 24 Aug 2011 16:02:18 -0400 From: Tim Shepard To: Joe Touch In-reply-to: Your message of Wed, 24 Aug 2011 12:28:30 -0700. <4E5550DE.4060402@isi.edu> Date: Wed, 24 Aug 2011 16:02:18 -0400 Message-Id: Sender: Tim Shepard Cc: tcpm@ietf.org, Fernando Gont Subject: Re: [tcpm] proposal for additional experimental-use option kind numbers X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 20:01:34 -0000 > Seriously, ERRORS ARE ERRORS - they don't define the de-facto standards. > The standard is that these codepoints are not yet assigned, and those > who use them need to STOP. I don't believe the IETF or anyone else has any power to force anyone to stop distributing anything. In particular, anything that runs over IP can be done between consenting end systems. > And - IMO - we as a community need to stop giving those who ignore our > policies a mic at IETF meetings. You or anyone else are free to offer harsh criticism (which might be appropriate here), but I think it is important that the IETF remain a very open organization, with no particular overall policies on who gets mic time. (Though I do not object to empowering WG chairs to run meetings in efficient ways.) And we should do whatever makes sense going forward, without the desire of some to punish or rebuke past bad behavior stopping us from doing whatever makes good sense going forward. BTW, with the way modern distributed version control systems work (and the way "the net" works in many ways these days) there's no good way to ever take anything back. Git, for example, deliberately makes it difficult to rewrite history. (It is not impossible, but everyone downstream can easily detect that upstream is attempting to change history. And it would be an unusual event. IMHO this is a very good thing.) Instead of insisting that code be taken down, the more constructive way forward is to offer a patch and convince as many people as possible that the patch should be adopted. And if you don't want to develop the patch yourself, try to convince others to develop it, and distribute it, and adopt it. I don't think telling people to STOP doing something that they find useful to do is likely to win them over. (And I'm not sure a patch is even needed here, there may be an easier and simpler way forward.) -Tim Shepard shep@alum.mit.edu From touch@isi.edu Wed Aug 24 13:06:40 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0331D21F8610 for ; Wed, 24 Aug 2011 13:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.166 X-Spam-Level: X-Spam-Status: No, score=-105.166 tagged_above=-999 required=5 tests=[AWL=1.433, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDhHPG9sTTfg for ; Wed, 24 Aug 2011 13:06:39 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 8296E21F84F7 for ; Wed, 24 Aug 2011 13:06:39 -0700 (PDT) Received: from [207.151.143.121] ([207.151.143.121]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p7OK7RH3029060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Aug 2011 13:07:36 -0700 (PDT) Message-ID: <4E5559FF.9070400@isi.edu> Date: Wed, 24 Aug 2011 13:07:27 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Tim Shepard References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Fernando Gont Subject: Re: [tcpm] proposal for additional experimental-use option kind numbers X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 20:06:40 -0000 On 8/24/2011 1:02 PM, Tim Shepard wrote: ... > (And I'm not sure a patch is even needed here, there may be an easier > and simpler way forward.) Presuming you don't mean assigning the squatted numbers (which, again, I offer to gobble up if that's how things work), do you have a suggestion? Joe From touch@isi.edu Wed Aug 24 14:57:43 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4489821F8D49 for ; Wed, 24 Aug 2011 14:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.339 X-Spam-Level: X-Spam-Status: No, score=-105.339 tagged_above=-999 required=5 tests=[AWL=1.260, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUv-LPE-082K for ; Wed, 24 Aug 2011 14:57:42 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id CE71C21F8D46 for ; Wed, 24 Aug 2011 14:57:42 -0700 (PDT) Received: from [207.151.143.121] ([207.151.143.121]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p7OLwK4B009794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Aug 2011 14:58:29 -0700 (PDT) Message-ID: <4E5573FC.1020509@isi.edu> Date: Wed, 24 Aug 2011 14:58:20 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Tim Shepard References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Fernando Gont Subject: Re: [tcpm] proposal for additional experimental-use option kind numbers X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 21:57:43 -0000 On your other point... On 8/24/2011 1:02 PM, Tim Shepard wrote: >> Seriously, ERRORS ARE ERRORS - they don't define the de-facto standards. >> The standard is that these codepoints are not yet assigned, and those >> who use them need to STOP. > > I don't believe the IETF or anyone else has any power to force anyone > to stop distributing anything. Force, no. Shame, yes. We also ought to have the power NOT to reward those who deliberately disobey what little rules we have. > In particular, anything that runs over IP can be done between > consenting end systems. Your rights end where mine begin, as with everything. Squatting on a TCP option number interferes with the assignment of that number to legitimate uses. ... > And we should do whatever makes sense going forward, without the > desire of some to punish or rebuke past bad behavior stopping us from > doing whatever makes good sense going forward. Please review the term "moral hazard". If you don't address this past behavior, then others will follow. Like me, as I already suggested ;-) We already had a similar debate on whether to assign the current TCP experimental option codepoints to a system that had been inappropriately deployed. Please review that discussion as well. ... > Instead of insisting that code be taken down, the more constructive > way forward is to offer a patch and convince as many people as > possible that the patch should be adopted. Sure. Let's all devote our spare time to fixing every bug in other people's experiments when they disobey our procedures. Or - here's a new idea - why not ask (which I already did a few IETFs ago) them to fix their own mess? And if they don't, we ought to - as a community - demand better. Joe From touch@isi.edu Wed Aug 24 18:02:15 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9CA21F8C00 for ; Wed, 24 Aug 2011 18:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.236 X-Spam-Level: X-Spam-Status: No, score=-105.236 tagged_above=-999 required=5 tests=[AWL=1.363, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVvVi+8fuzxR for ; Wed, 24 Aug 2011 18:02:14 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id A414121F8BFE for ; Wed, 24 Aug 2011 18:02:14 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p7P13FGW006078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Aug 2011 18:03:15 -0700 (PDT) Message-ID: <4E559F53.4040908@isi.edu> Date: Wed, 24 Aug 2011 18:03:15 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "tcpm@ietf.org" References: <20110824202401.GA15594@vim.isi.edu> In-Reply-To: <20110824202401.GA15594@vim.isi.edu> X-Forwarded-Message-Id: <20110824202401.GA15594@vim.isi.edu> Content-Type: multipart/mixed; boundary="------------010905000009060000010203" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: [tcpm] Fwd: Re: proposal for additional experimental-use option kind numbers X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 01:02:15 -0000 This is a multi-part message in MIME format. --------------010905000009060000010203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Forwarded for Ted... -------- Original Message -------- Subject: Re: [tcpm] proposal for additional experimental-use option kind numbers Date: Wed, 24 Aug 2011 13:24:01 -0700 From: Ted Faber To: Tim Shepard CC: Joe Touch , tcpm@ietf.org, Fernando Gont On Wed, Aug 24, 2011 at 04:02:18PM -0400, Tim Shepard wrote: > > > > Seriously, ERRORS ARE ERRORS - they don't define the de-facto standards. > > The standard is that these codepoints are not yet assigned, and those > > who use them need to STOP. > > I don't believe the IETF or anyone else has any power to force anyone > to stop distributing anything. > > In particular, anything that runs over IP can be done between > consenting end systems. > > > > And - IMO - we as a community need to stop giving those who ignore our > > policies a mic at IETF meetings. > > > You or anyone else are free to offer harsh criticism (which might be > appropriate here), but I think it is important that the IETF remain a > very open organization, with no particular overall policies on who > gets mic time. (Though I do not object to empowering WG chairs to run > meetings in efficient ways.) > > And we should do whatever makes sense going forward, without the > desire of some to punish or rebuke past bad behavior stopping us from > doing whatever makes good sense going forward. > > > BTW, with the way modern distributed version control systems work (and > the way "the net" works in many ways these days) there's no good way > to ever take anything back. Git, for example, deliberately makes it > difficult to rewrite history. (It is not impossible, but everyone > downstream can easily detect that upstream is attempting to change > history. And it would be an unusual event. IMHO this is a very good > thing.) > > Instead of insisting that code be taken down, the more constructive > way forward is to offer a patch and convince as many people as > possible that the patch should be adopted. And if you don't want to > develop the patch yourself, try to convince others to develop it, and > distribute it, and adopt it. I don't think telling people to STOP > doing something that they find useful to do is likely to win them over. > > (And I'm not sure a patch is even needed here, there may be an easier > and simpler way forward.) I generally hate to post "me, too," but I thought Tim's position was both well thought out and well said. -- 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 --------------010905000009060000010203 Content-Type: application/pgp-signature; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYyLjAuMTgg KEZyZWVCU0QpDQoNCmlFWUVBUkVDQUFZRkFrNVZYZDRBQ2drUWFVejNmK1pmK1h2V2xBQ2Zj SmVtaDlKVHNGbHdUQlBSU0tnYzJWVDUNClc3RUFuMEwxMUNDc015YkJ1SXZucHRyYllHZkFp UTdXDQo9YWx2NA0KLS0tLS1FTkQgUEdQIFNJR05BVFVSRS0tLS0tDQoNCg== --------------010905000009060000010203-- From touch@isi.edu Wed Aug 24 18:19:23 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F12721F86EA for ; Wed, 24 Aug 2011 18:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.255 X-Spam-Level: X-Spam-Status: No, score=-105.255 tagged_above=-999 required=5 tests=[AWL=1.344, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLNLQv2OvwaK for ; Wed, 24 Aug 2011 18:19:22 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 8248721F8686 for ; Wed, 24 Aug 2011 18:19:22 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p7P1K8o4009096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Aug 2011 18:20:08 -0700 (PDT) Message-ID: <4E55A348.3050705@isi.edu> Date: Wed, 24 Aug 2011 18:20:08 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Fernando Gont References: <4E49F54C.60200@mti-systems.com> <4AAE62C9-C2E8-4CEF-BB92-3F51DB500104@isi.edu> <4E54DF75.8050902@gont.com.ar> <4E5550DE.4060402@isi.edu> In-Reply-To: <4E5550DE.4060402@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] proposal for additional experimental-use option kind numbers X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 01:19:23 -0000 On 8/24/2011 12:28 PM, Joe Touch wrote: > And - IMO - we as a community need to stop giving those who ignore our > policies a mic at IETF meetings. To clarify this - I agree that our mic should be open to all parties that bring us ideas (time permitting). However, I do feel that we have no obligation to *repeatedly* give time to promote ideas that violate Internet practices in ways that harm the rest of us. The first talk is fine, but once a serious issue is raised then that issue needs to be the *focus* of future discussion IMO. This was not the case with the most recent presentation on tcpcrypt at TSVAREA in Quebec (which was presented previously at TCPM in Prague). The slot was 5 minutes in Prague; it was *40* in Quebec. The slides do *not* indicate the TCP option number that they're squatting, or why they don't use the existing experimental codepoints. All the reasons they don't want to use the existing codepoints - BTW - are the same reasons nobody will want to use the codepoints they're squatting on. Joe From wes@mti-systems.com Wed Aug 24 19:17:18 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 088D721F8772 for ; Wed, 24 Aug 2011 19:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4X4K+8+QVetq for ; Wed, 24 Aug 2011 19:17:17 -0700 (PDT) Received: from omr10.networksolutionsemail.com (omr10.networksolutionsemail.com [205.178.146.60]) by ietfa.amsl.com (Postfix) with ESMTP id 1418021F8779 for ; Wed, 24 Aug 2011 19:17:16 -0700 (PDT) Received: from cm-omr3 (mail.networksolutionsemail.com [205.178.146.50]) by omr10.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p7P2IQc4004222 for ; Wed, 24 Aug 2011 22:18:26 -0400 Authentication-Results: cm-omr3 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [174.130.46.7] ([174.130.46.7:24225] helo=[192.168.1.103]) by cm-omr3 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id D8/C9-12447-2F0B55E4; Wed, 24 Aug 2011 22:18:26 -0400 Message-ID: <4E55B0EC.5010701@mti-systems.com> Date: Wed, 24 Aug 2011 22:18:20 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Joe Touch References: <4E49F54C.60200@mti-systems.com> <4AAE62C9-C2E8-4CEF-BB92-3F51DB500104@isi.edu> <4E54DF75.8050902@gont.com.ar> <4E5550DE.4060402@isi.edu> <4E55A348.3050705@isi.edu> In-Reply-To: <4E55A348.3050705@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org, Fernando Gont Subject: Re: [tcpm] proposal for additional experimental-use option kind numbers X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 02:17:18 -0000 On 8/24/2011 9:20 PM, Joe Touch wrote: > > > On 8/24/2011 12:28 PM, Joe Touch wrote: >> And - IMO - we as a community need to stop giving those who ignore our >> policies a mic at IETF meetings. > > To clarify this - I agree that our mic should be open to all parties > that bring us ideas (time permitting). > > However, I do feel that we have no obligation to *repeatedly* give time > to promote ideas that violate Internet practices in ways that harm the > rest of us. The first talk is fine, but once a serious issue is raised > then that issue needs to be the *focus* of future discussion IMO. > > This was not the case with the most recent presentation on tcpcrypt at > TSVAREA in Quebec (which was presented previously at TCPM in Prague). > The slot was 5 minutes in Prague; it was *40* in Quebec. > > The slides do *not* indicate the TCP option number that they're > squatting, or why they don't use the existing experimental codepoints. > All the reasons they don't want to use the existing codepoints - BTW - > are the same reasons nobody will want to use the codepoints they're > squatting on. > I agree with you that it's not something that should be accepted. In the long term, it's a harmful practice. In the case of tcpcrypt, Mark did express regrets and admitted that it was a mistake. He needs to know what the right solution is to correct it, and that's why we're having this discussion, I think. I believe he expressed that his intention was to change to something more acceptable that would also allow their experiment to work. If I'm wrong on this, Mark can correct me. You and I have each proposed some potential solutions. Here are pros and cons, as I see them. Please correct if I misunderstood your proposal (the "nonce approach"): Summary of the nonce approach: - use the 2 existing option kind numbers designated for experiments - add a small "nonce" field to all options using these kinds to uniquely identify them Advantages of nonce approach: - no new kind numbers need to be allocated - might allow new experiments to coexist with existing misuse of the 2 experimental kind numbers Disadvantages of nonce approach: - isn't the nonce really a "sub-kind" field? If so, doesn't it need to be managed by IANA to avoid collisions? This depends on how small the "small" nonce is. If it's too small, then it needs to be coordinated in some way, or we have the same issue - if the nonce isn't small, the already tight options space gets squeezed even more for these experiments; if you use multiple experimental options at once, you pay the tax multiple times - protocols using this might need to remove the nonce if/when they transition away from just being an experiment - depending on size of the nonce, alignment issues may cause extra space for padding to be burnt Summary of draft-eddy-tcpm-addl-exp-options-00: - allocate more experimental options Advantages: - quick, easy - does not impinge on design/layout of options - existing protocols that want to behave can do so right away by change of option kind - avoids any potential conflict with deployed code misusing the existing experimental kinds - compatible with nonce approach for people that want to use it Disadvantages: - burns some more option kinds (analyzed in draft, not really an issue, by my estimation) - some danger of collision if lots of simultaneous experiments are running I think figuring out how to advise the use of nonces is a better long-term solution, but it does require a bit more thought to do correctly and does involve additional "burden" for designers to use it, so we need to think it out correctly. I think to get something reasonable done in the short term (like months) so that we have a reasonable solution for people, that the draft-eddy-... approach is more likely to be able to be worked quickly and applied in code. I think it would be possible to do that, and also work on specifying how to advise to use nonces in parallel, which would "Update" it when published. Thoughts? -- Wes Eddy MTI Systems From christos@zoulas.com Thu Aug 25 00:03:53 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC0B821F8B0D for ; Thu, 25 Aug 2011 00:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UH7--ZhK7YY0 for ; Thu, 25 Aug 2011 00:03:52 -0700 (PDT) Received: from rebar.astron.com (ftp.astron.com [38.117.134.204]) by ietfa.amsl.com (Postfix) with ESMTP id 7357D21F8B08 for ; Thu, 25 Aug 2011 00:03:52 -0700 (PDT) Received: by rebar.astron.com (Postfix, from userid 10080) id F11DF9711B; Thu, 25 Aug 2011 07:05:02 +0000 (UTC) From: christos@zoulas.com (Christos Zoulas) Date: Thu, 25 Aug 2011 03:05:02 -0400 In-Reply-To: <4E5550DE.4060402@isi.edu> from Joe Touch (Aug 24, 12:28pm) Organization: Astron Software X-Mailer: Mail User's Shell (7.2.6 beta(4.pl1)+dynamic 20000103) To: Joe Touch , Fernando Gont Message-Id: <20110825070502.F11DF9711B@rebar.astron.com> Cc: tcpm@ietf.org Subject: Re: [tcpm] proposal for additional experimental-use option kind numbers X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 07:03:54 -0000 On Aug 24, 12:28pm, touch@isi.edu (Joe Touch) wrote: -- Subject: Re: [tcpm] proposal for additional experimental-use option kind n | That cannot be our approach. If it is, I *WILL* deploy code that uses | all remaining option numbers in every protocol I can find, and we'll | have none left for anyone. ;-) | | Seriously, ERRORS ARE ERRORS - they don't define the de-facto standards. | The standard is that these codepoints are not yet assigned, and those | who use them need to STOP. I agree with you but there needs to be a procedure on how to do this instead of fuming in mailing lists. Is there an official channel we can notify the abusers via regular mail (getting lawyers involved) to stop doing that? Giving them time to apply for proper allocations and if approved, shift to them? What power does IETF have to stop the abusers, and if not IETF then who? christos From lars.eggert@nokia.com Thu Aug 25 00:09:16 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1540421F8B0D for ; Thu, 25 Aug 2011 00:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.378 X-Spam-Level: X-Spam-Status: No, score=-103.378 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scea9SFemX08 for ; Thu, 25 Aug 2011 00:09:15 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8D621F8B09 for ; Thu, 25 Aug 2011 00:09:15 -0700 (PDT) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p7P7AKSf005789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Aug 2011 10:10:22 +0300 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.2 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/signed; boundary="Apple-Mail=_7BA597B2-5DC0-4650-B074-D9F1B91A371D"; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <20110825070502.F11DF9711B@rebar.astron.com> Date: Thu, 25 Aug 2011 10:10:17 +0300 Message-Id: <97A54A9E-6BD2-446E-8297-D0134D841B6B@nokia.com> References: <20110825070502.F11DF9711B@rebar.astron.com> To: Christos Zoulas X-Mailer: Apple Mail (2.1244.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.fit.nokia.com); Thu, 25 Aug 2011 10:10:17 +0300 (EEST) X-Nokia-AV: Clean Cc: tcpm@ietf.org, Fernando Gont , Joe Touch Subject: Re: [tcpm] proposal for additional experimental-use option kind numbers X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 07:09:16 -0000 --Apple-Mail=_7BA597B2-5DC0-4650-B074-D9F1B91A371D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2011-8-25, at 10:05, Christos Zoulas wrote: > I agree with you but there needs to be a procedure on how to do > this instead of fuming in mailing lists. Is there an official > channel we can notify the abusers via regular mail (getting lawyers > involved) to stop doing that? Giving them time to apply for proper > allocations and if approved, shift to them? What power does IETF > have to stop the abusers, and if not IETF then who? One approach is to mark code points that are used without proper IANA = assignment in the IANA registries, naming the companies or organizations = involved and making very sure that the language used is clear that this = is highly inappropriate. Lars= --Apple-Mail=_7BA597B2-5DC0-4650-B074-D9F1B91A371D Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDgyNTA3MTAxOFowIwYJKoZIhvcNAQkE MRYEFEIK7q5DodpB6B2Pq7XYtjhXtYsTMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB AKvYXMfQoZnyqtQPxSDBliunpx7pHWtrJELSM8vCKYtDj11dp2CgapX8dHRilXlw1hPInjnlf6S0 g1a5F+tZxoOFFTDX6G7dYUWZEeuZzrh1s31s3zdD4iV+qWKbGRVVvOivwtSPOj+m8EVrAdbKKp9h GlvWct+WDja/hcwsVxwiPdUrJAbp6yW1sg9elrhyDvzUSwNtNpddA5thu9M5Xi5XJIxLtSUCvP9W h+YiZZ/BVs1TX0a/cd3CjkzAK/hfUz6Jfy4zrqWPPrqvHx4XVWE+2VS5poBmqsi0QiDq3yRb2qhf MGT/LpbyPIoIGcPMyg8xIW8mZybyE+xJ2JOfI/kAAAAAAAA= --Apple-Mail=_7BA597B2-5DC0-4650-B074-D9F1B91A371D-- From touch@isi.edu Thu Aug 25 09:16:04 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89A5C21F852C for ; Thu, 25 Aug 2011 09:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.654 X-Spam-Level: X-Spam-Status: No, score=-102.654 tagged_above=-999 required=5 tests=[AWL=-1.295, BAYES_00=-2.599, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id du2FjxWZWvWl for ; Thu, 25 Aug 2011 09:16:03 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id DE07521F851A for ; Thu, 25 Aug 2011 09:16:03 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p7PGGZqX005381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 25 Aug 2011 09:16:35 -0700 (PDT) Message-ID: <4E567563.10006@isi.edu> Date: Thu, 25 Aug 2011 09:16:35 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Wesley Eddy References: <4E49F54C.60200@mti-systems.com> <4AAE62C9-C2E8-4CEF-BB92-3F51DB500104@isi.edu> <4E54DF75.8050902@gont.com.ar> <4E5550DE.4060402@isi.edu> <4E55A348.3050705@isi.edu> <4E55B0EC.5010701@mti-systems.com> In-Reply-To: <4E55B0EC.5010701@mti-systems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Fernando Gont Subject: Re: [tcpm] proposal for additional experimental-use option kind numbers X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 16:16:04 -0000 Hi, Wes, On 8/24/2011 7:18 PM, Wesley Eddy wrote: ... > In the case of tcpcrypt, Mark did express regrets and admitted that > it was a mistake. He needs to know what the right solution is to > correct it, and that's why we're having this discussion, I think. Step 1 - pull the code off the website. See below for further impact. ... > You and I have each proposed some potential solutions. > > Here are pros and cons, as I see them. Please correct if I > misunderstood your proposal (the "nonce approach"): > > Summary of the nonce approach: > - use the 2 existing option kind numbers designated for experiments > - add a small "nonce" field to all options using these kinds to > uniquely identify them > > Advantages of nonce approach: > - no new kind numbers need to be allocated > - might allow new experiments to coexist with existing misuse of > the 2 experimental kind numbers > > Disadvantages of nonce approach: > - isn't the nonce really a "sub-kind" field? If so, doesn't it > need to be managed by IANA to avoid collisions? This depends > on how small the "small" nonce is. If it's too small, then it > needs to be coordinated in some way, or we have the same issue > - if the nonce isn't small, the already tight options space gets > squeezed even more for these experiments; if you use multiple > experimental options at once, you pay the tax multiple times > - protocols using this might need to remove the nonce if/when > they transition away from just being an experiment > - depending on size of the nonce, alignment issues may cause > extra space for padding to be burnt The nonce should be at least 32 bits, and I would think that would be sufficient. It can then be selected either randomly or by the user via, e.g., systime() when the experimenter wants to self-assign a value. I'm willing to bet that this is sufficient for a while ;-) If a registry is desired, experimenters can verify their chosen value is collision-free and provide a pointer to IANA. IANA would just accept values FCFS. A 32-bit nonce cannot be an impediment to a serious experiment, since we need to expect that experiments are never the only option in use, and that they would never consume ALL remaining option space. Even the smallest options consume 2 bytes, so this allows at least two more options beyond the experiment, which is a reasonable expectation IMO. In fact, here's what I'd propose: +--------+--------+--------+--------+ | KIND | LEN | (available) | +--------+--------+--------+--------+ | NONCE | +--------+--------+--------+--------+ | (available - con't if needed)... | This is 32-bit aligned, and already provides 2 bytes for experiments. Implementations MUST check the NONCE *first* before examining any available space before or after the NONCE. IF there is concern that the existing two codepoints (255, 254) are 'tainted' by the Cisco/Juniper/Alcatel deployed proposed TCP authentication alternative, then we can assign two more codepoints, and declare that they MUST use nonces. > Summary of draft-eddy-tcpm-addl-exp-options-00: > - allocate more experimental options > > Advantages: > - quick, easy > - does not impinge on design/layout of options > - existing protocols that want to behave can do so right away by > change of option kind > - avoids any potential conflict with deployed code misusing the > existing experimental kinds > - compatible with nonce approach for people that want to use it > > Disadvantages: > - burns some more option kinds (analyzed in draft, not really > an issue, by my estimation) > - some danger of collision if lots of simultaneous experiments > are running This provides a hazard that just kicks the problem down the road. If nonces aren't required now, then the options assigned this way are tainted exactly as are 255/254 (and Mark has tainted 69/70). > I think figuring out how to advise the use of nonces is a better > long-term solution, but it does require a bit more thought to do > correctly and does involve additional "burden" for designers to use > it, so we need to think it out correctly. I can't see the complexity here; see above. > I think to get something reasonable done in the short term (like > months) so that we have a reasonable solution for people, Anyone who is *serious* about this problem would take down code that needed fixing, or just shift to using the existing experimental codepoints (255/254), rather than putting the onus on us to find a quick fix. > that the > draft-eddy-... approach is more likely to be able to be worked > quickly and applied in code. I think it would be possible to do > that, and also work on specifying how to advise to use nonces in > parallel, which would "Update" it when published. See above; we can't UPDATE tainted option values. Once we cannot control the nonce field values (e.g., when they contain a MAC), the option values are dead. I don't think we should be assigning MORE options that we know are going to die. Time to fix this, and I think the nonce solution is VERY simple. Joe From rick.jones2@hp.com Fri Aug 26 11:59:57 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81B5F21F8C20 for ; Fri, 26 Aug 2011 11:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nE3otfaeGEUH for ; Fri, 26 Aug 2011 11:59:56 -0700 (PDT) Received: from g1t0026.austin.hp.com (g1t0026.austin.hp.com [15.216.28.33]) by ietfa.amsl.com (Postfix) with ESMTP id B018321F8BD5 for ; Fri, 26 Aug 2011 11:59:56 -0700 (PDT) Received: from g1t0038.austin.hp.com (g1t0038.austin.hp.com [16.236.32.44]) by g1t0026.austin.hp.com (Postfix) with ESMTP id 6BA06C0AC for ; Fri, 26 Aug 2011 19:01:13 +0000 (UTC) Received: from [16.89.244.213] (tardy.cup.hp.com [16.89.244.213]) by g1t0038.austin.hp.com (Postfix) with ESMTP id 2604A30267 for ; Fri, 26 Aug 2011 19:01:13 +0000 (UTC) Message-ID: <4E57ED78.9070600@hp.com> Date: Fri, 26 Aug 2011 12:01:12 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [tcpm] feedback on WG adoption of draft-cheng-tcpm-fastopen-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 18:59:57 -0000 I've been meaning to get this out for some time but "other things" have kept getting in the way. Anyhow, at the highest level I find the draft useful and think it would be a worthwhile WG item. Getting a bit lower, some comments/questions, one or two of which stray beyond the specifics of the draft and might be philosophical, but are triggered by it. *) Just how many more angelic options can dance on the header of the TCP SYN? How many options being present nearly all the time call for a revision of the standard header (Yes, that is an intractable Layer 8 and 9 issue but still...). *) MSS, Window Scale, Timestamp, SACK OK are all quite desirable no? We want to avoid the dreaded 536 byte MSS, handle bandwidth delay products beyond the limit of a 64K window, not corrupt data when we do so, and be able to quickly recover from the inevitable segment losses while we do so - not just in the interests of bandwidth, but in the interests of time. IIRC that is 2 + 3 + 10 + 2 or 17 bytes of option space in the SYN (assuming fully packed). 40 bytes of option space is the limit no? Section 4.1.1 of the draft talks about the cookie being up to 16 bytes in size, consuming a total of 18 bytes of option space. So, I suppose that doesn't completely consume the option space, but it starts to look pretty full - only 5 bytes left, perhaps only 4 depending on option alignment. How would one prioritize the cookie vs the other options once options space was exhausted? Section 4.2.2 makes a passing mention of forgoing TFO but expanding on that would be goodness. *) Section 2.1 mentions that TFO must be disabled by default and only enabled explicitly by applications which want it and can tolerate the prospect of duplicate SYN data. If it is inappropriate to include discussion of the mechanism in the "protocol" draft (perhaps as an appendix), is there another draft with a proposed interface for this enabling? *) Section 4.2.1 gives an example of AES_128 for generating the cookie and says it takes "only a few hundred nanoseconds." I think it would be goodness to be a bit more specific, and perhaps include some contemporary service demands for TCP connection establishment. Particularly since a TCP SYN with the cookie request could arrive every 68 nanoseconds through a 10GbE pipe into the server, and since 40 and 100 GbE are virtually upon us. More specific numbers for validating cookies up to 16 bytes would be goodness as well. *) Doesn't Section 4.2.2 (or some other) need to specify what should happen when a TCP SYN with a TFO cookie arrives at an endpoint where the application has not explicitly enabled TFO? Particularly since the cache of cookies is per-IP and not per IP-port-pair? A restart of the server application could change the setting while there was still an entry cached in the client(s). Unless automagically generating a new cookie upon receipt of an invalid one is dropped, presumably the behaviour of the server would be slightly different in that it would drop the cookie and not make a new one, as there is no point. I suppose for (pedantic?) completeness, explicitly stating what a client should do when it receives an unexpected cookie could be included as well. *) Given the ability to spoof IP addresses, I think the order of server processing given in 4.2.2 " Server: Receiving SYN and responding with SYN-ACK" should be changed. PendingFastOpenRequests should be checked first, before even attempting to validate the cookie. Further, until cookie generation is shown to indeed be epsilon compared to the rest of TCP connection establishment on the server, the server should not include a new cookie when the cookie was invalid and instead require the client to make another "from scratch" cookie request. Also, given that the application isn't notified until step 4, "The server MAY include data in the SYN-ACK packet (sic pedant mode, TCP sends segments not packets)" in step 3 seems out of place unless we are assuming there are applications which will use this that want data sent before receiving anything, in which case that is another bit of user interface to describe somewhere. *) 4.1.3 reads "Beside the cookie, we RECOMMEND that the client caches the MSS and RTT to the server to enhance performance." Should that be the MSS as based (possibly) on later PMTU events during the life of the connection? Meaning going to the cache not just on connection establishment, but also when there is a PTMU event. *) 4.1.3 reads "For a multi-homed client, the cookies are both client and server IP dependent." I ass-u-me that means they should be cached based on both client and server IP. That is I suppose implicit with cookies being generated by servers but it rarely hurts to be explicit. However, why does it have to be client,server IP at the client? Particularly since section 4.1.2 point 5 says a client only needs to remember one valid cookie per server IP? And if the client is only going to remember one, to what end would a server produce multiple cookies per client? *) 4.1.3 "The client MUST cache cookies from different servers for later..." - isn't "different" somewhat redundant? happy benchmarking, rick jones From gettysjim@gmail.com Fri Aug 26 12:24:31 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC3E21F8CA2; Fri, 26 Aug 2011 12:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.392 X-Spam-Level: X-Spam-Status: No, score=-3.392 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcwC4tCrsJM3; Fri, 26 Aug 2011 12:24:30 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 997DF21F8C9D; Fri, 26 Aug 2011 12:24:30 -0700 (PDT) Received: by vxi29 with SMTP id 29so3601367vxi.31 for ; Fri, 26 Aug 2011 12:25:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :subject:content-type; bh=tuZbbCZp88AqwkoSNZlxY5egpu4raKeLuNbbMNiW8wk=; b=utKK0JsmMr8Fn310G/4HeMvLH9yliim0c8IKQiOc7qqdc9MMVmyukjj7O5zFy6YD7D dlneVh3DfMPMIHDNaJkwKykmvGPu331HsOmKhi6zYTLh07Ei3gip0TAUsf4W55HcNE6B 5m9UP9c3H/LpsRxyNOTqTIQ76ZOLD99hztA3c= Received: by 10.52.185.135 with SMTP id fc7mr1686916vdc.133.1314386746959; Fri, 26 Aug 2011 12:25:46 -0700 (PDT) Received: from [192.168.1.108] (c-24-218-177-117.hsd1.ma.comcast.net [24.218.177.117]) by mx.google.com with ESMTPS id u3sm892177vcc.19.2011.08.26.12.25.45 (version=SSLv3 cipher=OTHER); Fri, 26 Aug 2011 12:25:45 -0700 (PDT) Sender: Jim Gettys Message-ID: <4E57F338.4080306@freedesktop.org> Date: Fri, 26 Aug 2011 15:25:44 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110627 Thunderbird/5.0 MIME-Version: 1.0 To: tcpm@ietf.org, HTTP working group , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="------------030706020008030602050405" Subject: [tcpm] IW10 Considered Harmful X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 19:24:32 -0000 This is a multi-part message in MIME format. --------------030706020008030602050405 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I just submitted draft-gettys-iw10-considered-harmful-00 http://www.ietf.org/id/draft-gettys-iw10-considered-harmful-00.txt It is commenting on the proposal in http://datatracker.ietf.org/doc/draft-ietf-tcpm-initcwnd/ which would change the TCP initial window from 4 packets to 10. I believe this would be a serious mistake compounding problems already present for low latency applications, for the reasons outlined in my draft. Best regards, Jim Gettys Abstract The proposed change to the initial window to 10 indraft-ietf-tcpm- initcwnd must be considered deeply harmful; not because it is the proposed change is evil taken in isolation, but that other changes in web browsers and web sites that have occurred over the last decade, it makes the problem of transient congestion at a user's broadband connection two and a half times worse. This result has been hidden by the already widespread bufferbloat present in broadband connections. Packet loss in isolation is no longer a useful metric of a path's quality. The very drive to improve latency of web page rendering is already destroying other low latency applications, such as VOIP and gaming, and will prevent reliable rich web real time web applications such as those contemplated by the IETF rtcweb working group. --------------030706020008030602050405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I just submitted draft-gettys-iw10-considered-harmful-00

http://www.ietf.org/id/draft-gettys-iw10-considered-harmful-00.txt

It is commenting on the proposal in
http://datatracker.ietf.org/doc/draft-ietf-tcpm-initcwnd/
which would change the TCP initial window from 4 packets to 10.

I believe this would be a serious mistake compounding problems already present
for low latency applications, for the reasons outlined in my draft.
                    Best regards,
                                Jim Gettys



                        Abstract

The proposed change to the initial window to 10 indraft-ietf-tcpm-
initcwnd must be considered deeply harmful; not because it is the
proposed change is evil taken in isolation, but that other changes in
web browsers and web sites that have occurred over the last decade,
it makes the problem of transient congestion at a user's broadband
connection two and a half times worse. This result has been hidden
by the already widespread bufferbloat present in broadband
connections. Packet loss in isolation is no longer a useful metric
of a path's quality. The very drive to improve latency of web page
rendering is already destroying other low latency applications, such
as VOIP and gaming, and will prevent reliable rich web real time web
applications such as those contemplated by the IETF rtcweb working
group. --------------030706020008030602050405-- From hkchu@google.com Fri Aug 26 21:06:32 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A3421F8779 for ; Fri, 26 Aug 2011 21:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.527 X-Spam-Level: X-Spam-Status: No, score=-105.527 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nqMzIUhof+v for ; Fri, 26 Aug 2011 21:06:31 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 962E621F8772 for ; Fri, 26 Aug 2011 21:06:31 -0700 (PDT) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id p7R47m4M013359 for ; Fri, 26 Aug 2011 21:07:48 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314418069; bh=In2hWcl+99WkQHJ1BtGFS/Phx7g=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=bTnBD2vkP+kvpxwJgsRbRWIBzc2qKfOpA9Sjz5bcUIAI+TNvq+7QRC+rDN7vw6Gtr 4+TWYaw+Kziq21XBsfqQg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=fZcqODHPtafWonFtkh0wzOX4NUuGua66A+aRIBGoT1wizSYTQ39kA4LSLIApwM6kH WCovHEFZweODEM2H8lfGA== Received: from gyh3 (gyh3.prod.google.com [10.243.50.195]) by hpaq14.eem.corp.google.com with ESMTP id p7R47kNa008985 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 26 Aug 2011 21:07:47 -0700 Received: by gyh3 with SMTP id 3so3801641gyh.37 for ; Fri, 26 Aug 2011 21:07:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Enf2zS0kkISPIh8uJPivtKCAdYyEIjgbg+h8AHjFrdc=; b=ibDvLdFvODK7ExeccAymUFf+nqTOnI1iwtQzhajX3Yp278Bt68x467u+fHgjbkMI4T 8oYqoSg1CM5BBkfLcAvw== Received: by 10.150.179.10 with SMTP id b10mr2725961ybf.408.1314418066142; Fri, 26 Aug 2011 21:07:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.179.10 with SMTP id b10mr2725957ybf.408.1314418065987; Fri, 26 Aug 2011 21:07:45 -0700 (PDT) Received: by 10.151.109.17 with HTTP; Fri, 26 Aug 2011 21:07:45 -0700 (PDT) In-Reply-To: <4E57ED78.9070600@hp.com> References: <4E57ED78.9070600@hp.com> Date: Fri, 26 Aug 2011 21:07:45 -0700 Message-ID: From: Jerry Chu To: Rick Jones Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: tcpm@ietf.org Subject: Re: [tcpm] feedback on WG adoption of draft-cheng-tcpm-fastopen-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2011 04:06:32 -0000 Hi Rick, Thanks for you thoughtful input. My comments are embedded below. On Fri, Aug 26, 2011 at 12:01 PM, Rick Jones wrote: > I've been meaning to get this out for some time but "other things" have k= ept > getting in the way. > > Anyhow, at the highest level I find the draft useful and think it would b= e a > worthwhile WG item. > > Getting a bit lower, some comments/questions, one or two of which stray > beyond the specifics of the draft and might be philosophical, but are > triggered by it. > > *) Just how many more angelic options can dance on the header of the TCP > SYN? =A0How many options being present nearly all the time call for a rev= ision > of the standard header (Yes, that is an intractable Layer 8 and 9 issue b= ut > still...). Yes it seems that this option space problem will one day become the choke p= oint for all future TCP innovations... That's why we've carefully evaluated the tradeoff between the security risk= vs cookie size and decided cookies as small as 4 bytes may be sufficient for s= ome cases/implementations..., etc. We've even wondered if cookies can be made optional (or treated as the degenerate case of server advertising a zero-le= nghth cookie) for some cases where the major security risk for TFO, i.e., the reflection attack, does not exist. (See http://www.ietf.org/proceedings/81/slides/tcpm-0.pdf.) > > *) MSS, Window Scale, Timestamp, SACK OK are all quite desirable no? =A0W= e > want to avoid the dreaded 536 byte MSS, handle bandwidth delay products > beyond the limit of a 64K window, not corrupt data when we do so, and be > able to quickly recover from the inevitable segment losses while we do so= - > not just in the interests of bandwidth, but in the interests of time. =A0= IIRC > that is 2 + 3 + 10 + 2 or 17 bytes of option space in the SYN (assuming > fully packed). =A040 bytes of option space is the limit no? Correct and since we believe the potential damage from an amplified reflect= ion attack is somewhat limited we do not suggest an insanely large cookie size hence all our suggested sizes fit together with other, existing commonly us= ed options. Yes going forward will be an issue but it's a general issue not li= mited to TFO that needs to be addressed separately. > > Section 4.1.1 of the draft talks about the cookie being up to 16 bytes in > size, consuming a total of 18 bytes of option space. So, I suppose that > doesn't completely consume the option space, but it starts to look pretty > full - only 5 bytes left, perhaps only 4 depending on option alignment. = =A0How > would one prioritize the cookie vs the other options once options space w= as > exhausted? =A0Section 4.2.2 makes a passing mention of forgoing TFO but > expanding on that would be goodness. Sure and we've already come across that problem when trying to enable the TCP MD5 options internally. >From the top of my head that could be an deployment decision. Each site wil= l need to prioritize their option preference but unfortunately options are initiated by the client side... Sigh (a train wreck is bound to happen). > > *) Section 2.1 mentions that TFO must be disabled by default and only > enabled explicitly by applications which want it and can tolerate the > prospect of duplicate SYN data. =A0If it is inappropriate to include > discussion of the mechanism in the "protocol" draft (perhaps as an > appendix), is there another draft with a proposed interface for this > enabling? Well, the obvious candidate for interface is socket option, right? Years ago IETF shunned any API discussion. But I guess that have changed with IPng and SCTP. (?) If so we can publish a separate draft on our proposed API. I have presented part of it in Quebec City. > > *) Section 4.2.1 gives an example of AES_128 for generating the cookie an= d > says it takes "only a few hundred nanoseconds." =A0I think it would be > goodness to be a bit more specific, and perhaps include some contemporary > service demands for TCP connection establishment. Particularly since a TC= P > SYN with the cookie request could arrive every 68 nanoseconds through a > 10GbE pipe into the server, and since 40 and 100 GbE are virtually upon u= s. > =A0More specific numbers for validating cookies up to 16 bytes would be > goodness as well. We have actually done some study on the server cookie processing overhead and will revise the draft with the data once we are cleared for publication= . In our test the # of sustained HTTP transaction rate was higher with TFO than = w/o. We attributed this to the fact that the reduced in pkt count (due to carryi= ng data in SYN) from TFO and its CPU saving more than compensating for the extra CPU processing cost from AES_128. > > *) Doesn't Section 4.2.2 (or some other) need to specify what should happ= en > when a TCP SYN with a TFO cookie arrives at an endpoint where the > application has not explicitly enabled TFO? =A0Particularly since the cac= he of > cookies is per-IP and not per IP-port-pair? =A0A restart of the server > application could change the setting while there was still an entry cache= d > in the client(s). =A0Unless automagically generating a new cookie upon re= ceipt > of an invalid one is dropped, presumably the behaviour of the server woul= d > be slightly different in that it would drop the cookie and not make a new > one, as there is no point. Yes TFO is negotiated implicitly by client including a cookie option and th= e server acknowledging explicitly the cookie option (by either acking the dat= a in SYN or replying with a new cookie). All other cases will cause TFO to be disabled. So if the listening app has not enabled TFO, TCP won't reply with a cookie option nor acking the data in the SYN pkt. There is probably some details on how often the client wants to refresh the cookie cache etc but some of them can be left to the implementation. One assumption we've made is the cookie generation is cheap. Otherwise it'd open up for another form of burning server CPU attack. > > I suppose for (pedantic?) completeness, explicitly stating what a client > should do when it receives an unexpected cookie could be included as well= . I don't remember we allow this case, i.e., "unexpected" cookie option recei= ved by the client will be treated as an unrecognized TCP option. > > *) Given the ability to spoof IP addresses, I think the order of server > processing given in 4.2.2 " Server: Receiving SYN and responding with > SYN-ACK" should be changed. PendingFastOpenRequests should be checked > first, before even attempting to validate the cookie. Aha, you've caught some good corner case. It think my colleague wrote in th= at order because not replying a cookie nor acking the data will be treated by the client as the server disabling/de-supporting TFO. But I'm sure we can further fine= tune the cookie protocol to address any ambiguity and performance optimization. >Further, until cookie > generation is shown to indeed be epsilon compared to the rest of TCP > connection establishment on the server, the server should not include a n= ew > cookie when the cookie was invalid and instead require the client to make > another "from scratch" cookie request. Yes we've thought about these performance issues and have gone through a few rounds of the seemingly simple cookie protocol design cycle. But I'm no= t sure your suggested "from scratch" approach will help much to defend agains= t a malicious client if the cookie generation is expensive. I think it boils down to as long as the cookie generation is no more expensive than the processing overhead of a SYN pkt (upto checking the listener's qlimit), this case is n= o worse than the SYN attack. > > Also, given that the application isn't notified until step 4, "The server > MAY include data in the SYN-ACK packet (sic =A0pedant mode, TCP sends seg= ments > not packets)" The draft was written for those majority, non-pedantic audience, who might = not appreciate the subtle difference between "segments" and "packets" :) >in step 3 seems out of place unless we are assuming there are > applications which will use this that want data sent before receiving > anything, in which case that is another bit of user interface to describe > somewhere. No, this is more like the regular delayed ack case when the SYN-ACK is delayed giving the app some time to respond. (Remember TFO will send up the data included in the SYN pkt right away before the final ack.) > > *) 4.1.3 reads "Beside the cookie, we RECOMMEND that the client caches th= e > MSS and RTT to the server to enhance performance." =A0Should that be the = MSS > as based (possibly) on later PMTU events during the life of the connectio= n? > =A0Meaning going to the cache not just on connection establishment, but a= lso > when there is a PTMU event. Sure. > > *) 4.1.3 reads "For a multi-homed client, the cookies are both client and > server IP dependent." =A0I ass-u-me that means they should be cached base= d on > both client and server IP. =A0That is I suppose implicit with cookies bei= ng > generated by servers but it rarely hurts to be explicit. However, why doe= s > it have to be client,server IP at the client? Well for a multi-homed client it needs to pick cookies based on client & se= rver IP. (Maybe I've missed your question?) >Particularly since section > 4.1.2 point 5 says a client only needs to remember one valid cookie per > server IP? I guess you may have quoted the above out of context. The full text is "5. A server may encode other information in the cookie, and allow more than one valid cookie per client at any given time. But this is all server implementation dependent and transparent to the client. A client only needs to remember one valid cookie per server IP." The last sentence can be considered redundant. >And if the client is only going to remember one, to what end > would a server produce multiple cookies per client? There was some usage case where the server could encode more info than just client IP address in the cookie (if one picks a large cookie size= ). But you are right if our cookie protocol implicitly allows only one valid cookie visible to the client then I don't see/remember why server would allow multiple valid cookies per client. Will defer this to my colleagues. > > *) 4.1.3 "The client MUST cache cookies from different servers for later.= .." > - isn't "different" somewhat redundant? It looks like the whole sentence is redundant. > Thanks again, Jerry > happy benchmarking, > > rick jones > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From rick.jones2@hp.com Mon Aug 29 15:35:00 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D3121F8C69 for ; Mon, 29 Aug 2011 15:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urxBH5G19-fi for ; Mon, 29 Aug 2011 15:34:59 -0700 (PDT) Received: from g4t0014.houston.hp.com (g4t0014.houston.hp.com [15.201.24.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1A721F8C71 for ; Mon, 29 Aug 2011 15:34:59 -0700 (PDT) Received: from g4t0018.houston.hp.com (g4t0018.houston.hp.com [16.234.32.27]) by g4t0014.houston.hp.com (Postfix) with ESMTP id 25254244C3; Mon, 29 Aug 2011 22:36:25 +0000 (UTC) Received: from [16.89.244.213] (tardy.cup.hp.com [16.89.244.213]) by g4t0018.houston.hp.com (Postfix) with ESMTP id CCF1A100FC; Mon, 29 Aug 2011 22:36:24 +0000 (UTC) Message-ID: <4E5C1465.9050907@hp.com> Date: Mon, 29 Aug 2011 15:36:21 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110805 Lightning/1.0b2 Thunderbird/3.1.12 MIME-Version: 1.0 To: Jerry Chu References: <4E57ED78.9070600@hp.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org Subject: Re: [tcpm] feedback on WG adoption of draft-cheng-tcpm-fastopen-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 22:35:01 -0000 going through the draft again while composing this some new stuff: *) section 2.1 - probably better to say ""i.e., to restrict TFO to a class of applications that are tolerant" >> *) Just how many more angelic options can dance on the header of the TCP >> SYN? How many options being present nearly all the time call for a revision >> of the standard header (Yes, that is an intractable Layer 8 and 9 issue but >> still...). > > Yes it seems that this option space problem will one day become the choke point > for all future TCP innovations... > > That's why we've carefully evaluated the tradeoff between the security risk vs > cookie size and decided cookies as small as 4 bytes may be sufficient for some > cases/implementations..., etc. We've even wondered if cookies can be made > optional (or treated as the degenerate case of server advertising a zero-lenghth > cookie) for some cases where the major security risk for TFO, i.e., > the reflection > attack, does not exist. (See > http://www.ietf.org/proceedings/81/slides/tcpm-0.pdf.) Slide five makes it sound like the definition of an amplification attack is one where what is emitted is more than one packet's worth of data. I do not think that is correct. Going well back in time, there was the issue of the way that the HP-UX (and I believe Solaris and a given version of Mac OS, all of which had a stack with a common ancestor) did PathMTU discovery - by sending a full link-local MTU ICMP echo request with the DF bit set in parallel with its attempted response to the remote IP, with the DF bit cleared. (The idea was to find the PathMTU without incurring the requisite packet loss on the data that "mattered") This was an amplification attack which sent only one packet. And only needed a small inbound packet to trigger it. As such, I don't think that one can avoid the taste of cookies if the server is to send data back before the 3WHS is complete. Slide nine - presumably the client side will also employ the "TCP_TFO" option. Slide 10 - what about server processing overhead in addition to latency. The slide almost suggests that rather than teach them to eat cookies, we want give applications/stacks further incentives to keep warm - say with a blanket :) Slide 12 - if the bufferbloat guys are "successful" where will RTTs be - will they be in the 200ms range from whcih the 41% claim comes or will it be closer to 100ms? Also, those whole pages - is the w/ and w/o TFO based on IW3 or IW10? And another question - is there a great deal of connection serialization there - the 200ms RTT example for the wikipedia page shows saving > 2 seconds. TFO gets rid of one RTT at the beginning of a connection, so that page had 10, serial TCP connections established to load it??? That seems as much a critique of the page design of the TCP wikipedia page as anything else given that the other three sites shown saw much less benefit. Is there any way to separate "fundamential" serialization from "bad design?" I like the idea of speeding things up, but I want to make certain that TFO isn't abused the way TCP_NODELAY can be. >> *) MSS, Window Scale, Timestamp, SACK OK are all quite desirable no? We >> want to avoid the dreaded 536 byte MSS, handle bandwidth delay products >> beyond the limit of a 64K window, not corrupt data when we do so, and be >> able to quickly recover from the inevitable segment losses while we do so - >> not just in the interests of bandwidth, but in the interests of time. IIRC >> that is 2 + 3 + 10 + 2 or 17 bytes of option space in the SYN (assuming >> fully packed). 40 bytes of option space is the limit no? > > Correct and since we believe the potential damage from an amplified reflection > attack is somewhat limited we do not suggest an insanely large cookie size > hence all our suggested sizes fit together with other, existing commonly used > options. Yes going forward will be an issue but it's a general issue not limited > to TFO that needs to be addressed separately. Though concurrently. Leaving that to the next poor schmuck who needs 6 bytes of option space doesn't seem all that, well, polite. Pitty we cannot smash several common TCP options together into one uber-option... or can we? Just how random does the initial timestamp *have* to be? But perhaps I digress... >> Section 4.1.1 of the draft talks about the cookie being up to 16 bytes in >> size, consuming a total of 18 bytes of option space. So, I suppose that >> doesn't completely consume the option space, but it starts to look pretty >> full - only 5 bytes left, perhaps only 4 depending on option alignment. How >> would one prioritize the cookie vs the other options once options space was >> exhausted? Section 4.2.2 makes a passing mention of forgoing TFO but >> expanding on that would be goodness. > > Sure and we've already come across that problem when trying to enable the > TCP MD5 options internally. > > From the top of my head that could be an deployment decision. Each site will > need to prioritize their option preference but unfortunately options > are initiated by the client side... Sigh (a train wreck is bound to happen). All the more reason to describe why TCP option A is higher priority than TCP option B. So when the trains do wreck it will be possible to point-out that it could have been avoided - well assuming that the advice would have prevented it :) >> *) Section 4.2.1 gives an example of AES_128 for generating the cookie and >> says it takes "only a few hundred nanoseconds." I think it would be >> goodness to be a bit more specific, and perhaps include some contemporary >> service demands for TCP connection establishment. Particularly since a TCP >> SYN with the cookie request could arrive every 68 nanoseconds through a >> 10GbE pipe into the server, and since 40 and 100 GbE are virtually upon us. >> More specific numbers for validating cookies up to 16 bytes would be >> goodness as well. > > We have actually done some study on the server cookie processing overhead > and will revise the draft with the data once we are cleared for publication. In > our test the # of sustained HTTP transaction rate was higher with TFO than w/o. > We attributed this to the fact that the reduced in pkt count (due to carrying > data in SYN) from TFO and its CPU saving more than compensating for the > extra CPU processing cost from AES_128. I don't doubt that in the "good" case that sustained transaction rate would be higher. If it weren't I suspect we wouldn't be discussing TFO in the first place :) I'm wondering about the attack case, when the attacker is sending SYN segments with bogus cookies, or even just cookie requests, all from spoofed IPs. That is a case where TFO does not reduce the number of segments sent, but does increase the processing overhead. Particularly if the specified behaviour ends-up being to treat an invalid cookie as an implicit cookie request. Yes, that is what the global counter is all about, but once that counter is reached, the server is forced to fall-back on pre-TFO behaviour, which means that server operators are going to want to make that limit rather high. An invalid cookie is Really Cheap (tm) to bake. Ten years ago I would have called worrying about the attack case an example of optimizing for the non-expected case, but today it seems that attacks are to be expected. :( > >> >> *) Doesn't Section 4.2.2 (or some other) need to specify what should happen >> when a TCP SYN with a TFO cookie arrives at an endpoint where the >> application has not explicitly enabled TFO? Particularly since the cache of >> cookies is per-IP and not per IP-port-pair? A restart of the server >> application could change the setting while there was still an entry cached >> in the client(s). Unless automagically generating a new cookie upon receipt >> of an invalid one is dropped, presumably the behaviour of the server would >> be slightly different in that it would drop the cookie and not make a new >> one, as there is no point. > > Yes TFO is negotiated implicitly by client including a cookie option and the > server acknowledging explicitly the cookie option (by either acking the data in > SYN or replying with a new cookie). All other cases will cause TFO to > be disabled. > So if the listening app has not enabled TFO, TCP won't reply with a > cookie option nor acking the data in the SYN pkt. > > There is probably some details on how often the client wants to > refresh the cookie cache etc but some of them can be left to the implementation. I would think that if the client is caching effective MSS with the cookie, then it should be on a timescale matching that of the cache of discovered PathMTUs. >> *) Given the ability to spoof IP addresses, I think the order of server >> processing given in 4.2.2 " Server: Receiving SYN and responding with >> SYN-ACK" should be changed. PendingFastOpenRequests should be checked >> first, before even attempting to validate the cookie. > > Aha, you've caught some good corner case. It think my colleague wrote > in that order because not replying a cookie nor acking the data will > be treated by the client as the server disabling/de-supporting TFO. > But I'm sure we can further fine tune the cookie protocol to address > any ambiguity and performance optimization. Unless the client side is caching a "negative response," which I don't recall the draft suggesting, the next connection attempt to the server by a TFO-enabling application on that client will naturally attempt to get a cookie again anyway right? I don't think you need to address it. >> Further, until cookie generation is shown to indeed be epsilon >> compared to the rest of TCP connection establishment on the >> server, the server should not include a new cookie when the cookie >> was invalid and instead require the client to make another "from >> scratch" cookie request. > > Yes we've thought about these performance issues and have gone > through a few rounds of the seemingly simple cookie protocol design > cycle. But I'm not sure your suggested "from scratch" approach will > help much to defend against a malicious client if the cookie > generation is expensive. I think it boils down to as long as the > cookie generation is no more expensive than the processing overhead > of a SYN pkt (upto checking the listener's qlimit), this case is no > worse than the SYN attack. Cookie generation, no matter how cheap, is still more than the server was doing on each SYN before no? The calculus seems to be that the savings from avoiding an RTT (not simply avoiding packets - at least some of that could come from merely accepting data on the SYN and awaiting the 3WHS) is going to out-weigh what happens when under attack. Presumably, an attacker seeking to extract maximum effect on the server is going to send streams of SYN segments with a bogus cookie and no more than one byte of data. That will maximize his send rate and effect on the server. Adding the cookie to the SYN only costs the attacker a tenth of a nanosecond of transmission time per 10 bits at the server's 10GbE pipe, a cost that is going down all the time as servers get fatter pipes but it costs the server however many nanoseconds it takes to invalidate the cookie. Attackers will almost always have more client systems than the good guys have servers no? >> Also, given that the application isn't notified until step 4, "The server >> MAY include data in the SYN-ACK packet (sic pedant mode, TCP sends segments >> not packets)" > > The draft was written for those majority, non-pedantic audience, who might not > appreciate the subtle difference between "segments" and "packets" :) Never underestimate the value of pedantry in matters of details :) >> in step 3 seems out of place unless we are assuming there are >> applications which will use this that want data sent before receiving >> anything, in which case that is another bit of user interface to describe >> somewhere. > > No, this is more like the regular delayed ack case when the SYN-ACK is > delayed giving the app some time to respond. (Remember TFO will send up > the data included in the SYN pkt right away before the final ack.) I guess it is a good thing that the delayed ACK timer would not be started until after the cookie was known to be valid, or the time for that would have to be added into the calculus too :) >> *) 4.1.3 reads "For a multi-homed client, the cookies are both client and >> server IP dependent." I ass-u-me that means they should be cached based on >> both client and server IP. That is I suppose implicit with cookies being >> generated by servers but it rarely hurts to be explicit. However, why does >> it have to be client,server IP at the client? > > Well for a multi-homed client it needs to pick cookies based on client& server > IP. (Maybe I've missed your question?) No, I simply missed the point. I was going to ask about NAT, but found section 5. However, when that section says that there is no performance penalty it points towards "Client receiving SYN-ACK" - my pedantic :) search didn't find that, but I did find "Client: Receiving SYN-ACK" Assuming that is the section, when carrier-grade NAT changes the client system's IP address as seen by the server, presumably the cookie the client sends will be invalid, which means unless the server holds-on to data in the SYN upon receipt of an invalid cookie, the client has to retransmit what it sent in the SYN - should step 2 of "Client: Receiving SYN-ACK" reflect that? The server retaining data in a SYN upon receipt of an invalid cookie is another possible attack vector isn't it? One that ties-up server memory for the time it takes the SYN-ACK to retransmit time-out. True, that is no different than if there was a classic TCP which accepted data in the SYN - how many of them actually do that today? TCP theory says a TCP today "should" not drop data in the SYN but still... Since any hope of saving an RTT is already lost in the case of an invalid cookie, and since CKO makes receiving that data by the server TCP a second time essentially free, and since an attacker isn't going to retransmit anyway (?), I don't think you lose anything if you have the server drop the data in the SYN in the case of an invalid cookie and modify that step 2 to immediately retransmit the data upon receipt of the SYN-ACK that does not contain a cookie option. Getting back to carrier NAT - how often does the clients perceived IP address change? Do the carriers make any attempt to make the IPs sticky or are they just round-robining them? rick jones From perfgeek@mac.com Mon Aug 29 19:24:16 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A791721F8A35 for ; Mon, 29 Aug 2011 19:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7610n7bs5fV for ; Mon, 29 Aug 2011 19:24:13 -0700 (PDT) Received: from asmtpout015.mac.com (asmtpout015.mac.com [17.148.16.90]) by ietfa.amsl.com (Postfix) with ESMTP id 68E6621F8AA8 for ; Mon, 29 Aug 2011 19:24:13 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [192.168.1.65] (76-220-56-223.lightspeed.sntcca.sbcglobal.net [76.220.56.223]) by asmtp015.mac.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LQP00JFOYQO1300@asmtp015.mac.com> for tcpm@ietf.org; Mon, 29 Aug 2011 19:25:38 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813,1.0.211,0.0.0000 definitions=2011-08-29_10:2011-08-30, 2011-08-29, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1108290365 From: rick jones In-reply-to: <4E5C1465.9050907@hp.com> Date: Mon, 29 Aug 2011 19:25:36 -0700 Message-id: <8DF6AA63-4B9A-4014-B054-1182B9D284C5@mac.com> References: <4E57ED78.9070600@hp.com> <4E5C1465.9050907@hp.com> To: Rick Jones X-Mailer: Apple Mail (2.1084) Cc: tcpm@ietf.org Subject: Re: [tcpm] feedback on WG adoption of draft-cheng-tcpm-fastopen-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 02:24:16 -0000 > > Presumably, an attacker seeking to extract maximum effect on the server is going to send streams of SYN segments with a bogus cookie and no more than one byte of data. That will maximize his send rate and effect on the server. Adding the cookie to the SYN only costs the attacker a tenth of a nanosecond of transmission time per 10 bits at the server's 10GbE pipe, a cost that is going down all the time as servers get fatter pipes but it costs the server however many nanoseconds it takes to invalidate the cookie. Attackers will almost always have more client systems than the good guys have servers no? Math/unit fail - 10 bits per nanosecond at 10 GbE, so costs the attacker a nanosecond per 10 bits at the server's 10GbE pipe.... rick jones http://homepage.mac.com/perfgeek From hkchu@google.com Mon Aug 29 22:31:56 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B233921F8591 for ; Mon, 29 Aug 2011 22:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.452 X-Spam-Level: X-Spam-Status: No, score=-105.452 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-USp8BN2imN for ; Mon, 29 Aug 2011 22:31:55 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id DE34B21F86EA for ; Mon, 29 Aug 2011 22:31:54 -0700 (PDT) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id p7U5XGXm027838 for ; Mon, 29 Aug 2011 22:33:16 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314682396; bh=7eRLjPMPpcXp5K0n/es/6sS+aco=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=xmUbHS67A7lQJH2CN9Houy9+WBmzB46INYGh841gf1BGuLAJZ2hWA7xgzoisVkHCT B1fpQUJwIULIJ+3ekeNJw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=gy/bSEPj8KW522pxwihXF/K/J1mFEbGHv3b535e23EBZnxGB6IITiLG7FbPAZU97d lFe2G30IJhR33W1J9LW4A== Received: from gyc15 (gyc15.prod.google.com [10.243.49.143]) by wpaz24.hot.corp.google.com with ESMTP id p7U5XFZq006949 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 29 Aug 2011 22:33:15 -0700 Received: by gyc15 with SMTP id 15so12522128gyc.25 for ; Mon, 29 Aug 2011 22:33:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=2xxLXpg8Nflj0qqln6BIZ/uC4k8pQCZubQYjhOWx/ug=; b=w+fk2yNnRzPbZQfeqJOVRkMgrwzb26XMg31BykdTmQ9bzeUuwhi+urys+1cWTtGIfe pwCLFqNkNZEXMv53ZZNw== Received: by 10.150.179.10 with SMTP id b10mr5418233ybf.408.1314682393375; Mon, 29 Aug 2011 22:33:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.179.10 with SMTP id b10mr5418228ybf.408.1314682393182; Mon, 29 Aug 2011 22:33:13 -0700 (PDT) Received: by 10.151.109.17 with HTTP; Mon, 29 Aug 2011 22:33:12 -0700 (PDT) In-Reply-To: <4E5C1465.9050907@hp.com> References: <4E57ED78.9070600@hp.com> <4E5C1465.9050907@hp.com> Date: Mon, 29 Aug 2011 22:33:12 -0700 Message-ID: From: Jerry Chu To: Rick Jones Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: tcpm@ietf.org Subject: Re: [tcpm] feedback on WG adoption of draft-cheng-tcpm-fastopen-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 05:31:56 -0000 On Mon, Aug 29, 2011 at 3:36 PM, Rick Jones wrote: > going through the draft again while composing this some new stuff: > > *) section 2.1 - probably better to say ""i.e., to restrict TFO to a clas= s > of applications that are tolerant" Ok. > >>> *) Just how many more angelic options can dance on the header of the TC= P >>> SYN? =A0How many options being present nearly all the time call for a >>> revision >>> of the standard header (Yes, that is an intractable Layer 8 and 9 issue >>> but >>> still...). >> >> Yes it seems that this option space problem will one day become the chok= e >> point >> for all future TCP innovations... >> >> That's why we've carefully evaluated the tradeoff between the security >> risk vs >> cookie size and decided cookies as small as 4 bytes may be sufficient fo= r >> some >> cases/implementations..., etc. We've even wondered if cookies can be mad= e >> optional (or treated as the degenerate case of server advertising a >> zero-lenghth >> cookie) for some cases where the major security risk for TFO, i.e., >> the reflection >> attack, does not exist. (See >> http://www.ietf.org/proceedings/81/slides/tcpm-0.pdf.) > > > Slide five makes it sound like the definition of an amplification attack = is > one where what is emitted is more than one packet's worth of data. =A0I d= o not > think that is correct. > > Going well back in time, there was the issue of the way that the HP-UX (a= nd > I believe Solaris and a given version of Mac OS, all of which had a stack > with a common ancestor) did PathMTU discovery - by sending a full link-lo= cal > MTU ICMP echo request with the DF bit set in parallel with its attempted > response to the remote IP, with the DF bit cleared. (The idea was to find > the PathMTU without incurring the requisite packet loss on the data that > "mattered") This was an amplification attack which sent only one packet. > =A0And only needed a small inbound packet to trigger it. > > As such, I don't think that one can avoid the taste of cookies if the ser= ver > is to send data back before the 3WHS is complete. But do you know what stack still does this? I believe Solaris was the first stack that supported PMTUD in early to mid 90' by using the DF bit while I was the main maintainer and I don't remember it ever sent a parallel ICMP pkt. I tend to believe the percentage of PMTU !=3D interface MTU is small plus caching past MTU info making the above mentioned optimization unnecessary. > > Slide nine - presumably the client side will also employ the "TCP_TFO" > option. We've assumed client doesn't need an additional call to enable TFO because it's sort of implied in its use of TFO's sendto() call. But this brings up an issue with application portability. On system where TFO is not supported or disabled, one will have to provide a version of sendto() that is API compatible with the one running on TFO enabled stack. So maybe it's worthwhile for the app to find out whether TFO is enabled on a local kernel through a socket option call before it attempts sendto()/sendmsg(). > > Slide 10 - what about server processing overhead in addition to latency. I mentioned in previous email from one test mix we did it showed the saving from one less pkt more than covers the additional processing overhead cause= d by cookies. > =A0The slide almost suggests that rather than teach them to eat cookies, = we > want give applications/stacks further incentives to keep warm - say with = a > blanket :) Yes but persistent HTTP has been problematic (otherwise we won't have bothered with TFO). > > Slide 12 - if the bufferbloat guys are "successful" where will RTTs be - > will they be in the 200ms range from whcih the 41% claim comes or will it= be > closer to 100ms? =A0Also, those whole pages - is the w/ and w/o TFO based= on > IW3 or IW10? The table in slide 12 was produced using an emulation environment with RTT was injected by Dummynet so is exclusive of the queuing delay. I believe the tests used IW10 but need to double check. > And another question - is there a great deal of connection > serialization there - the 200ms RTT example for the wikipedia page shows > saving > 2 seconds. TFO gets rid of one RTT at the beginning of a > connection, so that page had 10, serial TCP connections established to lo= ad > it??? =A0That seems as much a critique of the page design of the TCP wiki= pedia > page as anything else given that the other three sites shown saw much les= s > benefit. We used the Chrome browser and a replay tool created by the Chrome team so there is likely more serialization. We hope to publish more details in an upcoming paper. > > Is there any way to separate "fundamential" serialization from "bad desig= n?" > =A0I like the idea of speeding things up, but I want to make certain that= TFO > isn't abused the way TCP_NODELAY can be. Again the Chrome team has invested lots of cycles gaining insight on PLT an= d we were relying on them for meaningful testcases. > >>> *) MSS, Window Scale, Timestamp, SACK OK are all quite desirable no? = =A0We >>> want to avoid the dreaded 536 byte MSS, handle bandwidth delay products >>> beyond the limit of a 64K window, not corrupt data when we do so, and b= e >>> able to quickly recover from the inevitable segment losses while we do = so >>> - >>> not just in the interests of bandwidth, but in the interests of time. >>> =A0IIRC >>> that is 2 + 3 + 10 + 2 or 17 bytes of option space in the SYN (assuming >>> fully packed). =A040 bytes of option space is the limit no? >> >> Correct and since we believe the potential damage from an amplified >> reflection >> attack is somewhat limited we do not suggest an insanely large cookie si= ze >> hence all our suggested sizes fit together with other, existing commonly >> used >> options. Yes going forward will be an issue but it's a general issue not >> limited >> to TFO that needs to be addressed separately. > > Though concurrently. =A0Leaving that to the next poor schmuck who needs 6 > bytes of option space doesn't seem all that, well, polite. =A0Pitty we ca= nnot > smash several common TCP options together into one uber-option... or can = we? > =A0Just how random does the initial timestamp *have* to be? But perhaps I > digress... It looks like you just brought up some great idea for future drafts. > >>> Section 4.1.1 of the draft talks about the cookie being up to 16 bytes = in >>> size, consuming a total of 18 bytes of option space. So, I suppose that >>> doesn't completely consume the option space, but it starts to look pret= ty >>> full - only 5 bytes left, perhaps only 4 depending on option alignment. >>> =A0How >>> would one prioritize the cookie vs the other options once options space >>> was >>> exhausted? =A0Section 4.2.2 makes a passing mention of forgoing TFO but >>> expanding on that would be goodness. >> >> Sure and we've already come across that problem when trying to enable th= e >> TCP MD5 options internally. >> >> From the top of my head that could be an deployment decision. Each site >> will >> need to prioritize their option preference but unfortunately options >> are initiated by the client side... Sigh (a train wreck is bound to >> happen). > > All the more reason to describe why TCP option A is higher priority than = TCP > option B. =A0So when the trains do wreck it will be possible to point-out= that > it could have been avoided - well assuming that the advice would have > prevented it :) > >>> *) Section 4.2.1 gives an example of AES_128 for generating the cookie >>> and >>> says it takes "only a few hundred nanoseconds." =A0I think it would be >>> goodness to be a bit more specific, and perhaps include some contempora= ry >>> service demands for TCP connection establishment. Particularly since a >>> TCP >>> SYN with the cookie request could arrive every 68 nanoseconds through a >>> 10GbE pipe into the server, and since 40 and 100 GbE are virtually upon >>> us. >>> =A0More specific numbers for validating cookies up to 16 bytes would be >>> goodness as well. >> >> We have actually done some study on the server cookie processing overhea= d >> and will revise the draft with the data once we are cleared for >> publication. In >> our test the # of sustained HTTP transaction rate was higher with TFO th= an >> w/o. >> We attributed this to the fact that the reduced in pkt count (due to >> carrying >> data in SYN) from TFO and its CPU saving more than compensating for the >> extra CPU processing cost from AES_128. > > I don't doubt that in the "good" case that sustained transaction rate wou= ld > be higher. =A0If it weren't I suspect we wouldn't be discussing TFO in th= e > first place :) > > I'm wondering about the attack case, when the attacker is sending SYN > segments with bogus cookies, or even just cookie requests, all from spoof= ed > IPs. =A0That is a case where TFO does not reduce the number of segments s= ent, > but does increase the processing overhead. =A0Particularly if the specifi= ed > behaviour ends-up being to treat an invalid cookie as an implicit cookie > request. > > Yes, that is what the global counter is all about, but once that counter = is > reached, the server is forced to fall-back on pre-TFO behaviour, which me= ans > that server operators are going to want to make that limit rather high. = =A0An No they won't because these potentially bogus TFO requests take up memory just like pending SYN requests so they should and will be treated similarl= y, may even be subject to the same max qlen as regular SYN requests. > invalid cookie is Really Cheap (tm) to bake. > > Ten years ago I would have called worrying about the attack case an examp= le > of optimizing for the non-expected case, but today it seems that attacks = are > to be expected. :( Yup. Like I mentioned in my previous reply there is plenty of opportunities for fine tuning the protocol. E.g., the qlen check could happen before a cookie is validated like you suggested. This will cap the cookie validation overhead to no more= than is allowed by max qlen's worth of TFO requests. In order to enable the clie= nt to differentiate between a TFO request hitting a non-TFO server vs a TFO reque= st hitting server's max qlen limit, a different TFO opcode can be returned by = the server in the latter case. > >> >>> >>> *) Doesn't Section 4.2.2 (or some other) need to specify what should >>> happen >>> when a TCP SYN with a TFO cookie arrives at an endpoint where the >>> application has not explicitly enabled TFO? =A0Particularly since the c= ache >>> of >>> cookies is per-IP and not per IP-port-pair? =A0A restart of the server >>> application could change the setting while there was still an entry >>> cached >>> in the client(s). =A0Unless automagically generating a new cookie upon >>> receipt >>> of an invalid one is dropped, presumably the behaviour of the server >>> would >>> be slightly different in that it would drop the cookie and not make a n= ew >>> one, as there is no point. >> >> Yes TFO is negotiated implicitly by client including a cookie option and >> the >> server acknowledging explicitly the cookie option (by either acking the >> data in >> SYN or replying with a new cookie). All other cases will cause TFO to >> be disabled. >> So if the listening app has not enabled TFO, TCP won't reply with a >> cookie option nor acking the data in the SYN pkt. >> >> There is probably some details on how often the client wants to >> refresh the cookie cache etc but some of them can be left to the >> implementation. > > I would think that if the client is caching effective MSS with the cookie= , > then it should be on a timescale matching that of the cache of discovered > PathMTUs. > >>> *) Given the ability to spoof IP addresses, I think the order of server >>> processing given in 4.2.2 " Server: Receiving SYN and responding with >>> SYN-ACK" should be changed. PendingFastOpenRequests should be checked >>> first, before even attempting to validate the cookie. >> >> Aha, you've caught some good corner case. It think my colleague wrote >> in that order because not replying a cookie nor acking the data will >> be treated by the client as the server disabling/de-supporting TFO. >> But I'm sure we can further fine tune the cookie protocol to address >> any ambiguity and performance optimization. > > Unless the client side is caching a "negative response," which I don't > recall the draft suggesting, the next connection attempt to the server by= a > TFO-enabling application on that client will naturally attempt to get a > cookie again anyway right? =A0I don't think you need to address it. Well some of these details are left to the implementation but for those important ones we will certainly love to take input like yours and continue= to refine. > >>> Further, until cookie generation is shown to indeed be epsilon >>> compared to the rest of TCP connection establishment on the >>> server, the server should not include a new cookie when the cookie >>> was invalid and instead require the client to make another "from >>> scratch" cookie request. >> >> Yes we've thought about these performance issues and have gone >> through a few rounds of the seemingly simple cookie protocol design >> cycle. But I'm not sure your suggested "from scratch" approach will >> help much to defend against a malicious client if the cookie >> generation is expensive. I think it boils down to as long as the >> cookie generation is no more expensive than the processing overhead >> of a SYN pkt (upto checking the listener's qlimit), this case is no >> worse than the SYN attack. > > Cookie generation, no matter how cheap, is still more than the server was > doing on each SYN before no? =A0The calculus seems to be that the savings= from > avoiding an RTT (not simply avoiding packets - at least some of that coul= d > come from merely accepting data on the SYN and awaiting the 3WHS) is goin= g > to out-weigh what happens when under attack. > > Presumably, an attacker seeking to extract maximum effect on the server i= s > going to send streams of SYN segments with a bogus cookie and no more tha= n > one byte of data. =A0That will maximize his send rate and effect on the > server. =A0Adding the cookie to the SYN only costs the attacker a tenth o= f a > nanosecond of transmission time per 10 bits at the server's 10GbE pipe, a > cost that is going down all the time as servers get fatter pipes but it > costs the server however many nanoseconds it takes to invalidate the cook= ie. > =A0Attackers will almost always have more client systems than the good gu= ys > have servers no? Again if cookie validation cost becomes a real issue we can also do what I described earlier to subject it to the same max qlen check. Moreover, if the cost of cookie generation also becomes a concern, we can tweak the protocol to not return a valid cookie, when asked, as part of SYN= -ACK, but instead the server will wait till 3WHS finishes before handing out cookie as part of ack (unreliable), or data segment (reliable). Details need to be worked out and it's also a tradeoff between a little more complexity vs addressing the con= cern about cookie processing overhead under attack. > >>> Also, given that the application isn't notified until step 4, "The serv= er >>> MAY include data in the SYN-ACK packet (sic =A0pedant mode, TCP sends >>> segments >>> not packets)" >> >> The draft was written for those majority, non-pedantic audience, who mig= ht >> not >> appreciate the subtle difference between "segments" and "packets" :) > > Never underestimate the value of pedantry in matters of details :) > >>> in step 3 seems out of place unless we are assuming there are >>> applications which will use this that want data sent before receiving >>> anything, in which case that is another bit of user interface to descri= be >>> somewhere. >> >> No, this is more like the regular delayed ack case when the SYN-ACK is >> delayed giving the app some time to respond. (Remember TFO will send up >> the data included in the SYN pkt right away before the final ack.) > > I guess it is a good thing that the delayed ACK timer would not be starte= d > until after the cookie was known to be valid, or the time for that would > have to be added into the calculus too :) > > >>> *) 4.1.3 reads "For a multi-homed client, the cookies are both client a= nd >>> server IP dependent." =A0I ass-u-me that means they should be cached ba= sed >>> on >>> both client and server IP. =A0That is I suppose implicit with cookies b= eing >>> generated by servers but it rarely hurts to be explicit. However, why >>> does >>> it have to be client,server IP at the client? >> >> Well for a multi-homed client it needs to pick cookies based on client& >> =A0server >> IP. (Maybe I've missed your question?) > > No, I simply missed the point. > > I was going to ask about NAT, but found section 5. =A0However, when that > section says that there is no performance penalty it points towards "Clie= nt > receiving SYN-ACK" - my pedantic :) search didn't find that, but I did fi= nd > "Client: Receiving SYN-ACK" =A0Assuming that is the section, when > carrier-grade NAT changes the client system's IP address as seen by the > server, presumably the cookie the client sends will be invalid, which mea= ns > unless the server holds-on to data in the SYN upon receipt of an invalid No, the server will always drop data if the cookie is invalid. > cookie, the client has to retransmit what it sent in the SYN - should ste= p 2 > of "Client: Receiving SYN-ACK" reflect that? It's sort of implied in the paragraph followed 3: "Note there is no latency penalty if the server does not acknowledge the data in the original SYN packet. The client will retransmit it in the ACK packet..." > > The server retaining data in a SYN upon receipt of an invalid cookie is > another possible attack vector isn't it? Hmm, not sure where in the draft gives the impression the server will retai= n the data. Oh, it looks like the draft only stated to ack the SYN only but never explicitly stated to drop the data. Will fix this. >One that ties-up server memory for > the time it takes the SYN-ACK to retransmit time-out. =A0True, that is no > different than if there was a classic TCP which accepted data in the SYN = - > how many of them actually do that today? =A0TCP theory says a TCP today > "should" not drop data in the SYN but still... =A0Since any hope of savin= g an > RTT is already lost in the case of an invalid cookie, and since CKO makes > receiving that data by the server TCP a second time essentially free, and > since an attacker isn't going to retransmit anyway (?), I don't think you > lose anything if you have the server drop the data in the SYN in the case= of > an invalid cookie and modify that step 2 to immediately retransmit the da= ta > upon receipt of the SYN-ACK that does not contain a cookie option. Sorry for the confusion. We need intend for the server to retain data upon a invalid cookie - the whole point why a cookie is used. > > Getting back to carrier NAT - how often does the clients perceived IP > address change? =A0Do the carriers make any attempt to make the IPs stick= y or > are they just round-robining them? Will have to go back to the data we collected, or collect more data to answ= er this question. Thanks, Jerry > > rick jones > From Michael.Scharf@alcatel-lucent.com Wed Aug 31 01:23:52 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE2621F8B12 for ; Wed, 31 Aug 2011 01:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.191 X-Spam-Level: X-Spam-Status: No, score=-6.191 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjeQf1BHIPWt for ; Wed, 31 Aug 2011 01:23:52 -0700 (PDT) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by ietfa.amsl.com (Postfix) with ESMTP id C570D21F8ADC for ; Wed, 31 Aug 2011 01:23:51 -0700 (PDT) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id p7V8PIa5017488 for ; Wed, 31 Aug 2011 10:25:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 31 Aug 2011 10:25:16 +0200 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C06683228@SLFSNX.rcs.alcatel-research.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: End of WGLC for draft-ietf-tcpm-rfc3782-bis-02 Thread-Index: AcxE30Q8Xnk5mhX4Sl2ijPOGvE99ywi168FQ From: "SCHARF, Michael" To: "TCP Maintenance and Minor Extensions WG" X-Scanned-By: MIMEDefang 2.69 on 149.204.45.73 Subject: [tcpm] End of WGLC for draft-ietf-tcpm-rfc3782-bis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 08:23:52 -0000 Dear all, as far as I can see, this WGLC ended without any comment. We will therefore hand over the document to the IESG.=20 Thanks Michael -----Original Message----- From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of SCHARF, Michael Sent: Monday, July 18, 2011 2:48 AM To: TCP Maintenance and Minor Extensions WG Subject: [tcpm] WGLC for draft-ietf-tcpm-rfc3782-bis-02 Dear all, we have the following charter milestone: Apr 2011 - Submit document updating the NewReno RFC 3782 to the IESG for publication as Proposed Standard Recently there have been no comments on draft-ietf-tcpm-rfc3782-bis, and the authors have no plans for further revisions. Therefore, this email begins a Working Group Last Call on draft-ietf-tcpm-rfc3782-bis-02 to close on August 5. As discussed at the IETF 80, the document is planned to go to Proposed Standard. Best regards Michael _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From pasi.sarolahti@iki.fi Wed Aug 31 06:55:36 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBB521F8BB5 for ; Wed, 31 Aug 2011 06:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTtkpDlAcJIL for ; Wed, 31 Aug 2011 06:55:35 -0700 (PDT) Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE0221F8BB1 for ; Wed, 31 Aug 2011 06:55:34 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 994D81E052 for ; Wed, 31 Aug 2011 16:57:04 +0300 (EEST) X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id O0jq33R48JUz for ; Wed, 31 Aug 2011 16:57:00 +0300 (EEST) Received: from pc75.netlab.hut.fi (pc75.netlab.hut.fi [130.233.154.75]) by smtp.netlab.hut.fi (Postfix) with ESMTPSA id 98F791E04E for ; Wed, 31 Aug 2011 16:57:00 +0300 (EEST) From: Pasi Sarolahti Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 31 Aug 2011 16:57:00 +0300 Message-Id: <9605EAA4-F1C4-4D83-B76E-88C81BFE1555@iki.fi> To: tcpm@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 13:55:36 -0000 Hi, TCP's option space has been under increasing demand recently, with new = option-space hungry extensions such as MPTCP, and some recent ideas in = the research domain. In the past there have been some discussion about = mechanisms to extend the option space, and an extension option was = proposed in draft-eddy-tcp-loo, but since then these efforts have died = down. I'm wondering if there would be any interest in the tcpm community = to resume this work. I recall that re-segmenting middleboxes were mentioned as one potential = problem for such extension, and there might be other problems. = Nevertheless, I would find it useful, if there was an RFC that a) = documented the known problems with option space extension; and b) = defined an option format and assigned the needed type codes, to enable = experimentations with larger than 40-byte option space. Thoughts? - Pasi From shep@xplot.org Wed Aug 31 07:25:42 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 860A521F8B7A for ; Wed, 31 Aug 2011 07:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97QGO9Feesz7 for ; Wed, 31 Aug 2011 07:25:42 -0700 (PDT) Received: from www.xplot.org (www.xplot.org [66.92.66.146]) by ietfa.amsl.com (Postfix) with ESMTP id E35A021F8B67 for ; Wed, 31 Aug 2011 07:25:41 -0700 (PDT) Received: from shep (helo=alva.home) by www.xplot.org with local-esmtp (Exim 3.36 #1 (Debian)) id 1Qylkk-00069G-00; Wed, 31 Aug 2011 10:26:54 -0400 From: Tim Shepard To: Pasi Sarolahti In-reply-to: Your message of Wed, 31 Aug 2011 16:57:00 +0300. <9605EAA4-F1C4-4D83-B76E-88C81BFE1555@iki.fi> Date: Wed, 31 Aug 2011 10:26:54 -0400 Message-Id: Sender: Tim Shepard Cc: tcpm@ietf.org Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 14:25:42 -0000 Several years ago, I posted to the TCPM list a ha-ha-only-serious proposal that what we need is a single new minimal size option called IAMACAHYAT which could be exchanged on the SYN and SYN-ACK packets. This would be used to allow both ends to signal to each other that they are fully prepared to negotiate further options on later segments. There was a belief at least among some that unexpected options on anything other than the SYN are dangerous because there might be stacks out there that handle them badly, like crashing. So we seemed to be stuck requiring all new options to somehow fit in the SYN/SYN-ACK exchange. And now that I think of it, perhaps it would have been good if MPTCP had not filled up most all of the remaining option space on the SYN with its new options but had instead required use of the IAMACAHYAT option on the initial SYN/SYN-ACK exchange, and then did its own option negotiation on later packets. I think this sort of hack could help quite a bit. (Though I understand that for some things we might very much want the new options to fly on the initial SYN SYN-ACK exchange to avoid having to wait another round trip for the negotiation to happen.) -Tim Shepard shep@alum.mit.edu From Michael.Scharf@alcatel-lucent.com Wed Aug 31 07:43:15 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEBDB21F8B73 for ; Wed, 31 Aug 2011 07:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.193 X-Spam-Level: X-Spam-Status: No, score=-6.193 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqYyQJ9A-J4X for ; Wed, 31 Aug 2011 07:43:15 -0700 (PDT) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by ietfa.amsl.com (Postfix) with ESMTP id 07A5C21F8B6C for ; Wed, 31 Aug 2011 07:43:14 -0700 (PDT) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id p7VEihtD002402 for ; Wed, 31 Aug 2011 16:44:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 31 Aug 2011 16:44:11 +0200 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C066832A6@SLFSNX.rcs.alcatel-research.de> In-Reply-To: <9605EAA4-F1C4-4D83-B76E-88C81BFE1555@iki.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Extending TCP option space Thread-Index: Acxn5eo6vrh10eDiSgikAaYRk604WgABnF5w References: <9605EAA4-F1C4-4D83-B76E-88C81BFE1555@iki.fi> From: "SCHARF, Michael" To: "TCP Maintenance and Minor Extensions WG" X-Scanned-By: MIMEDefang 2.69 on 149.204.45.73 Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 14:43:15 -0000 Hi Pasi, > TCP's option space has been under increasing demand recently, with new > option-space hungry extensions such as MPTCP, and some recent ideas in > the research domain. In the past there have been some discussion about > mechanisms to extend the option space, and an extension option was=20 > proposed in draft-eddy-tcp-loo, but since then these efforts have died > down. I'm wondering if there would be any interest in the tcpm=20 > community to resume this work. >=20 > I recall that re-segmenting middleboxes were mentioned as one=20 > potential problem for such extension, and there might be other=20 > problems. Nevertheless, I would find it useful, if there was an RFC=20 > that a) documented the known problems with option space extension; and > b) defined an option format and assigned the needed type codes, to=20 > enable experimentations with larger than 40-byte option space. >=20 > Thoughts? actually, I happened to argue in favor of a) in hallway discussions during the last IETF meetings. Maybe someone should just start to put together some text, at least for a)... (And I think it would really make sense to raise awareness among researchers that TCP option space in SYNs is a really scarce resource.) Michael From touch@isi.edu Wed Aug 31 08:45:09 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB1D921F8C46 for ; Wed, 31 Aug 2011 08:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUMk1AXzDXiW for ; Wed, 31 Aug 2011 08:45:09 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAD521F8C44 for ; Wed, 31 Aug 2011 08:45:09 -0700 (PDT) Received: from [198.123.60.143] ([198.123.60.143]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p7VFkFGU012130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 Aug 2011 08:46:25 -0700 (PDT) Message-ID: <4E5E5748.301@isi.edu> Date: Wed, 31 Aug 2011 08:46:16 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "SCHARF, Michael" References: <9605EAA4-F1C4-4D83-B76E-88C81BFE1555@iki.fi> <133D9897FB9C5E4E9DF2779DC91E947C066832A6@SLFSNX.rcs.alcatel-research.de> In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C066832A6@SLFSNX.rcs.alcatel-research.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: TCP Maintenance and Minor Extensions WG Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 15:45:09 -0000 FWIW, I had offered to summarize the reasons why this has failed in the past (and, IMO, simply isn't useful to pursue). Again, let me know. Joe On 8/31/2011 7:44 AM, SCHARF, Michael wrote: > Hi Pasi, > >> TCP's option space has been under increasing demand recently, with new > >> option-space hungry extensions such as MPTCP, and some recent ideas in > >> the research domain. In the past there have been some discussion about > >> mechanisms to extend the option space, and an extension option was >> proposed in draft-eddy-tcp-loo, but since then these efforts have died > >> down. I'm wondering if there would be any interest in the tcpm >> community to resume this work. >> >> I recall that re-segmenting middleboxes were mentioned as one >> potential problem for such extension, and there might be other >> problems. Nevertheless, I would find it useful, if there was an RFC >> that a) documented the known problems with option space extension; and > >> b) defined an option format and assigned the needed type codes, to >> enable experimentations with larger than 40-byte option space. >> >> Thoughts? > > actually, I happened to argue in favor of a) in hallway discussions > during the last IETF meetings. Maybe someone should just start to put > together some text, at least for a)... (And I think it would really make > sense to raise awareness among researchers that TCP option space in SYNs > is a really scarce resource.) > > Michael > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From touch@isi.edu Wed Aug 31 08:57:42 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC8121F8CBA for ; Wed, 31 Aug 2011 08:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.266 X-Spam-Level: X-Spam-Status: No, score=-103.266 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2K13p57UAH9z for ; Wed, 31 Aug 2011 08:57:42 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id CCE5021F8CAE for ; Wed, 31 Aug 2011 08:57:31 -0700 (PDT) Received: from [198.123.60.143] ([198.123.60.143]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id p7VFwiS2001393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 Aug 2011 08:58:47 -0700 (PDT) Message-ID: <4E5E5A34.1030707@isi.edu> Date: Wed, 31 Aug 2011 08:58:44 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Tim Shepard References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 15:57:43 -0000 On 8/31/2011 7:26 AM, Tim Shepard wrote: > > > Several years ago, I posted to the TCPM list a ha-ha-only-serious > proposal that what we need is a single new minimal size option called > IAMACAHYAT which could be exchanged on the SYN and SYN-ACK packets. > > This would be used to allow both ends to signal to each other that > they are fully prepared to negotiate further options on later > segments. Whether this works or not - as per middlebox interactions - is less important than it not solving the problem. In a nutshell: - extending option space after then TWHS is trivial define a new option, confirm it with a SYN exchange, and either the SYN gets dropped (some midboxes), the option is dropped (others), or it works. if the SYN is retransmitted, retransmit without the option and tell the user it failed ;-( - extending the SYN option space is the real issue anyway - put in an option and extend the options right then this breaks under 'ignore unknown options', since the end of the options will be mis- read as data - put in an option and use the data in the SYN this breaks under 'ignore unknown options', since the option-as-data will be mis- read as data - put in something that breaks if unknown this is the same as using a new transport protocol number, and won't pass through NATs If anyone sees a way around #2, please speak up. My recollection is that we've dragged this dog around the block every few years, and realize the same thing: TCP SYN option space cannot be extended There may be use to extending the space after the SYNs (someone can propose that), but doing it in the SYNs doesn't appear to be possible. NOTE: > There was a belief at least among some that unexpected options on > anything other than the SYN are dangerous because there might be > stacks out there that handle them badly, like crashing. So we seemed > to be stuck requiring all new options to somehow fit in the > SYN/SYN-ACK exchange. Options are exchanged reliably only during connection establishment. There is no TWHS after that. So starting a new option after the connection starts seems difficult at best - however, it fails to solve the key issue: - starting after the SYN has no real use given you can start the option during the SYN with 2 bytes - extending the SYN option space isn't helped by starting after the SYN Another suggestion was to set an option that can affect future TCP connections, but this is a problem because: a) hosts that restart could use new stacks that don't support the option, and have no way to safely ignore it b) IP addrs can be/are shared among endpoints (behind NATs, or via L2 muxing) > And now that I think of it, perhaps it would have been good if MPTCP > had not filled up most all of the remaining option space on the SYN > with its new options but had instead required use of the IAMACAHYAT > option on the initial SYN/SYN-ACK exchange, and then did its > own option negotiation on later packets. Option negotiation on subsequent packets needs to build in enough of a state machine to consider what happens when packets are replayed or come out of order. The TWHS already handles that, but there doesn't appear to be a good way to do that once a connection is established. Joe From shep@xplot.org Wed Aug 31 09:06:52 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6612821F8D00 for ; Wed, 31 Aug 2011 09:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQOGjneo213P for ; Wed, 31 Aug 2011 09:06:52 -0700 (PDT) Received: from www.xplot.org (www.xplot.org [66.92.66.146]) by ietfa.amsl.com (Postfix) with ESMTP id D12C421F8CD5 for ; Wed, 31 Aug 2011 09:06:51 -0700 (PDT) Received: from shep (helo=alva.home) by www.xplot.org with local-esmtp (Exim 3.36 #1 (Debian)) id 1QynKg-0006cn-00; Wed, 31 Aug 2011 12:08:06 -0400 From: Tim Shepard To: Joe Touch In-reply-to: Your message of Wed, 31 Aug 2011 08:58:44 -0700. <4E5E5A34.1030707@isi.edu> Date: Wed, 31 Aug 2011 12:08:06 -0400 Message-Id: Sender: Tim Shepard Cc: tcpm@ietf.org Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 16:06:52 -0000 > If anyone sees a way around #2, please speak up. My recollection is that > we've dragged this dog around the block every few years, and realize the > same thing: > > TCP SYN option space cannot be extended > > There may be use to extending the space after the SYNs (someone can > propose that), but doing it in the SYNs doesn't appear to be possible. I think the space could be extended on the SYN-ACK if there was something on the SYN that indicated that the initiator could handle it. Just not on the initial SYN. (Middle boxes: grumble. Simultaneous open: uh huh.) -Tim Shepard shep@alum.mit.edu From touch@isi.edu Wed Aug 31 09:11:37 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1963C21F8B91 for ; Wed, 31 Aug 2011 09:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mrWBHPOTZ6p for ; Wed, 31 Aug 2011 09:11:36 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 991CC21F8B8F for ; Wed, 31 Aug 2011 09:11:36 -0700 (PDT) Received: from [198.123.60.143] ([198.123.60.143]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p7VGCiMi011689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 Aug 2011 09:12:54 -0700 (PDT) Message-ID: <4E5E5D7C.5040808@isi.edu> Date: Wed, 31 Aug 2011 09:12:44 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Tim Shepard References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 16:11:37 -0000 On 8/31/2011 9:08 AM, Tim Shepard wrote: >> If anyone sees a way around #2, please speak up. My recollection is that >> we've dragged this dog around the block every few years, and realize the >> same thing: >> >> TCP SYN option space cannot be extended >> >> There may be use to extending the space after the SYNs (someone can >> propose that), but doing it in the SYNs doesn't appear to be possible. > > I think the space could be extended on the SYN-ACK if there was > something on the SYN that indicated that the initiator could handle > it. Just not on the initial SYN. (Middle boxes: grumble. > Simultaneous open: uh huh.) It's the SYN that's the real problem. Sure, once you confirm, the SYN-ACK is fair game as are all subsequent packets. Joe From mallman@icir.org Wed Aug 31 09:14:28 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D70F021F8CD8 for ; Wed, 31 Aug 2011 09:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.324 X-Spam-Level: X-Spam-Status: No, score=-106.324 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNNriM9ASr0q for ; Wed, 31 Aug 2011 09:14:27 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 6810B21F8B05 for ; Wed, 31 Aug 2011 09:14:20 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p7VGFlSw004098; Wed, 31 Aug 2011 09:15:48 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 66A7066EF0D; Wed, 31 Aug 2011 12:15:47 -0400 (EDT) To: Tim Shepard From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Blow Up the Outside World X-URL-0: http://www.icir.org/mallman-files/Document84207.html X-URL-1: http://www.icir.org/mallman-files/Document93267.xlsx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma24112-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 31 Aug 2011 12:15:47 -0400 Sender: mallman@icir.org Message-Id: <20110831161547.66A7066EF0D@lawyers.icir.org> Cc: tcpm@ietf.org Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 16:14:29 -0000 ----------ma24112-1 Content-Type: text/plain Content-Disposition: inline > There was a belief at least among some that unexpected options on > anything other than the SYN are dangerous because there might be > stacks out there that handle them badly, like crashing. So we seemed > to be stuck requiring all new options to somehow fit in the > SYN/SYN-ACK exchange. Well, - It is 2011. If something crashes because of the arrival of an unknown option it probably has bigger problems. - In particular, in a study a few years back [*] we found that an unknown option in the SYN caused connection failures in 0.2% of the cases. And, further, unexpected [**] options plopped on a packet after the 3WHS caused connection failure rates of 3%. I'd bet that by now that is likely even lower. But, at least that is some data. allman [*] Alberto Medina, Mark Allman, Sally Floyd. Measuring the Evolution of Transport Protocols in the Internet. ACM Computer Communication Review, 35(2), April 2005. http://www.icir.org/mallman/papers/tcp-evo-ccr05.ps [**] "Unexpected" took two forms. (1) the timestamp option, even though we did not put a TS in the SYN and (2) an unspecified junk option. ----------ma24112-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk5eXjIACgkQWyrrWs4yIs4I/wCfWQpLYwaIUGM7xPAvvqqob/Ja LMMAn2IyqEGgZVjo+wKtnwPZ27bfQLhd =xTmr -----END PGP SIGNATURE----- ----------ma24112-1-- From rick.jones2@hp.com Wed Aug 31 09:24:22 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37EF021F8D1A for ; Wed, 31 Aug 2011 09:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmdxfhVHvpei for ; Wed, 31 Aug 2011 09:24:21 -0700 (PDT) Received: from g6t0184.atlanta.hp.com (g6t0184.atlanta.hp.com [15.193.32.61]) by ietfa.amsl.com (Postfix) with ESMTP id A33FC21F8D19 for ; Wed, 31 Aug 2011 09:24:21 -0700 (PDT) Received: from g5t0030.atlanta.hp.com (g5t0030.atlanta.hp.com [16.228.8.142]) by g6t0184.atlanta.hp.com (Postfix) with ESMTP id 00C3AC311; Wed, 31 Aug 2011 16:25:51 +0000 (UTC) Received: from [16.89.244.213] (tardy.cup.hp.com [16.89.244.213]) by g5t0030.atlanta.hp.com (Postfix) with ESMTP id 9CA01140E2; Wed, 31 Aug 2011 16:25:51 +0000 (UTC) Message-ID: <4E5E608E.3060006@hp.com> Date: Wed, 31 Aug 2011 09:25:50 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110805 Lightning/1.0b2 Thunderbird/3.1.12 MIME-Version: 1.0 To: Tim Shepard References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org, Joe Touch Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 16:24:22 -0000 On 08/31/2011 09:08 AM, Tim Shepard wrote: > > >> If anyone sees a way around #2, please speak up. My recollection is that >> we've dragged this dog around the block every few years, and realize the >> same thing: >> >> TCP SYN option space cannot be extended >> >> There may be use to extending the space after the SYNs (someone can >> propose that), but doing it in the SYNs doesn't appear to be possible. > > I think the space could be extended on the SYN-ACK if there was > something on the SYN that indicated that the initiator could handle > it. Just not on the initial SYN. (Middle boxes: grumble. > Simultaneous open: uh huh.) So, active side says "I understand an extended set of options and can confirm them on my ACK of your SYN-ACK" and then when the passive side understands it, it gets to initiate options by introducing them with the SYN-ACK, which themselves are accepted or not via the active side's ACK of the passive sides SYN-ACK? It becomes rather a rather kludgy layer violation, but how flexible are IPv6 optional headers? rick jones From touch@isi.edu Wed Aug 31 09:34:42 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E021C21F8CC7 for ; Wed, 31 Aug 2011 09:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-UH3nINtM7A for ; Wed, 31 Aug 2011 09:34:42 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 5E23A21F8CAA for ; Wed, 31 Aug 2011 09:34:42 -0700 (PDT) Received: from [198.123.60.143] ([198.123.60.143]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id p7VGZSQ4013343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 Aug 2011 09:35:31 -0700 (PDT) Message-ID: <4E5E62D0.5080302@isi.edu> Date: Wed, 31 Aug 2011 09:35:28 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Rick Jones References: <4E5E608E.3060006@hp.com> In-Reply-To: <4E5E608E.3060006@hp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Tim Shepard Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 16:34:43 -0000 On 8/31/2011 9:25 AM, Rick Jones wrote: > On 08/31/2011 09:08 AM, Tim Shepard wrote: >> >> >>> If anyone sees a way around #2, please speak up. My recollection is that >>> we've dragged this dog around the block every few years, and realize the >>> same thing: >>> >>> TCP SYN option space cannot be extended >>> >>> There may be use to extending the space after the SYNs (someone can >>> propose that), but doing it in the SYNs doesn't appear to be possible. >> >> I think the space could be extended on the SYN-ACK if there was >> something on the SYN that indicated that the initiator could handle >> it. Just not on the initial SYN. (Middle boxes: grumble. >> Simultaneous open: uh huh.) > > So, active side says "I understand an extended set of options and can > confirm them on my ACK of your SYN-ACK" and then when the passive side > understands it, it gets to initiate options by introducing them with the > SYN-ACK, Yes. > which themselves are accepted or not via the active side's ACK > of the passive sides SYN-ACK? You get more option space at that point. You don't (IMO) get to start another round of option negotiation - that's a 4WHS. > It becomes rather a rather kludgy layer violation, but how flexible are > IPv6 optional headers? That won't work through a NAT, AFAICT. NATs wouldn't know to look for the option, and thus would interpret the TCP header conventionally (and thus misinterpret the extended option space as data). Joe From rick.jones2@hp.com Wed Aug 31 09:57:01 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0491821F8D1F for ; Wed, 31 Aug 2011 09:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.399 X-Spam-Level: X-Spam-Status: No, score=-106.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OegvraZIdydM for ; Wed, 31 Aug 2011 09:57:00 -0700 (PDT) Received: from g5t0009.atlanta.hp.com (g5t0009.atlanta.hp.com [15.192.0.46]) by ietfa.amsl.com (Postfix) with ESMTP id 8D47021F8D0E for ; Wed, 31 Aug 2011 09:57:00 -0700 (PDT) Received: from g5t0030.atlanta.hp.com (g5t0030.atlanta.hp.com [16.228.8.142]) by g5t0009.atlanta.hp.com (Postfix) with ESMTP id 18B073033B; Wed, 31 Aug 2011 16:58:31 +0000 (UTC) Received: from [16.89.244.213] (tardy.cup.hp.com [16.89.244.213]) by g5t0030.atlanta.hp.com (Postfix) with ESMTP id AADB7140D9; Wed, 31 Aug 2011 16:58:30 +0000 (UTC) Message-ID: <4E5E6835.3010604@hp.com> Date: Wed, 31 Aug 2011 09:58:29 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110805 Lightning/1.0b2 Thunderbird/3.1.12 MIME-Version: 1.0 To: Joe Touch References: <4E5E608E.3060006@hp.com> <4E5E62D0.5080302@isi.edu> In-Reply-To: <4E5E62D0.5080302@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org, Tim Shepard Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 16:57:01 -0000 >> So, active side says "I understand an extended set of options and can >> confirm them on my ACK of your SYN-ACK" and then when the passive side >> understands it, it gets to initiate options by introducing them with the >> SYN-ACK, > > Yes. > >> which themselves are accepted or not via the active side's ACK >> of the passive sides SYN-ACK? > > You get more option space at that point. You don't (IMO) get to start > another round of option negotiation - that's a 4WHS. Is there anything technical standing in the way of letting the server introduce an option on the SYN-ACK that gets accepted by the client via an option carried in the ACK of the SYN-ACK? >> It becomes rather a rather kludgy layer violation, but how flexible are >> IPv6 optional headers? > > That won't work through a NAT, AFAICT. NATs wouldn't know to look for > the option, and thus would interpret the TCP header conventionally (and > thus misinterpret the extended option space as data). I wasn't thinking of putting TCP options in the data portion of the TCP segment, I was thinking of stuffing them into an IPv6 extension header. (and got my terms wrong at first) With a "see the appropriate IPv6 extension header for more TCP options" option in the TCP header. Abuse Destination Options perhaps? Or add something new akin to the Fragmentation Header? rick jones From touch@isi.edu Wed Aug 31 10:07:48 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEAB521F8DD8 for ; Wed, 31 Aug 2011 10:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.932 X-Spam-Level: X-Spam-Status: No, score=-104.932 tagged_above=-999 required=5 tests=[AWL=1.667, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXbGzrWpgzn2 for ; Wed, 31 Aug 2011 10:07:48 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 45B6321F8DA6 for ; Wed, 31 Aug 2011 10:07:48 -0700 (PDT) Received: from [198.123.60.143] ([198.123.60.143]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p7VH889w029660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 Aug 2011 10:08:18 -0700 (PDT) Message-ID: <4E5E6A78.3070308@isi.edu> Date: Wed, 31 Aug 2011 10:08:08 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Rick Jones References: <4E5E608E.3060006@hp.com> <4E5E62D0.5080302@isi.edu> <4E5E6835.3010604@hp.com> In-Reply-To: <4E5E6835.3010604@hp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Tim Shepard Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 17:07:48 -0000 On 8/31/2011 9:58 AM, Rick Jones wrote: >>> So, active side says "I understand an extended set of options and can >>> confirm them on my ACK of your SYN-ACK" and then when the passive side >>> understands it, it gets to initiate options by introducing them with the >>> SYN-ACK, >> >> Yes. >> >>> which themselves are accepted or not via the active side's ACK >>> of the passive sides SYN-ACK? >> >> You get more option space at that point. You don't (IMO) get to start >> another round of option negotiation - that's a 4WHS. > > Is there anything technical standing in the way of letting the server > introduce an option on the SYN-ACK that gets accepted by the client via > an option carried in the ACK of the SYN-ACK? Yes. You need a 4th state - a SYN-ACK-ACK to know that the SYN-ACK's new options are confirmed. However, even if you did that, you still didn't increase the space of the first SYN -- and *that* is where the challenge lies. >>> It becomes rather a rather kludgy layer violation, but how flexible are >>> IPv6 optional headers? >> >> That won't work through a NAT, AFAICT. NATs wouldn't know to look for >> the option, and thus would interpret the TCP header conventionally (and >> thus misinterpret the extended option space as data). > > I wasn't thinking of putting TCP options in the data portion of the TCP > segment, I was thinking of stuffing them into an IPv6 extension header. > (and got my terms wrong at first) With a "see the appropriate IPv6 > extension header for more TCP options" option in the TCP header. Abuse > Destination Options perhaps? Or add something new akin to the > Fragmentation Header? It could easily be a new option, but the problem is that some stacks might be very difficult to modify to support this. They expect that all IP options are processed before TCP touches the packet. It would be very difficult to set the option at the IP layer to operate on different TCP connections differently too. Can't see how to do that at all, FWIW. It also might interact with NATs badly, AFAICT. Joe From william.allen.simpson@gmail.com Wed Aug 31 11:11:42 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F020821F8E62 for ; Wed, 31 Aug 2011 11:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQ46CvsCqbOr for ; Wed, 31 Aug 2011 11:11:41 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id C49FF21F8E2F for ; Wed, 31 Aug 2011 11:11:33 -0700 (PDT) Received: by yie12 with SMTP id 12so993402yie.31 for ; Wed, 31 Aug 2011 11:13:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=p0rglDNr3FhuBVfwCajTBA32Ao7bgRtACH0wjmeXKvE=; b=LQ744dLqy45y8Oxgsv+IvcDvYAR7/Q+LfQ3AfE3+w1ugz2bMlHDWVeQZT6wMTCeKnV gXXKUTr6yQUh1n+peSP6j1HVoRwDYMGwuWm9l/Hapu3r7cimCSNmFlW+DG88lRLCdXh5 GgR8zSSKjCAhvhUNfcDGyr3GzDeHqn0N3iPfo= Received: by 10.236.185.138 with SMTP id u10mr3961822yhm.67.1314814383659; Wed, 31 Aug 2011 11:13:03 -0700 (PDT) Received: from Wastrel-3.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id a29sm1488851yhj.59.2011.08.31.11.13.01 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 31 Aug 2011 11:13:02 -0700 (PDT) Message-ID: <4E5E79AC.6030605@gmail.com> Date: Wed, 31 Aug 2011 14:13:00 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.21) Gecko/20110830 Thunderbird/3.1.13 MIME-Version: 1.0 To: Pasi Sarolahti References: <9605EAA4-F1C4-4D83-B76E-88C81BFE1555@iki.fi> In-Reply-To: <9605EAA4-F1C4-4D83-B76E-88C81BFE1555@iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 18:11:42 -0000 On 8/31/11 9:57 AM, Pasi Sarolahti wrote: > TCP's option space has been under increasing demand recently, with new option-space hungry extensions such as MPTCP, and some recent ideas in the research domain. In the past there have been some discussion about mechanisms to extend the option space, and an extension option was proposed in draft-eddy-tcp-loo, but since then these efforts have died down. I'm wondering if there would be any interest in the tcpm community to resume this work. > Already done, already tested. RFC-6013. > I recall that re-segmenting middleboxes were mentioned as one potential problem for such extension, and there might be other problems. Nevertheless, I would find it useful, if there was an RFC that a) documented the known problems with option space extension; and b) defined an option format and assigned the needed type codes, to enable experimentations with larger than 40-byte option space. > I'm using options 31 and 32. See https://tools.ietf.org/html/draft-simpson-tcpct-api-04 > Thoughts? > Always happy to have additional experimenters. Not talkers, implementers. From wes@mti-systems.com Wed Aug 31 12:03:27 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D6921F8D65 for ; Wed, 31 Aug 2011 12:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlIvTe8kWCNl for ; Wed, 31 Aug 2011 12:03:08 -0700 (PDT) Received: from omr13.networksolutionsemail.com (omr13.networksolutionsemail.com [205.178.146.63]) by ietfa.amsl.com (Postfix) with ESMTP id 7281521F8E75 for ; Wed, 31 Aug 2011 12:03:08 -0700 (PDT) Received: from cm-omr8 (mail.networksolutionsemail.com [205.178.146.50]) by omr13.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p7VJ4a9j029858 for ; Wed, 31 Aug 2011 15:04:38 -0400 Authentication-Results: cm-omr8 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [184.224.28.79] ([184.224.28.79:12566] helo=[68.245.171.115]) by cm-omr8 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 4C/94-11933-3C58E5E4; Wed, 31 Aug 2011 15:04:36 -0400 Message-ID: <4E5E85C4.7060409@mti-systems.com> Date: Wed, 31 Aug 2011 15:04:36 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: tcpm@ietf.org References: <4E5E608E.3060006@hp.com> In-Reply-To: <4E5E608E.3060006@hp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 19:03:27 -0000 On 8/31/2011 12:25 PM, Rick Jones wrote: > On 08/31/2011 09:08 AM, Tim Shepard wrote: >> >> >>> If anyone sees a way around #2, please speak up. My recollection is that >>> we've dragged this dog around the block every few years, and realize the >>> same thing: >>> >>> TCP SYN option space cannot be extended >>> >>> There may be use to extending the space after the SYNs (someone can >>> propose that), but doing it in the SYNs doesn't appear to be possible. >> >> I think the space could be extended on the SYN-ACK if there was >> something on the SYN that indicated that the initiator could handle >> it. Just not on the initial SYN. (Middle boxes: grumble. >> Simultaneous open: uh huh.) > > So, active side says "I understand an extended set of options and can > confirm them on my ACK of your SYN-ACK" and then when the passive side > understands it, it gets to initiate options by introducing them with the > SYN-ACK, which themselves are accepted or not via the active side's ACK > of the passive sides SYN-ACK? Actually, this is the way that the SLO option works in the document that Pasi mentioned. It comes in on the ACK at the end of the 3WHS in order to indicate options that should be processed as if the SYN bit was set. I'd been using that around 2004/2005 in Linux and it was mostly a matter of redirecting the options processing to a different function within the kernel if SLO appeared on the ACK. -- Wes Eddy MTI Systems From micchie@sfc.wide.ad.jp Wed Aug 31 12:13:16 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 164CB21F8F2D for ; Wed, 31 Aug 2011 12:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyuN9jeG-hy7 for ; Wed, 31 Aug 2011 12:13:15 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 3435F21F8F1C for ; Wed, 31 Aug 2011 12:13:12 -0700 (PDT) Received: from [IPv6:2001:200:1c0:2800:78af:ea1:4c58:405c] (unknown [IPv6:2001:200:1c0:2800:78af:ea1:4c58:405c]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 82ECC278091; Thu, 1 Sep 2011 04:14:12 +0900 (JST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Michio Honda In-Reply-To: <4E5E79AC.6030605@gmail.com> Date: Thu, 1 Sep 2011 04:14:15 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <350D177D-8A25-4339-AC68-32CEC48EAC9E@sfc.wide.ad.jp> References: <9605EAA4-F1C4-4D83-B76E-88C81BFE1555@iki.fi> <4E5E79AC.6030605@gmail.com> To: William Allen Simpson X-Mailer: Apple Mail (2.1244.3) Cc: tcpm@ietf.org Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 19:13:16 -0000 Hi,=20 We have some middlebox data for this topic. =20 On Sep 1, 2011, at 3:13 AM, William Allen Simpson wrote: >=20 >> I recall that re-segmenting middleboxes were mentioned as one = potential problem for such extension, and there might be other problems. = Nevertheless, I would find it useful, if there was an RFC that a) = documented the known problems with option space extension; and b) = defined an option format and assigned the needed type codes, to enable = experimentations with larger than 40-byte option space. >>=20 > I'm using options 31 and 32. See > https://tools.ietf.org/html/draft-simpson-tcpct-api-04 In our middlebox measurement of 142 paths, all re-segmenting middleboxes = don't allow TCP options (they are transparent proxies) except for one = path. However, this path did not re-segment packets when options were = present. =20 Another problem is consistency of retransmissions. =20 We observed some middleboxes that cache segments and probably use these = for retransmissions. =20 Our test performs retransmissions with different payload from the = original segment. =20 On some paths, retransmitted segments did not reach the receiver. =20 Therefore, if we retransmit segment with different option kinds or = values in the payload, it might not reach the receiver. =20 Middleboxes that aware of known option are also problematic. =20 We observed some middleboxes that pass options and modifying sequence = numbers. =20 If we put SACK block in payload, such middleboxes won't rewrite sequence = numbers in payload. =20 I also performed SYN with payload test, which transmits such SYN to 500 = websites in Alexa Top sites.=20 494 sites responded to regular SYN 483 accepted SYN with payload (i.e., returned regular SYN/ACK)=20 10 did not responded. =20 1 reset the connection. =20 Thanks, - Michio >=20 >=20 >> Thoughts? >>=20 > Always happy to have additional experimenters. Not talkers, = implementers. > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From hkchu@google.com Wed Aug 31 12:26:34 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C800521F8E3E for ; Wed, 31 Aug 2011 12:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.427 X-Spam-Level: X-Spam-Status: No, score=-105.427 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+yB4CA9Gr8o for ; Wed, 31 Aug 2011 12:26:34 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id C73DC21F8E3A for ; Wed, 31 Aug 2011 12:26:33 -0700 (PDT) Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id p7VJS3IN023993 for ; Wed, 31 Aug 2011 12:28:04 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314818884; bh=2zVH4svpR/u4RNDtLk4FNKkoq9Y=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=FVjIrRApE+lZmGPknDZFVTqT3TmxzbUGan4u/AJEHrNS5F467tMrckFva2RliyHbw g2TUiwOPlJLGhAVBIocYQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=JwUfATHRhyclewYEN80F3PFsgoBt9KbZCaizZVQN4bF6hGJrRWX5DyxKwuRFZP/ag Wyt8MjYBrQrzfC9Z9AdcA== Received: from qyk35 (qyk35.prod.google.com [10.241.83.163]) by hpaq2.eem.corp.google.com with ESMTP id p7VJRdEB019564 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 31 Aug 2011 12:28:02 -0700 Received: by qyk35 with SMTP id 35so696378qyk.10 for ; Wed, 31 Aug 2011 12:28:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6AlqJqYuxEQRtkBbyHVHBQEyuwxwP2V4evUdztctuQg=; b=XhWKSYPk2DY8wDTYUnNDK0edGXeWCfQ8cOnT4BHWUywCpSFugHTeC+iuvDBLyROoEr AkdoGGxTOm/ux7TXB87w== Received: by 10.229.189.202 with SMTP id df10mr613356qcb.257.1314818880799; Wed, 31 Aug 2011 12:28:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.189.202 with SMTP id df10mr613334qcb.257.1314818879391; Wed, 31 Aug 2011 12:27:59 -0700 (PDT) Received: by 10.229.134.137 with HTTP; Wed, 31 Aug 2011 12:27:59 -0700 (PDT) In-Reply-To: <4E5E6A78.3070308@isi.edu> References: <4E5E608E.3060006@hp.com> <4E5E62D0.5080302@isi.edu> <4E5E6835.3010604@hp.com> <4E5E6A78.3070308@isi.edu> Date: Wed, 31 Aug 2011 12:27:59 -0700 Message-ID: From: Jerry Chu To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: tcpm@ietf.org, Tim Shepard Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 19:26:34 -0000 On Wed, Aug 31, 2011 at 10:08 AM, Joe Touch wrote: > > > On 8/31/2011 9:58 AM, Rick Jones wrote: >>>> >>>> So, active side says "I understand an extended set of options and can >>>> confirm them on my ACK of your SYN-ACK" and then when the passive side >>>> understands it, it gets to initiate options by introducing them with the >>>> SYN-ACK, >>> >>> Yes. >>> >>>> which themselves are accepted or not via the active side's ACK >>>> of the passive sides SYN-ACK? >>> >>> You get more option space at that point. You don't (IMO) get to start >>> another round of option negotiation - that's a 4WHS. >> >> Is there anything technical standing in the way of letting the server >> introduce an option on the SYN-ACK that gets accepted by the client via >> an option carried in the ACK of the SYN-ACK? > > Yes. You need a 4th state - a SYN-ACK-ACK to know that the SYN-ACK's new > options are confirmed. > > However, even if you did that, you still didn't increase the space of the > first SYN -- and *that* is where the challenge lies. But that is mostly academic if one considers the last handshake in the 4WHS to be an extension of the 3WHS for completing the option negotiation, no? The endhosts won't seem to care which side initiates a particular option, nor which round of HS is the option negotiated, except it will cost one additional roundtrip. (Well if a given option is not required before the data phase then it can be piggyback'ed on data pkt to get the reliable delivery.) It may break middleboxes that assume options are always initiated by the active open side though. Jerry > >>>> It becomes rather a rather kludgy layer violation, but how flexible are >>>> IPv6 optional headers? >>> >>> That won't work through a NAT, AFAICT. NATs wouldn't know to look for >>> the option, and thus would interpret the TCP header conventionally (and >>> thus misinterpret the extended option space as data). >> >> I wasn't thinking of putting TCP options in the data portion of the TCP >> segment, I was thinking of stuffing them into an IPv6 extension header. >> (and got my terms wrong at first) With a "see the appropriate IPv6 >> extension header for more TCP options" option in the TCP header. Abuse >> Destination Options perhaps? Or add something new akin to the >> Fragmentation Header? > > It could easily be a new option, but the problem is that some stacks might > be very difficult to modify to support this. They expect that all IP options > are processed before TCP touches the packet. > > It would be very difficult to set the option at the IP layer to operate on > different TCP connections differently too. Can't see how to do that at all, > FWIW. > > It also might interact with NATs badly, AFAICT. > > Joe > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From hkchu@google.com Wed Aug 31 12:36:31 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B1221F8DAD for ; Wed, 31 Aug 2011 12:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.916 X-Spam-Level: X-Spam-Status: No, score=-105.916 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jY+enqAYl6v for ; Wed, 31 Aug 2011 12:36:30 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id F37D621F8DA3 for ; Wed, 31 Aug 2011 12:36:29 -0700 (PDT) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id p7VJbu8h007616 for ; Wed, 31 Aug 2011 12:37:56 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314819477; bh=Ak2y1v2I5/Q6MhL/gWBGVuxnZi0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=vuku3CE9bylmXVKuH3m9H+NlIjpw7V5/T0IHvxSM0Q2ZPv5Ec4Oy5Gc26Bo0Thb2o AvoFZUrvepznQ+hFGXm0Q== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=xHyCMjttx5iE6aXgq8q+Yjn+4n0AO91SyZ13P4EwRTetakCbMj8r/iecQQxdRvP0Q fYRmLANUn5jFcEhbOefmg== Received: from qyk30 (qyk30.prod.google.com [10.241.83.158]) by hpaq14.eem.corp.google.com with ESMTP id p7VJbmTv006517 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 31 Aug 2011 12:37:55 -0700 Received: by qyk30 with SMTP id 30so794368qyk.9 for ; Wed, 31 Aug 2011 12:37:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fq5TrVwGQ9E8uoQRfg46UX1b2vlPitiZ3qoyF4JLJIo=; b=QIkYB46v6I1hRco8aQf1SnmJmXIB4POrNzsKHUIIWpO6Fk4TTjFrWcKcRJNL6HPzxO ZCoCLUg/nxiRJEzacd7w== Received: by 10.229.49.198 with SMTP id w6mr627671qcf.219.1314819475064; Wed, 31 Aug 2011 12:37:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.49.198 with SMTP id w6mr627664qcf.219.1314819474708; Wed, 31 Aug 2011 12:37:54 -0700 (PDT) Received: by 10.229.134.137 with HTTP; Wed, 31 Aug 2011 12:37:54 -0700 (PDT) In-Reply-To: <350D177D-8A25-4339-AC68-32CEC48EAC9E@sfc.wide.ad.jp> References: <9605EAA4-F1C4-4D83-B76E-88C81BFE1555@iki.fi> <4E5E79AC.6030605@gmail.com> <350D177D-8A25-4339-AC68-32CEC48EAC9E@sfc.wide.ad.jp> Date: Wed, 31 Aug 2011 12:37:54 -0700 Message-ID: From: Jerry Chu To: Michio Honda Content-Type: multipart/alternative; boundary=001636426a2fbbdb2504abd24311 X-System-Of-Record: true Cc: tcpm@ietf.org Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 19:36:31 -0000 --001636426a2fbbdb2504abd24311 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Aug 31, 2011 at 12:14 PM, Michio Honda wrote: > Hi, > > We have some middlebox data for this topic. > > On Sep 1, 2011, at 3:13 AM, William Allen Simpson wrote: > > > >> I recall that re-segmenting middleboxes were mentioned as one potential > problem for such extension, and there might be other problems. Nevertheless, > I would find it useful, if there was an RFC that a) documented the known > problems with option space extension; and b) defined an option format and > assigned the needed type codes, to enable experimentations with larger than > 40-byte option space. > >> > > I'm using options 31 and 32. See > > https://tools.ietf.org/html/draft-simpson-tcpct-api-04 > In our middlebox measurement of 142 paths, all re-segmenting middleboxes > don't allow TCP options (they are transparent proxies) except for one path. > However, this path did not re-segment packets when options were present. > > Another problem is consistency of retransmissions. > We observed some middleboxes that cache segments and probably use these for > retransmissions. > Our test performs retransmissions with different payload from the original > segment. > On some paths, retransmitted segments did not reach the receiver. > Therefore, if we retransmit segment with different option kinds or values > in the payload, it might not reach the receiver. > > Middleboxes that aware of known option are also problematic. > We observed some middleboxes that pass options and modifying sequence > numbers. > If we put SACK block in payload, such middleboxes won't rewrite sequence > numbers in payload. > > I also performed SYN with payload test, which transmits such SYN to 500 > websites in Alexa Top sites. > 494 sites responded to regular SYN > 483 accepted SYN with payload (i.e., returned regular SYN/ACK) > What's the difference between the two above (responded to vs accepted)? Thanks, Jerry > 10 did not responded. > 1 reset the connection. > > Thanks, > - Michio > > > > > >> Thoughts? > >> > > Always happy to have additional experimenters. Not talkers, > implementers. > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --001636426a2fbbdb2504abd24311 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Aug 31, 2011 at 12:14 PM, Michio= Honda <micc= hie@sfc.wide.ad.jp> wrote:
Hi,

We have some middlebox data for this topic.

On Sep 1, 2011, at 3:13 AM, William Allen Simpson wrote:
>
>> I recall that re-segmenting middleboxes were mentioned as one pote= ntial problem for such extension, and there might be other problems. Nevert= heless, I would find it useful, if there was an RFC that a) documented the = known problems with option space extension; and b) defined an option format= and assigned the needed type codes, to enable experimentations with larger= than 40-byte option space.
>>
> I'm using options 31 and 32. =A0See
> =A0https://tools.ietf.org/html/draft-simpson-tcpct-api-04
In our middlebox measurement of 142 paths, all re-segmenting middlebo= xes don't allow TCP options (they are transparent proxies) except for o= ne path. =A0However, this path did not re-segment packets when options were= present.

Another problem is consistency of retransmissions.
We observed some middleboxes that cache segments and probably use these for= retransmissions.
Our test performs retransmissions with different payload from the original = segment.
On some paths, retransmitted segments did not reach the receiver.
Therefore, if we retransmit segment with different option kinds or values i= n the payload, it might not reach the receiver.

Middleboxes that aware of known option are also problematic.
We observed some middleboxes that pass options and modifying sequence numbe= rs.
If we put SACK block in payload, such middleboxes won't rewrite sequenc= e numbers in payload.

I also performed SYN with payload test, which transmits such SYN to 500 web= sites in Alexa Top sites.
494 sites responded to regular SYN
483 accepted SYN with payload (i.e., returned regular SYN/ACK)

What's the difference between the two above (re= sponded to vs accepted)?

Thanks,

Jerry
=A0
10 did not responded.
1 reset the connection.

Thanks,
- Michio
>
>
>> Thoughts?
>>
> Always happy to have additional experimenters. =A0Not talkers, impleme= nters.
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm

--001636426a2fbbdb2504abd24311-- From michawe@ifi.uio.no Wed Aug 31 12:37:42 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8897621F8DC2 for ; Wed, 31 Aug 2011 12:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ge5ULk6ZHBl2 for ; Wed, 31 Aug 2011 12:37:42 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id D47DC21F8F35 for ; Wed, 31 Aug 2011 12:37:41 -0700 (PDT) Received: from mail-mx5.uio.no ([129.240.10.46]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1Qyqcx-0007ud-H8; Wed, 31 Aug 2011 21:39:11 +0200 Received: from cm-84.208.175.27.getinternet.no ([84.208.175.27] helo=[192.168.0.198]) by mail-mx5.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.76) (envelope-from ) id 1Qyqcx-0005xX-1x; Wed, 31 Aug 2011 21:39:11 +0200 Message-Id: <039B4E40-9942-48E5-A129-CCD1FB116D03@ifi.uio.no> From: Michael Welzl To: Michio Honda In-Reply-To: <350D177D-8A25-4339-AC68-32CEC48EAC9E@sfc.wide.ad.jp> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 31 Aug 2011 21:38:48 +0200 References: <9605EAA4-F1C4-4D83-B76E-88C81BFE1555@iki.fi> <4E5E79AC.6030605@gmail.com> <350D177D-8A25-4339-AC68-32CEC48EAC9E@sfc.wide.ad.jp> X-Mailer: Apple Mail (2.936) X-UiO-Ratelimit-Test: rcpts/h 11 msgs/h 7 sum rcpts/h 13 sum msgs/h 8 total rcpts 12427 max rcpts/h 36 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: A48034A2674227964D5BFC2D142828C563B2F3BE X-UiO-SPAM-Test: remote_host: 84.208.175.27 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 7 total 1908 max/h 18 blacklist 0 greylist 0 ratelimit 0 Cc: tcpm@ietf.org Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 19:37:42 -0000 On Aug 31, 2011, at 9:14 PM, Michio Honda wrote: > I also performed SYN with payload test, which transmits such SYN to > 500 websites in Alexa Top sites. Poor them! Did it ever occur to you how much rubbish must get shot at these sites? :-) They must get the strangest traffic, originating from all over the world! (yes of course I'm aware that most or all of these are not represented by one single poor computer standing in a terminal room somewhere... it's still a funny thought to me) Michael From micchie@sfc.wide.ad.jp Wed Aug 31 12:48:08 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF57521F8F83 for ; Wed, 31 Aug 2011 12:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1WXOyIiqrdY for ; Wed, 31 Aug 2011 12:48:08 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 070D521F8F86 for ; Wed, 31 Aug 2011 12:48:07 -0700 (PDT) Received: from [IPv6:2001:200:1c0:2800:78af:ea1:4c58:405c] (unknown [IPv6:2001:200:1c0:2800:78af:ea1:4c58:405c]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 5D04B278067; Thu, 1 Sep 2011 04:49:08 +0900 (JST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Michio Honda In-Reply-To: Date: Thu, 1 Sep 2011 04:49:11 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <8BB37A39-745C-4106-934B-4581BBBB4ACA@sfc.wide.ad.jp> References: <9605EAA4-F1C4-4D83-B76E-88C81BFE1555@iki.fi> <4E5E79AC.6030605@gmail.com> <350D177D-8A25-4339-AC68-32CEC48EAC9E@sfc.wide.ad.jp> To: Jerry Chu X-Mailer: Apple Mail (2.1244.3) Cc: tcpm@ietf.org Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 19:48:08 -0000 On Sep 1, 2011, at 4:37 AM, Jerry Chu wrote: >=20 >=20 > On Wed, Aug 31, 2011 at 12:14 PM, Michio Honda = wrote: > Hi, >=20 > We have some middlebox data for this topic. >=20 > On Sep 1, 2011, at 3:13 AM, William Allen Simpson wrote: > > > >> I recall that re-segmenting middleboxes were mentioned as one = potential problem for such extension, and there might be other problems. = Nevertheless, I would find it useful, if there was an RFC that a) = documented the known problems with option space extension; and b) = defined an option format and assigned the needed type codes, to enable = experimentations with larger than 40-byte option space. > >> > > I'm using options 31 and 32. See > > https://tools.ietf.org/html/draft-simpson-tcpct-api-04 > In our middlebox measurement of 142 paths, all re-segmenting = middleboxes don't allow TCP options (they are transparent proxies) = except for one path. However, this path did not re-segment packets when = options were present. >=20 > Another problem is consistency of retransmissions. > We observed some middleboxes that cache segments and probably use = these for retransmissions. > Our test performs retransmissions with different payload from the = original segment. > On some paths, retransmitted segments did not reach the receiver. > Therefore, if we retransmit segment with different option kinds or = values in the payload, it might not reach the receiver. >=20 > Middleboxes that aware of known option are also problematic. > We observed some middleboxes that pass options and modifying sequence = numbers. > If we put SACK block in payload, such middleboxes won't rewrite = sequence numbers in payload. >=20 > I also performed SYN with payload test, which transmits such SYN to = 500 websites in Alexa Top sites. > 494 sites responded to regular SYN > 483 accepted SYN with payload (i.e., returned regular SYN/ACK) >=20 > What's the difference between the two above (responded to vs = accepted)? Sorry, it means that 494 responded to regular SYN (no payload) with = regular SYNACK. =20 In this 494, 483 responded to SYN including payload with regular = SYNACK. =20 Thanks, - Michio >=20 > Thanks, >=20 > Jerry > =20 > 10 did not responded. > 1 reset the connection. >=20 > Thanks, > - Michio > > > > > >> Thoughts? > >> > > Always happy to have additional experimenters. Not talkers, = implementers. > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 From touch@isi.edu Wed Aug 31 13:20:21 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6287721F8D2B for ; Wed, 31 Aug 2011 13:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.87 X-Spam-Level: X-Spam-Status: No, score=-102.87 tagged_above=-999 required=5 tests=[AWL=-0.871, BAYES_00=-2.599, J_CHICKENPOX_92=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztdrOOCaqmcc for ; Wed, 31 Aug 2011 13:20:20 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id D82B521F8CED for ; Wed, 31 Aug 2011 13:20:20 -0700 (PDT) Received: from [198.123.60.66] ([198.123.60.66]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p7VKLDjw001739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 Aug 2011 13:21:23 -0700 (PDT) Message-ID: <4E5E97B9.3070908@isi.edu> Date: Wed, 31 Aug 2011 13:21:13 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Jerry Chu References: <4E5E608E.3060006@hp.com> <4E5E62D0.5080302@isi.edu> <4E5E6835.3010604@hp.com> <4E5E6A78.3070308@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Tim Shepard Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 20:20:21 -0000 Hi, Jerry, On 8/31/2011 12:27 PM, Jerry Chu wrote: > On Wed, Aug 31, 2011 at 10:08 AM, Joe Touch wrote: ... >>> Is there anything technical standing in the way of letting the server >>> introduce an option on the SYN-ACK that gets accepted by the client via >>> an option carried in the ACK of the SYN-ACK? >> >> Yes. You need a 4th state - a SYN-ACK-ACK to know that the SYN-ACK's new >> options are confirmed. >> >> However, even if you did that, you still didn't increase the space of the >> first SYN -- and *that* is where the challenge lies. > > But that is mostly academic if one considers the last handshake in the 4WHS to > be an extension of the 3WHS for completing the option negotiation, no? You need to distinguish between the SYN-ACK, the first message received after the SYN-ACK, the message sent, and the other messages sent and received. You can't simply transition from SYN-RECEIVED or SYN-SENT to ESTABLISHED - you need another state. That other state is the problem - NATs don't implement it yet, so you will have trouble traversing it. If the messages between get split, do the options get copied, etc. This is the (continuing) problem with state coordination after the 3WHS. It requires more states, which is incompatible with any middlebox (relay, NAT, etc.) that doesn't have those states. It also makes it very difficult to implement, and can require a lot of care to avoid impacting the robustness of the current state diagram (not to mention dealing with simultaneous opens). > The > endhosts won't seem to care which side initiates a particular option, Agreed. > nor which > round of HS is the option negotiated, except it will cost one > additional roundtrip. Disagreed as per above. > (Well if a given option is not required before the data phase then it can be > piggyback'ed on data pkt to get the reliable delivery.) If it were only that simple. TCP signalling is not reliable; it is the data that is reliable. > It may break middleboxes that assume options are always initiated by the active > open side though. That's a completely different issue that may further complicate things... Joe > > Jerry > >> >>>>> It becomes rather a rather kludgy layer violation, but how flexible are >>>>> IPv6 optional headers? >>>> >>>> That won't work through a NAT, AFAICT. NATs wouldn't know to look for >>>> the option, and thus would interpret the TCP header conventionally (and >>>> thus misinterpret the extended option space as data). >>> >>> I wasn't thinking of putting TCP options in the data portion of the TCP >>> segment, I was thinking of stuffing them into an IPv6 extension header. >>> (and got my terms wrong at first) With a "see the appropriate IPv6 >>> extension header for more TCP options" option in the TCP header. Abuse >>> Destination Options perhaps? Or add something new akin to the >>> Fragmentation Header? >> >> It could easily be a new option, but the problem is that some stacks might >> be very difficult to modify to support this. They expect that all IP options >> are processed before TCP touches the packet. >> >> It would be very difficult to set the option at the IP layer to operate on >> different TCP connections differently too. Can't see how to do that at all, >> FWIW. >> >> It also might interact with NATs badly, AFAICT. >> >> Joe >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> From touch@isi.edu Wed Aug 31 13:26:19 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 004B021F8DE1 for ; Wed, 31 Aug 2011 13:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.062 X-Spam-Level: X-Spam-Status: No, score=-105.062 tagged_above=-999 required=5 tests=[AWL=1.538, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0LD9sS+pIE9 for ; Wed, 31 Aug 2011 13:26:18 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 758BB21F8D24 for ; Wed, 31 Aug 2011 13:26:18 -0700 (PDT) Received: from [198.123.60.66] ([198.123.60.66]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p7VKQoN4003363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 Aug 2011 13:26:59 -0700 (PDT) Message-ID: <4E5E990A.5090804@isi.edu> Date: Wed, 31 Aug 2011 13:26:50 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: William Allen Simpson References: <9605EAA4-F1C4-4D83-B76E-88C81BFE1555@iki.fi> <4E5E79AC.6030605@gmail.com> In-Reply-To: <4E5E79AC.6030605@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 20:26:19 -0000 On 8/31/2011 11:13 AM, William Allen Simpson wrote: ... >> I recall that re-segmenting middleboxes were mentioned as one >> potential problem for such extension, and there might be other >> problems. Nevertheless, I would find it useful, if there was an RFC >> that a) documented the known problems with option space extension; and >> b) defined an option format and assigned the needed type codes, to >> enable experimentations with larger than 40-byte option space. >> > I'm using options 31 and 32. See > https://tools.ietf.org/html/draft-simpson-tcpct-api-04 Thanks for letting us know. I'll let IANA to mark those as (further) unauthorized uses. In the meantime, please stop and use the experimental options until you get an assignment, IMO. Joe From touch@isi.edu Wed Aug 31 13:43:00 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7792521F8E84 for ; Wed, 31 Aug 2011 13:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.232 X-Spam-Level: X-Spam-Status: No, score=-103.232 tagged_above=-999 required=5 tests=[AWL=-0.633, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWDWSK+cn5Ef for ; Wed, 31 Aug 2011 13:43:00 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 0327021F8E7B for ; Wed, 31 Aug 2011 13:42:59 -0700 (PDT) Received: from [198.123.60.66] ([198.123.60.66]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id p7VKi61I006168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 Aug 2011 13:44:09 -0700 (PDT) Message-ID: <4E5E9D16.9090200@isi.edu> Date: Wed, 31 Aug 2011 13:44:06 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: William Allen Simpson References: <9605EAA4-F1C4-4D83-B76E-88C81BFE1555@iki.fi> <4E5E79AC.6030605@gmail.com> In-Reply-To: <4E5E79AC.6030605@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 20:43:00 -0000 Some further clarification: On 8/31/2011 11:13 AM, William Allen Simpson wrote: > On 8/31/11 9:57 AM, Pasi Sarolahti wrote: >> TCP's option space has been under increasing demand recently, with new >> option-space hungry extensions such as MPTCP, and some recent ideas in >> the research domain. In the past there have been some discussion about >> mechanisms to extend the option space, and an extension option was >> proposed in draft-eddy-tcp-loo, but since then these efforts have died >> down. I'm wondering if there would be any interest in the tcpm >> community to resume this work. >> > Already done, already tested. RFC-6013. This extends options after then SYN exchange. That has always been trivial, but doesn't address the SYN space. I.e., this is Wed Eddy's LO, not SLO. >> I recall that re-segmenting middleboxes were mentioned as one >> potential problem for such extension, and there might be other >> problems. Nevertheless, I would find it useful, if there was an RFC >> that a) documented the known problems with option space extension; and >> b) defined an option format and assigned the needed type codes, to >> enable experimentations with larger than 40-byte option space. Experiments SHOULD be using options 253 and 254, as per RFC 4727; i.e., those option numbers are already available for experiments. Joe From hkchu@google.com Wed Aug 31 14:04:24 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1EEB21F8F50 for ; Wed, 31 Aug 2011 14:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.327 X-Spam-Level: X-Spam-Status: No, score=-105.327 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_52=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NItt-GJDl4To for ; Wed, 31 Aug 2011 14:04:24 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 478F921F8F4A for ; Wed, 31 Aug 2011 14:04:23 -0700 (PDT) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id p7VL5ros022012 for ; Wed, 31 Aug 2011 14:05:53 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314824753; bh=wQkrqikAdsY3rn6xLqel7NslODk=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=CWsBd4q9hvboVcmXb7PHQes6BhwBPv+WE+UYUkq1XYAsuOVY/61JnhmLLyrUM6kss P5H3n3KxMdi6xO3Q7Re4g== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=PpD0NisNQZ6MzI93OJCes1lby52uMOvfxWETt630Mz7kwcAArkJnwlh5BTzX7okVY NH8JMhioBQoY+4/xo6jeQ== Received: from qwj8 (qwj8.prod.google.com [10.241.195.72]) by wpaz29.hot.corp.google.com with ESMTP id p7VL36LA003049 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 31 Aug 2011 14:05:51 -0700 Received: by qwj8 with SMTP id 8so933707qwj.18 for ; Wed, 31 Aug 2011 14:05:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=2egOhgr+h1VzWHYpIkOvQ5l7czcZXpGdZWjO+WzRD2s=; b=mrKPntwPoIlgAllEdhDjWfGxLh0qYbDU/pNUqVkSCVt7GpvCyw4+dw046ElN+Aw9U+ IRghn5p+LNxYihy4M52g== Received: by 10.229.189.202 with SMTP id df10mr694523qcb.257.1314824751225; Wed, 31 Aug 2011 14:05:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.189.202 with SMTP id df10mr694512qcb.257.1314824750774; Wed, 31 Aug 2011 14:05:50 -0700 (PDT) Received: by 10.229.134.137 with HTTP; Wed, 31 Aug 2011 14:05:50 -0700 (PDT) In-Reply-To: <4E5E97B9.3070908@isi.edu> References: <4E5E608E.3060006@hp.com> <4E5E62D0.5080302@isi.edu> <4E5E6835.3010604@hp.com> <4E5E6A78.3070308@isi.edu> <4E5E97B9.3070908@isi.edu> Date: Wed, 31 Aug 2011 14:05:50 -0700 Message-ID: From: Jerry Chu To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: tcpm@ietf.org, Tim Shepard Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 21:04:24 -0000 Hi Joe, On Wed, Aug 31, 2011 at 1:21 PM, Joe Touch wrote: > Hi, Jerry, > > On 8/31/2011 12:27 PM, Jerry Chu wrote: >> >> On Wed, Aug 31, 2011 at 10:08 AM, Joe Touch =A0wrote: > > ... >>>> >>>> Is there anything technical standing in the way of letting the server >>>> introduce an option on the SYN-ACK that gets accepted by the client vi= a >>>> an option carried in the ACK of the SYN-ACK? >>> >>> Yes. You need a 4th state - a SYN-ACK-ACK to know that the SYN-ACK's ne= w >>> options are confirmed. >>> >>> However, even if you did that, you still didn't increase the space of t= he >>> first SYN -- and *that* is where the challenge lies. >> >> But that is mostly academic if one considers the last handshake in the >> 4WHS to >> be an extension of the 3WHS for completing the option negotiation, no? > > You need to distinguish between the SYN-ACK, the first message received > after the SYN-ACK, the message sent, and the other messages sent and > received. You can't simply transition from SYN-RECEIVED or SYN-SENT to > ESTABLISHED - you need another state. Guess it depends on what you're trying to achieve. Since it takes two sides= to agree upon an option, it may be less important which side initiates an opti= on negotiation hence the space of the first SYN. Options initiated by SYN-ACK will be ack'ed by a pure ack or piggy'ed back through a data segment but either way it won't hold off data transmission f= rom the active side because it already knows what options have been agreed upon= . > > That other state is the problem - NATs don't implement it yet, so you wil= l > have trouble traversing it. If the messages between get split, do the > options get copied, etc. Correct NAT won't understand this passive-open side initiated option negoti= ation but I wonder if it's any worse than an unknown option. Ok, unknown option o= n data segments will suffer a higher (3% per Mark Allman) failure rate. If on= e avoids tagging the 1st data segment with options then one must rely exclusi= vely on a pure ACK, which is not reliably delivered so one can not use this mechanism for options that must be negotiated reliably. > > This is the (continuing) problem with state coordination after the 3WHS. = It > requires more states, which is incompatible with any middlebox (relay, NA= T, > etc.) that doesn't have those states. It also makes it very difficult to > implement, and can require a lot of care to avoid impacting the robustnes= s > of the current state diagram (not to mention dealing with simultaneous > opens). See above. > >> The >> endhosts won't seem to care which side initiates a particular option, > > Agreed. > >> nor which >> >> round of HS is the option negotiated, except it will cost one >> additional roundtrip. > > Disagreed as per above. > >> (Well if a given option is not required before the data phase then it ca= n >> be >> piggyback'ed on data pkt to get the reliable delivery.) > > If it were only that simple. TCP signalling is not reliable; it is the da= ta > that is reliable. > >> It may break middleboxes that assume options are always initiated by the >> active >> open side though. > > That's a completely different issue that may further complicate things... Yup. Jerry > > Joe > >> >> Jerry >> >>> >>>>>> It becomes rather a rather kludgy layer violation, but how flexible >>>>>> are >>>>>> IPv6 optional headers? >>>>> >>>>> That won't work through a NAT, AFAICT. NATs wouldn't know to look for >>>>> the option, and thus would interpret the TCP header conventionally (a= nd >>>>> thus misinterpret the extended option space as data). >>>> >>>> I wasn't thinking of putting TCP options in the data portion of the TC= P >>>> segment, I was thinking of stuffing them into an IPv6 extension header= . >>>> (and got my terms wrong at first) With a "see the appropriate IPv6 >>>> extension header for more TCP options" option in the TCP header. Abuse >>>> Destination Options perhaps? Or add something new akin to the >>>> Fragmentation Header? >>> >>> It could easily be a new option, but the problem is that some stacks >>> might >>> be very difficult to modify to support this. They expect that all IP >>> options >>> are processed before TCP touches the packet. >>> >>> It would be very difficult to set the option at the IP layer to operate >>> on >>> different TCP connections differently too. Can't see how to do that at >>> all, >>> FWIW. >>> >>> It also might interact with NATs badly, AFAICT. >>> >>> Joe >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>> > From touch@isi.edu Wed Aug 31 14:14:03 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43DD921F8F50 for ; Wed, 31 Aug 2011 14:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.869 X-Spam-Level: X-Spam-Status: No, score=-104.869 tagged_above=-999 required=5 tests=[AWL=1.130, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkz600Wzv-Yi for ; Wed, 31 Aug 2011 14:14:02 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id BDDBE21F8F41 for ; Wed, 31 Aug 2011 14:14:02 -0700 (PDT) Received: from [198.123.60.66] ([198.123.60.66]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p7VLF66c013274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 Aug 2011 14:15:15 -0700 (PDT) Message-ID: <4E5EA45A.3090501@isi.edu> Date: Wed, 31 Aug 2011 14:15:06 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Jerry Chu References: <4E5E608E.3060006@hp.com> <4E5E62D0.5080302@isi.edu> <4E5E6835.3010604@hp.com> <4E5E6A78.3070308@isi.edu> <4E5E97B9.3070908@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Tim Shepard Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 21:14:03 -0000 On 8/31/2011 2:05 PM, Jerry Chu wrote: ... >> You need to distinguish between the SYN-ACK, the first message received >> after the SYN-ACK, the message sent, and the other messages sent and >> received. You can't simply transition from SYN-RECEIVED or SYN-SENT to >> ESTABLISHED - you need another state. > > Guess it depends on what you're trying to achieve. Since it takes two sides to > agree upon an option, it may be less important which side initiates an option > negotiation hence the space of the first SYN. The point is that if the first SYN doesn't indicate option support, then the 3WHS isn't going to synchronize the endpoints as to whether that option is supported. That's true regardless of which side initiates the connection. > Options initiated by SYN-ACK will be ack'ed by a pure ack or piggy'ed back > through a data segment but either way it won't hold off data transmission from > the active side because it already knows what options have been agreed upon. An option initiated by a SYN-ACK either: - was indicated in the SYN, and so confirms it to the initiator and the final ACK of the 3WHS confirms it to the responder - was initiated in the SYN-ACK which means either: A- the initiator didn't support it B- the initiator didn't have room to say it supported it A needs a NACK. B needs an ACK. That happens during the 3WHS. Another 4th message needs to complete the exchange, and needs to be reliably retransmitted if lost, etc. - that's what the TCP state machine is for. You can claim your implementation fudges around it, but you effectively need that state - with the timeouts, retransmissions, etc. - to make sure that last message is sent properly. AND how do you know when you can now use the option? When you're out of that last 4th state. Not before. >> That other state is the problem - NATs don't implement it yet, so you will >> have trouble traversing it. If the messages between get split, do the >> options get copied, etc. > > Correct NAT won't understand this passive-open side initiated option negotiation > but I wonder if it's any worse than an unknown option. Ok, unknown option on > data segments will suffer a higher (3% per Mark Allman) failure rate. If one > avoids tagging the 1st data segment with options then one must rely exclusively > on a pure ACK, which is not reliably delivered so one can not use this > mechanism for options that must be negotiated reliably. For a general option, it may not be much different. BUT you're redefining the option/data boundary with this option, which DOES interact badly with NATs that, e.g., ignore unknown options but still manipulate TCP packets. Joe From hkchu@google.com Wed Aug 31 16:28:12 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A779B21F8DAD for ; Wed, 31 Aug 2011 16:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.548 X-Spam-Level: X-Spam-Status: No, score=-105.548 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENZdy1B-dVEu for ; Wed, 31 Aug 2011 16:28:12 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id AF75F21F8DA8 for ; Wed, 31 Aug 2011 16:28:11 -0700 (PDT) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id p7VNTg3X002598 for ; Wed, 31 Aug 2011 16:29:42 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314833382; bh=41R9NIABRaJyktnAoW0HDBla4D4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=HTw/P8qjyJBdYDXfWWixHtYXsRumcRmZ/up/Q/aVXwzz2Q1GDtGLiwbaURn54Z3OQ g9dr4+3Lt4jbG+L7mUgcw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=MM5LOu3wvNwkaBZh5iDNsx0UrsOknUBFewj/+u0UF+wPM6ck6wLXT8XjYN/PqC0XI AKyoyrMzei29JOcC/gcxA== Received: from qwa26 (qwa26.prod.google.com [10.241.193.26]) by hpaq12.eem.corp.google.com with ESMTP id p7VNPugt028709 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 31 Aug 2011 16:29:41 -0700 Received: by qwa26 with SMTP id 26so757485qwa.14 for ; Wed, 31 Aug 2011 16:29:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Pj7gXD8gtFc1vL7tk4KiEejSccjgfQnSq4TS7ewUKZM=; b=V8tO+SkL6Jf+fyJubhDa2VPNiFuTqKpc/+ggFmyJiDAWY0qI852+Pzku5xorN+LsGJ DwKke52W5t2PFIdZjcnQ== Received: by 10.229.90.71 with SMTP id h7mr786893qcm.295.1314833376815; Wed, 31 Aug 2011 16:29:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.90.71 with SMTP id h7mr786886qcm.295.1314833376649; Wed, 31 Aug 2011 16:29:36 -0700 (PDT) Received: by 10.229.134.137 with HTTP; Wed, 31 Aug 2011 16:29:36 -0700 (PDT) In-Reply-To: <4E5EA45A.3090501@isi.edu> References: <4E5E608E.3060006@hp.com> <4E5E62D0.5080302@isi.edu> <4E5E6835.3010604@hp.com> <4E5E6A78.3070308@isi.edu> <4E5E97B9.3070908@isi.edu> <4E5EA45A.3090501@isi.edu> Date: Wed, 31 Aug 2011 16:29:36 -0700 Message-ID: From: Jerry Chu To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: tcpm@ietf.org, Tim Shepard Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 23:28:12 -0000 On Wed, Aug 31, 2011 at 2:15 PM, Joe Touch wrote: > > > On 8/31/2011 2:05 PM, Jerry Chu wrote: > ... >>> >>> You need to distinguish between the SYN-ACK, the first message received >>> after the SYN-ACK, the message sent, and the other messages sent and >>> received. You can't simply transition from SYN-RECEIVED or SYN-SENT to >>> ESTABLISHED - you need another state. >> >> Guess it depends on what you're trying to achieve. Since it takes two >> sides to >> agree upon an option, it may be less important which side initiates an >> option >> negotiation hence the space of the first SYN. > > The point is that if the first SYN doesn't indicate option support, then = the > 3WHS isn't going to synchronize the endpoints as to whether that option i= s > supported. That's true regardless of which side initiates the connection. I still think the final ack can be fudged to close the option negotiation loop. (See below.) But I just realized this thread seems to assume there is plenty room left for more options in SYN-ACK, and why is that? > >> Options initiated by SYN-ACK will be ack'ed by a pure ack or piggy'ed ba= ck >> through a data segment but either way it won't hold off data transmissio= n >> from >> the active side because it already knows what options have been agreed >> upon. > > An option initiated by a SYN-ACK either: > =A0 =A0 =A0 =A0- was indicated in the SYN, and so confirms it to the init= iator > =A0 =A0 =A0 =A0and the final ACK of the 3WHS confirms it to the responder > > =A0 =A0 =A0 =A0- was initiated in the SYN-ACK > =A0 =A0 =A0 =A0which means either: > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0A- the initiator didn't support it > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0B- the initiator didn't have room to say i= t supported it > > A needs a NACK. > > B needs an ACK. > > That happens during the 3WHS. > > Another 4th message needs to complete the exchange, and needs to be relia= bly > retransmitted if lost, etc. - that's what the TCP state machine is for. The final ack will serve this purpose. > > You can claim your implementation fudges around it, but you effectively n= eed > that state - with the timeouts, retransmissions, etc. - to make sure that > last message is sent properly. > > AND how do you know when you can now use the option? When you're out of t= hat > last 4th state. Not before. The active open side will have all the knowledge about what options/values = the passive open side proposes after receiving SYN-ACK option so is done with o= ption negotiation hence can begin the data transmission phase. The passive open s= ide will be waiting for the final ack of the 3WHS, either in the form of a pure ack, or as part of a data segment (i.e., the 1st data segment from the active open side). But either way the option will have been negotiated reliably too for the pa= ssive open side. More importantly, both sides will have the same understanding of options to use before the data phase. > >>> That other state is the problem - NATs don't implement it yet, so you >>> will >>> have trouble traversing it. If the messages between get split, do the >>> options get copied, etc. >> >> Correct NAT won't understand this passive-open side initiated option >> negotiation >> but I wonder if it's any worse than an unknown option. Ok, unknown optio= n >> on >> data segments will suffer a higher (3% per Mark Allman) failure rate. If >> one >> avoids tagging the 1st data segment with options then one must rely >> exclusively >> on a pure ACK, which is not reliably delivered so one can not use this >> mechanism for options that must be negotiated reliably. > > For a general option, it may not be much different. BUT you're redefining > the option/data boundary with this option, which DOES interact badly with > NATs that, e.g., ignore unknown options but still manipulate TCP packets. Just realized the reliable delivery of options I was concerned about is not= an issue. See above. Jerry > > Joe > From touch@isi.edu Wed Aug 31 16:36:25 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7D421F8559 for ; Wed, 31 Aug 2011 16:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.972 X-Spam-Level: X-Spam-Status: No, score=-102.972 tagged_above=-999 required=5 tests=[AWL=-0.973, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGaM4-q3TR5b for ; Wed, 31 Aug 2011 16:36:24 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7F321F851A for ; Wed, 31 Aug 2011 16:36:24 -0700 (PDT) Received: from [198.123.60.66] ([198.123.60.66]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p7VNbI93004824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 Aug 2011 16:37:28 -0700 (PDT) Message-ID: <4E5EC5AE.3090707@isi.edu> Date: Wed, 31 Aug 2011 16:37:18 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Jerry Chu References: <4E5E608E.3060006@hp.com> <4E5E62D0.5080302@isi.edu> <4E5E6835.3010604@hp.com> <4E5E6A78.3070308@isi.edu> <4E5E97B9.3070908@isi.edu> <4E5EA45A.3090501@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Tim Shepard Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 23:36:25 -0000 On 8/31/2011 4:29 PM, Jerry Chu wrote: ... >> The point is that if the first SYN doesn't indicate option support, then the >> 3WHS isn't going to synchronize the endpoints as to whether that option is >> supported. That's true regardless of which side initiates the connection. > > I still think the final ack can be fudged to close the option > negotiation loop. (See > below.) You can do a lot of things that end up creating an additional state, and you can lie to everyone that such state doesn't exist (a counter keeps track of the SEQNO of the SYN/ACK to know which ACK to check, etc.) - but it's got to be there. > But I just realized this thread seems to assume there is > plenty room left for > more options in SYN-ACK, and why is that? I think we expect that would be true only because the SYN had the "I understand long options" flag. At that point, the SYN/ACK can use the feature, in addition to acking it. However, this is NOT the case if the SYN/ACK introduces the option. Whatever segment introduces the option cannot use it yet. >>> Options initiated by SYN-ACK will be ack'ed by a pure ack or piggy'ed back >>> through a data segment but either way it won't hold off data transmission >>> from >>> the active side because it already knows what options have been agreed >>> upon. >> >> An option initiated by a SYN-ACK either: >> - was indicated in the SYN, and so confirms it to the initiator >> and the final ACK of the 3WHS confirms it to the responder >> >> - was initiated in the SYN-ACK >> which means either: >> A- the initiator didn't support it >> B- the initiator didn't have room to say it supported it >> >> A needs a NACK. >> >> B needs an ACK. >> >> That happens during the 3WHS. >> >> Another 4th message needs to complete the exchange, and needs to be reliably >> retransmitted if lost, etc. - that's what the TCP state machine is for. > > The final ack will serve this purpose. You need to flag that ACK as being handled differently from other ACKs - that's state. You also need to not use the option until the last ACK confirms it. That's state on the other end. Any intermediate node that doesn't emulate that state can mess things up - esp. if that ACK comes out of order to a subsequent packet that uses the option. The whole point of the state machine is to ensure that certain actions are gated on the handshake of certain packets. >> You can claim your implementation fudges around it, but you effectively need >> that state - with the timeouts, retransmissions, etc. - to make sure that >> last message is sent properly. >> >> AND how do you know when you can now use the option? When you're out of that >> last 4th state. Not before. > > The active open side will have all the knowledge about what options/values the > passive open side proposes after receiving SYN-ACK option so is done with option > negotiation hence can begin the data transmission phase. The passive open side > will be waiting for the final ack of the 3WHS, either in the form of a > pure ack, or > as part of a data segment (i.e., the 1st data segment from the active > open side). > But either way the option will have been negotiated reliably too for the passive > open side. More importantly, both sides will have the same understanding of > options to use before the data phase. Who says the final ACK can't include data? or the other segments (SYN, SYN/ACK)? Who says the final ACK can't be reordered with data that is going across? This is what the states are for, and why you basically need to add one to make this work (and why a NAT that doesn't have that state will cause things to fail). Joe From hkchu@google.com Wed Aug 31 17:20:38 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD86921F8D4D for ; Wed, 31 Aug 2011 17:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.527 X-Spam-Level: X-Spam-Status: No, score=-105.527 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hXayxsqvbkxx for ; Wed, 31 Aug 2011 17:20:37 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 748A021F8D4B for ; Wed, 31 Aug 2011 17:20:31 -0700 (PDT) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id p810M2XR010853 for ; Wed, 31 Aug 2011 17:22:02 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314836523; bh=qjRKiSH4gAK/sopSJd2fbzLWm0Q=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=mhVQjPbf6E21TkY0zemZSVmmQZmx+KD7SQCvAArNLNO7SnkdiQSya5ioVDOyuWLSk iYGy+Wi49bv/FpPLHIATA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=iYgvP9Q7AY4FO9qSeXjU/0MlY6vivzWDpwwt8Hinrl6tI5A52+HwZmIzQR6QlzFXz JFNR+sm9YAJi94lIrGPnw== Received: from qyl16 (qyl16.prod.google.com [10.241.83.208]) by wpaz9.hot.corp.google.com with ESMTP id p810Lbj8018855 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 31 Aug 2011 17:22:00 -0700 Received: by qyl16 with SMTP id 16so999159qyl.14 for ; Wed, 31 Aug 2011 17:22:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=0n3hdtHhtumW43JPvV2d1GNNvLazQPdPgniYjMvgnco=; b=jofAl/kQ5NcNF+hdmw1QzU5MQsLL/vNkOV84P5LtQWOoTk3CdAa3Pdw8RZjquQI2g8 YwM8uWNLFuh6og57LoMg== Received: by 10.229.189.202 with SMTP id df10mr819366qcb.257.1314836520269; Wed, 31 Aug 2011 17:22:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.189.202 with SMTP id df10mr819356qcb.257.1314836519482; Wed, 31 Aug 2011 17:21:59 -0700 (PDT) Received: by 10.229.134.137 with HTTP; Wed, 31 Aug 2011 17:21:59 -0700 (PDT) In-Reply-To: <4E5EC5AE.3090707@isi.edu> References: <4E5E608E.3060006@hp.com> <4E5E62D0.5080302@isi.edu> <4E5E6835.3010604@hp.com> <4E5E6A78.3070308@isi.edu> <4E5E97B9.3070908@isi.edu> <4E5EA45A.3090501@isi.edu> <4E5EC5AE.3090707@isi.edu> Date: Wed, 31 Aug 2011 17:21:59 -0700 Message-ID: From: Jerry Chu To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: tcpm@ietf.org, Tim Shepard Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 00:20:38 -0000 On Wed, Aug 31, 2011 at 4:37 PM, Joe Touch wrote: > > > On 8/31/2011 4:29 PM, Jerry Chu wrote: > ... >>> >>> The point is that if the first SYN doesn't indicate option support, the= n >>> the >>> 3WHS isn't going to synchronize the endpoints as to whether that option >>> is >>> supported. That's true regardless of which side initiates the connectio= n. >> >> I still think the final ack can be fudged to close the option >> negotiation loop. (See >> below.) > > You can do a lot of things that end up creating an additional state, and = you > can lie to everyone that such state doesn't exist (a counter keeps track = of > the SEQNO of the SYN/ACK to know which ACK to check, etc.) - but it's got= to > be there. Ok, perhaps my continue calling this kludge 3WHS set you off so let's call = it 4WHS then :). > >> But I just realized this thread seems to assume there is >> >> plenty room left for >> more options in SYN-ACK, and why is that? > > I think we expect that would be true only because the SYN had the "I > understand long options" flag. At that point, the SYN/ACK can use the > feature, in addition to acking it. > > However, this is NOT the case if the SYN/ACK introduces the option. Whate= ver > segment introduces the option cannot use it yet. Ok. > >>>> Options initiated by SYN-ACK will be ack'ed by a pure ack or piggy'ed >>>> back >>>> through a data segment but either way it won't hold off data >>>> transmission >>>> from >>>> the active side because it already knows what options have been agreed >>>> upon. >>> >>> An option initiated by a SYN-ACK either: >>> =A0 =A0 =A0 =A0- was indicated in the SYN, and so confirms it to the in= itiator >>> =A0 =A0 =A0 =A0and the final ACK of the 3WHS confirms it to the respond= er >>> >>> =A0 =A0 =A0 =A0- was initiated in the SYN-ACK >>> =A0 =A0 =A0 =A0which means either: >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0A- the initiator didn't support it >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0B- the initiator didn't have room to say= it supported it >>> >>> A needs a NACK. >>> >>> B needs an ACK. >>> >>> That happens during the 3WHS. >>> >>> Another 4th message needs to complete the exchange, and needs to be >>> reliably >>> retransmitted if lost, etc. - that's what the TCP state machine is for. >> >> The final ack will serve this purpose. > > You need to flag that ACK as being handled differently from other ACKs - > that's state. You also need to not use the option until the last ACK > confirms it. That's state on the other end. > > Any intermediate node that doesn't emulate that state can mess things up = - > esp. if that ACK comes out of order to a subsequent packet that uses the > option. > > The whole point of the state machine is to ensure that certain actions ar= e > gated on the handshake of certain packets. Ok. Perhaps the question is complexity (added states..., etc) vs usefulness= , both can be subjective though. > >>> You can claim your implementation fudges around it, but you effectively >>> need >>> that state - with the timeouts, retransmissions, etc. - to make sure th= at >>> last message is sent properly. >>> >>> AND how do you know when you can now use the option? When you're out of >>> that >>> last 4th state. Not before. >> >> The active open side will have all the knowledge about what options/valu= es >> the >> passive open side proposes after receiving SYN-ACK option so is done wit= h >> option >> negotiation hence can begin the data transmission phase. The passive ope= n >> side >> will be waiting for the final ack of the 3WHS, either in the form of a >> pure ack, or >> as part of a data segment (i.e., the 1st data segment from the active >> open side). >> But either way the option will have been negotiated reliably too for the >> passive >> open side. More importantly, both sides will have the same understanding >> of >> options to use before the data phase. > > Who says the final ACK can't include data? or the other segments (SYN, > SYN/ACK)? > > Who says the final ACK can't be reordered with data that is going across? Yes the options need to be present in all segments from the active open unt= il there is clear indication to the active open side that the passive open sid= e has exit 3WHS (probably what you alluded previously as the 4th state). Jerry > > This is what the states are for, and why you basically need to add one to > make this work (and why a NAT that doesn't have that state will cause thi= ngs > to fail). > > Joe > From touch@isi.edu Wed Aug 31 17:26:44 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D229C21F8C84 for ; Wed, 31 Aug 2011 17:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.191 X-Spam-Level: X-Spam-Status: No, score=-103.191 tagged_above=-999 required=5 tests=[AWL=-0.592, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-tkNAsI91SZ for ; Wed, 31 Aug 2011 17:26:44 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 610D421F8C83 for ; Wed, 31 Aug 2011 17:26:44 -0700 (PDT) Received: from [198.123.60.66] ([198.123.60.66]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id p810RRtW018497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 Aug 2011 17:27:30 -0700 (PDT) Message-ID: <4E5ED16F.70109@isi.edu> Date: Wed, 31 Aug 2011 17:27:27 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Jerry Chu References: <4E5E608E.3060006@hp.com> <4E5E62D0.5080302@isi.edu> <4E5E6835.3010604@hp.com> <4E5E6A78.3070308@isi.edu> <4E5E97B9.3070908@isi.edu> <4E5EA45A.3090501@isi.edu> <4E5EC5AE.3090707@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Tim Shepard Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 00:26:44 -0000 On 8/31/2011 5:21 PM, Jerry Chu wrote: ... >> Who says the final ACK can't include data? or the other segments (SYN, >> SYN/ACK)? >> >> Who says the final ACK can't be reordered with data that is going across? > > Yes the options need to be present in all segments from the active open until > there is clear indication to the active open side that the passive open side has > exit 3WHS (probably what you alluded previously as the 4th state). > > Jerry Yes. So this is the "4WHS". Note that: - it doesn't increase the space in the SYN which has always been the show-stopper - it adds a state to TCP which can be a problem in both local complexity and NAT traversal Pushing the flag into the SYN makes the option available faster *and* avoids the 4th state. What's the reason for waiting until SYN/ACK to send the option? Joe From fernando.gont.netbook.win@gmail.com Wed Aug 31 17:51:31 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F41A521F8C36 for ; Wed, 31 Aug 2011 17:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.426 X-Spam-Level: X-Spam-Status: No, score=-3.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGmsP5qH3MSZ for ; Wed, 31 Aug 2011 17:51:30 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5305D21F8C28 for ; Wed, 31 Aug 2011 17:51:30 -0700 (PDT) Received: by gwb20 with SMTP id 20so680668gwb.31 for ; Wed, 31 Aug 2011 17:53:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=PMwYlOg0Vjj1henxGvobkwBD/CXhTmcgMKCux91pD0s=; b=tnmj9vTTVzkXAaoXjiwjTh0SGBAKG1iDr79o6a+YRSGHXw8UJUfWQc6Bc5q8/8TWMR OLlY4YusYIscD6My/mRRG7aeBLGrfN04AB4VPAalPQZe5hoMMTRdLVfnlMmgSEN1OPIk tFp8FZmFcPMf1FB9vY0032/Z5xtPDg4l4NT8A= Received: by 10.91.121.1 with SMTP id y1mr912865agm.29.1314838381757; Wed, 31 Aug 2011 17:53:01 -0700 (PDT) Received: from [192.168.0.58] ([190.48.221.100]) by mx.google.com with ESMTPS id h25sm113861anm.30.2011.08.31.17.52.58 (version=SSLv3 cipher=OTHER); Wed, 31 Aug 2011 17:53:00 -0700 (PDT) Sender: Fernando Gont Message-ID: <4E5ED768.8070703@gont.com.ar> Date: Wed, 31 Aug 2011 21:52:56 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.20) Gecko/20110805 Thunderbird/3.1.12 MIME-Version: 1.0 To: Joe Touch References: <4E5E5A34.1030707@isi.edu> In-Reply-To: <4E5E5A34.1030707@isi.edu> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org, Tim Shepard Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 00:51:31 -0000 On 08/31/2011 12:58 PM, Joe Touch wrote: > >> There was a belief at least among some that unexpected options on >> anything other than the SYN are dangerous because there might be >> stacks out there that handle them badly, like crashing. So we seemed >> to be stuck requiring all new options to somehow fit in the >> SYN/SYN-ACK exchange. > > Options are exchanged reliably only during connection establishment. > There is no TWHS after that. So starting a new option after the > connection starts seems difficult at best - Stick the option to a given SEQ. Whenever you retransmit that SEQ, you retransmit the option. And when that SEQ is ACKed, that means the option arrived to the other end (assuming no packet scrubber stripped the option, obviously). Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando.gont.netbook.win@gmail.com Wed Aug 31 17:55:16 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4C8421F8C64 for ; Wed, 31 Aug 2011 17:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.435 X-Spam-Level: X-Spam-Status: No, score=-3.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8v1Gu2XW6Uw for ; Wed, 31 Aug 2011 17:55:16 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1DED421F8C3A for ; Wed, 31 Aug 2011 17:55:16 -0700 (PDT) Received: by gyf3 with SMTP id 3so1286581gyf.31 for ; Wed, 31 Aug 2011 17:56:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=e8oLpHKA0D7kLPvhQvcfA0nbAM+YcXsfdXC/jlT20bg=; b=K/JIyYaFm1BY9o1csAio6DliySPQS+ftEyzYpbJI5WTC0dBY4MyiYT/c+C4OPLlI7/ gPDtpJ2Fb3meFU9fve1mrXy4GqSlV0iCY/K1GK2xOz4fm90ZbcblFfKNXR2uD89TTwcT rxJSowTQyiTChgv4HTpGTQgVenRqp/scgNklA= Received: by 10.91.159.12 with SMTP id l12mr889556ago.101.1314838607183; Wed, 31 Aug 2011 17:56:47 -0700 (PDT) Received: from [192.168.0.58] ([190.48.221.100]) by mx.google.com with ESMTPS id l13sm110825anj.42.2011.08.31.17.56.43 (version=SSLv3 cipher=OTHER); Wed, 31 Aug 2011 17:56:46 -0700 (PDT) Sender: Fernando Gont Message-ID: <4E5ED848.5090101@gont.com.ar> Date: Wed, 31 Aug 2011 21:56:40 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.20) Gecko/20110805 Thunderbird/3.1.12 MIME-Version: 1.0 To: Tim Shepard References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org, Joe Touch Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 00:55:16 -0000 On 08/31/2011 01:08 PM, Tim Shepard wrote: >> If anyone sees a way around #2, please speak up. My recollection is that >> we've dragged this dog around the block every few years, and realize the >> same thing: >> >> TCP SYN option space cannot be extended >> >> There may be use to extending the space after the SYNs (someone can >> propose that), but doing it in the SYNs doesn't appear to be possible. > > I think the space could be extended on the SYN-ACK if there was > something on the SYN that indicated that the initiator could handle > it. Just not on the initial SYN. (Middle boxes: grumble. > Simultaneous open: uh huh.) Simultaneous opens are not reliable, anyway -- See Section 5.1 (page 46) of http://www.gont.com.ar/papers/tn-03-09-security-assessment-TCP.pdf Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando.gont.netbook.win@gmail.com Wed Aug 31 17:57:43 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BACD21F8D18 for ; Wed, 31 Aug 2011 17:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.443 X-Spam-Level: X-Spam-Status: No, score=-3.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZsoOSkVUDS6P for ; Wed, 31 Aug 2011 17:57:43 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 06B6821F8D10 for ; Wed, 31 Aug 2011 17:57:42 -0700 (PDT) Received: by yie12 with SMTP id 12so1319572yie.31 for ; Wed, 31 Aug 2011 17:59:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=Bvr6gRTIS4Pxz5JxzdycWimaIGbDYG6a7dcdUzfhmnU=; b=k2n2z5SNcel2lvNo+evKZKpcTjKe3QmMis4Etob6pwinoB6B6dlYmi7dSeBoxkywQl Y/Fw9ASh20Y2fstvbek/eRDZ2e7QNXCJYkn8RvbZ/ODJj1ScfvjSOoMjBRFOVLLPIEGC jWzzR+U4Yh0NHtOuu2oUhI6gvVucw7v5/FC4s= Received: by 10.101.5.33 with SMTP id h33mr885847ani.39.1314838754436; Wed, 31 Aug 2011 17:59:14 -0700 (PDT) Received: from [192.168.0.58] ([190.48.221.100]) by mx.google.com with ESMTPS id d7sm122883anb.14.2011.08.31.17.59.11 (version=SSLv3 cipher=OTHER); Wed, 31 Aug 2011 17:59:13 -0700 (PDT) Sender: Fernando Gont Message-ID: <4E5ED8DE.5030409@gont.com.ar> Date: Wed, 31 Aug 2011 21:59:10 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.20) Gecko/20110805 Thunderbird/3.1.12 MIME-Version: 1.0 To: mallman@icir.org References: <20110831161547.66A7066EF0D@lawyers.icir.org> In-Reply-To: <20110831161547.66A7066EF0D@lawyers.icir.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org, Tim Shepard Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 00:57:43 -0000 On 08/31/2011 01:15 PM, Mark Allman wrote: > Well, > > - It is 2011. If something crashes because of the arrival of an > unknown option it probably has bigger problems. +1 > - In particular, in a study a few years back [*] we found that an > unknown option in the SYN caused connection failures in 0.2% of the > cases. And, further, unexpected [**] options plopped on a packet > after the 3WHS caused connection failure rates of 3%. I'd bet that > by now that is likely even lower. But, at least that is some data. Do you recall (of the top of your head) what caused the connection failures when an option that wasn't negotiated during the 3WHS was included once the connection was established? Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando.gont.netbook.win@gmail.com Wed Aug 31 18:00:32 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB56321F8D48 for ; Wed, 31 Aug 2011 18:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.45 X-Spam-Level: X-Spam-Status: No, score=-3.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tdr7M2otbAeG for ; Wed, 31 Aug 2011 18:00:31 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id C391121F8D32 for ; Wed, 31 Aug 2011 18:00:31 -0700 (PDT) Received: by gxk19 with SMTP id 19so1283353gxk.31 for ; Wed, 31 Aug 2011 18:01:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=fhAEQ8PfKVD7oW+VbWZmKTcLIi9Zi2LvK3JZ7n0Mv3I=; b=sgO0DiRcO/Agm8Yw+m4sI6pdWiM+eeyfsR0RO/KYjcJUYQ0pfO7nipFZcOkWYKJBi/ KQUb9QlmpKMYcA2r8wfPbufHcIcfEmdv12m37wWHQBLTDSmnVyvJSZ/XI3ruYvp80z1c ht0VvNOE6tz+R2qdZKS0dPwcPabynLJK0m5HE= Received: by 10.90.169.9 with SMTP id r9mr883232age.189.1314838919293; Wed, 31 Aug 2011 18:01:59 -0700 (PDT) Received: from [192.168.0.58] ([190.48.221.100]) by mx.google.com with ESMTPS id v4sm115048ank.51.2011.08.31.18.01.54 (version=SSLv3 cipher=OTHER); Wed, 31 Aug 2011 18:01:58 -0700 (PDT) Sender: Fernando Gont Message-ID: <4E5ED980.60901@gont.com.ar> Date: Wed, 31 Aug 2011 22:01:52 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.20) Gecko/20110805 Thunderbird/3.1.12 MIME-Version: 1.0 To: Rick Jones References: <4E5E608E.3060006@hp.com> In-Reply-To: <4E5E608E.3060006@hp.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org, Tim Shepard , Joe Touch Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 01:00:32 -0000 On 08/31/2011 01:25 PM, Rick Jones wrote: > It becomes rather a rather kludgy layer violation, but how flexible are > IPv6 optional headers? The problem in this case is whether they will be (may be even more) unreliable... (e.g., firewalls and the like dropping them) Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando.gont.netbook.win@gmail.com Wed Aug 31 18:03:43 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 834C721F8D32 for ; Wed, 31 Aug 2011 18:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.463 X-Spam-Level: X-Spam-Status: No, score=-1.463 tagged_above=-999 required=5 tests=[AWL=-1.852, BAYES_00=-2.599, FRT_STOCK2=3.988, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rqw5yl46NpOs for ; Wed, 31 Aug 2011 18:03:43 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC8C21F8D2E for ; Wed, 31 Aug 2011 18:03:42 -0700 (PDT) Received: by gwb20 with SMTP id 20so687139gwb.31 for ; Wed, 31 Aug 2011 18:05:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=/51/tAP27PIzUrTw/oKzqVY04+gI6I4VG9ihH8Ftg4E=; b=i8JF794O0d0nDoPv4wLvS8lYh6uxnBAiaBJ8Snl4fwfiLpYqHClhtY1oOqJ81981R/ p9kn0XYOzFM2VhipXVC6GAihQssMrpD1S+LFOGrIF2yMkbcr3FqoD1Qw+wBUnrSVkhC2 HyR8XzNdjjqEVulQjx09qO1eTdlmi9FBToaxk= Received: by 10.236.178.39 with SMTP id e27mr5790100yhm.99.1314839113804; Wed, 31 Aug 2011 18:05:13 -0700 (PDT) Received: from [192.168.0.58] ([190.48.221.100]) by mx.google.com with ESMTPS id b4sm155905yhe.71.2011.08.31.18.05.09 (version=SSLv3 cipher=OTHER); Wed, 31 Aug 2011 18:05:12 -0700 (PDT) Sender: Fernando Gont Message-ID: <4E5EDA43.7020205@gont.com.ar> Date: Wed, 31 Aug 2011 22:05:07 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.20) Gecko/20110805 Thunderbird/3.1.12 MIME-Version: 1.0 To: Joe Touch References: <4E5E608E.3060006@hp.com> <4E5E62D0.5080302@isi.edu> <4E5E6835.3010604@hp.com> <4E5E6A78.3070308@isi.edu> In-Reply-To: <4E5E6A78.3070308@isi.edu> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org, Tim Shepard Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 01:03:43 -0000 Hi, Joe, On 08/31/2011 02:08 PM, Joe Touch wrote: > It could easily be a new option, but the problem is that some stacks > might be very difficult to modify to support this. They expect that all > IP options are processed before TCP touches the packet. > > It would be very difficult to set the option at the IP layer to operate > on different TCP connections differently too. Well, you can allways setsockopt() them. > It also might interact with NATs badly, AFAICT. Particularly with NAT64. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From rick.jones2@hp.com Wed Aug 31 18:10:18 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A44421F8D00 for ; Wed, 31 Aug 2011 18:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osK4euJYSwer for ; Wed, 31 Aug 2011 18:10:17 -0700 (PDT) Received: from g5t0009.atlanta.hp.com (g5t0009.atlanta.hp.com [15.192.0.46]) by ietfa.amsl.com (Postfix) with ESMTP id C176A21F8CCF for ; Wed, 31 Aug 2011 18:10:17 -0700 (PDT) Received: from g5t0030.atlanta.hp.com (g5t0030.atlanta.hp.com [16.228.8.142]) by g5t0009.atlanta.hp.com (Postfix) with ESMTP id 34871303C1; Thu, 1 Sep 2011 01:11:44 +0000 (UTC) Received: from [16.89.244.213] (tardy.cup.hp.com [16.89.244.213]) by g5t0030.atlanta.hp.com (Postfix) with ESMTP id DA8AB14134; Thu, 1 Sep 2011 01:11:42 +0000 (UTC) Message-ID: <4E5EDBCD.4060806@hp.com> Date: Wed, 31 Aug 2011 18:11:41 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110805 Lightning/1.0b2 Thunderbird/3.1.12 MIME-Version: 1.0 To: Fernando Gont References: <4E5E608E.3060006@hp.com> <4E5ED980.60901@gont.com.ar> In-Reply-To: <4E5ED980.60901@gont.com.ar> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org, Tim Shepard , Joe Touch Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 01:10:18 -0000 On 08/31/2011 06:01 PM, Fernando Gont wrote: > On 08/31/2011 01:25 PM, Rick Jones wrote: > >> It becomes rather a rather kludgy layer violation, but how flexible are >> IPv6 optional headers? > > The problem in this case is whether they will be (may be even more) > unreliable... (e.g., firewalls and the like dropping them) I suppose, but there would be little if any chance of them being misinterpreted, which I believe was one of Joe's big concerns about anything that shoved options into the nominal data portion of the TCP segment. rick jones From fernando.gont.netbook.win@gmail.com Wed Aug 31 18:38:33 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22DCA21F8CE7 for ; Wed, 31 Aug 2011 18:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.377 X-Spam-Level: X-Spam-Status: No, score=-3.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIhoZwWd6z5B for ; Wed, 31 Aug 2011 18:38:32 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3669521F8CE4 for ; Wed, 31 Aug 2011 18:38:32 -0700 (PDT) Received: by gxk19 with SMTP id 19so1303451gxk.31 for ; Wed, 31 Aug 2011 18:40:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; bh=NH++KTok5FIge8VWn//gHuONKAxFXB1GEvTCsbqY2uo=; b=IVi9MddQWuco1KzjV7UhuPBp5wouEhUKgoJD+lVWmKRVyw6gmRVSdpbKs/7jGm4f3b h9WCaeIxtj2A/Cg1klb5N3RLGes1gopwIdMrPmNjAo2RcUrrYQTH1sQ+F9sJ6DbIo+CO tW+06DkFIjMammiw13mnpIPpfBqlfwFyfosY4= Received: by 10.101.131.35 with SMTP id i35mr880268ann.131.1314841203476; Wed, 31 Aug 2011 18:40:03 -0700 (PDT) Received: from [192.168.0.58] ([190.48.221.100]) by mx.google.com with ESMTPS id g3sm153870ank.2.2011.08.31.18.40.00 (version=SSLv3 cipher=OTHER); Wed, 31 Aug 2011 18:40:01 -0700 (PDT) Sender: Fernando Gont Message-ID: <4E5EE26D.8080603@gont.com.ar> Date: Wed, 31 Aug 2011 22:39:57 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.20) Gecko/20110805 Thunderbird/3.1.12 MIME-Version: 1.0 To: "tcpm@ietf.org" X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: [tcpm] Fwd: [Fwd: [Bloat] Interesting new study of wireless carrier "middle box" characteristics - buffering and strange TCP activities] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 01:38:33 -0000 FYI -------- Original Message -------- Subject: [Bloat] Interesting new study of wireless carrier "middle box" characteristics - buffering and strange TCP activities From: "richard" Date: August 26, 2011 22:41 To: bloat@lists.bufferbloat.net -------------------------------------------------------------------------- http://www.eecs.umich.edu/~qiangxu/paper/sigcomm11_wang.pdf includes creation of Android app "NetPiculet" to analyze this activity. sample: We released NetPiculet on Android Market in January 2011 and attracted 393 unique mobile users within merely two weeks. Leveraging the data from these users, we report our findings from 10 7 cellular carriers around the world. In particular, we studied the policies of two large nation-wide U.S. carriers in more depth and corroborated our findings carefully with controlled experi ments. Due to security and privacy concerns, we anonymize their names and label them as Carrier A and Carrier B. We summarize our key findings as follows: • In some cellular networks, a single mobile device can encounter more than one type of NAT, likely due to load balancing. We also discovered some NAT mappings increment external port number with time which was not documented in any prior NAT study. Accordingly, we develop new NAT traversal techniques to handle both cases. • Four cellular networks are found to allow IP spoofing, which provides attack opportunities by punching holes on NATs and firewalls “on behalf of” a victim from inside the networks, and thus directly exposing the victim to further attacks from the Internet. • Eleven carriers are found to impose a quite aggressive timeout value of less than 10 minutes for idle TCP connections, potentially frequently disrupting long-lived connections maintained by applications such as push-based email. The resulting extra radio activities on a mobile device could use more than 10% of battery per day compared to those under a more conservative timeout value (e.g., 30 minutes). • One of the largest U.S. carriers is found to configure firewalls to buffer out-of-order TCP packets for a long time, likely for the purpose of deep packet inspection. This unexpectedly interferes with TCP Fast Retransmit and Forward RTO-Recovery, severely degrading TCP performance triggered merely by a single packet loss. • At least one firewall of a major cellular ISP liberally accept s TCP packets within a very large window of sequence numbers, greatly facilitating the traditional blind data injection attacks, endangering connections that transfer relatively large amount of data (e.g., streaming applications). • Some cellular network firewalls do not immediately remove the TCP connection state after a connection is closed, allowing attackers to extend his attack on a victim even after the victim has closed the connection to a malicious server. This also dramatically lengthens the NAT traversal time to a few minutes, given that the same TCP five tuple cannot be reused quickly. original pointer from http://www.technologyreview.com/communications/38435/page1/ richard From micchie@sfc.wide.ad.jp Wed Aug 31 19:47:09 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9BC021F8715 for ; Wed, 31 Aug 2011 19:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8kAs5gMoaU0 for ; Wed, 31 Aug 2011 19:47:09 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFE321F85F6 for ; Wed, 31 Aug 2011 19:47:08 -0700 (PDT) Received: from [IPv6:2001:200:1c0:2800:79f0:3d74:18c3:a7dc] (unknown [IPv6:2001:200:1c0:2800:79f0:3d74:18c3:a7dc]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 1461A278093; Thu, 1 Sep 2011 11:48:09 +0900 (JST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Michio Honda In-Reply-To: <039B4E40-9942-48E5-A129-CCD1FB116D03@ifi.uio.no> Date: Thu, 1 Sep 2011 11:48:09 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <8C1D1E14-D58B-4434-8D4B-074A9A255A49@sfc.wide.ad.jp> References: <9605EAA4-F1C4-4D83-B76E-88C81BFE1555@iki.fi> <4E5E79AC.6030605@gmail.com> <350D177D-8A25-4339-AC68-32CEC48EAC9E@sfc.wide.ad.jp> <039B4E40-9942-48E5-A129-CCD1FB116D03@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.1244.3) Cc: tcpm@ietf.org Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 02:47:10 -0000 Not that much, only several of such segments; SYN with 128 byte payload, = SYN with 128 payload + unknown option, and 512 byte payload variant of = these tests. Results are not varied depending on the payload or and = presence of unknown option.=20 Cheers, - Michio On Sep 1, 2011, at 4:38 AM, Michael Welzl wrote: >=20 > On Aug 31, 2011, at 9:14 PM, Michio Honda wrote: >=20 >> I also performed SYN with payload test, which transmits such SYN to = 500 websites in Alexa Top sites. >=20 > Poor them! Did it ever occur to you how much rubbish must get shot at = these sites? :-) They must get the strangest traffic, originating = from all over the world! >=20 > (yes of course I'm aware that most or all of these are not represented = by one single poor computer standing in a terminal room somewhere... = it's still a funny thought to me) >=20 > Michael >=20 From shep@xplot.org Wed Aug 31 20:05:52 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA41E21F8B31 for ; Wed, 31 Aug 2011 20:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKrOwduDJzF1 for ; Wed, 31 Aug 2011 20:05:52 -0700 (PDT) Received: from www.xplot.org (www.xplot.org [66.92.66.146]) by ietfa.amsl.com (Postfix) with ESMTP id 3913F21F8B30 for ; Wed, 31 Aug 2011 20:05:51 -0700 (PDT) Received: from shep (helo=alva.home) by www.xplot.org with local-esmtp (Exim 3.36 #1 (Debian)) id 1QyxWd-0001KQ-00; Wed, 31 Aug 2011 23:01:07 -0400 From: Tim Shepard To: Fernando Gont In-reply-to: Your message of Wed, 31 Aug 2011 21:52:56 -0300. <4E5ED768.8070703@gont.com.ar> Date: Wed, 31 Aug 2011 23:01:07 -0400 Message-Id: Sender: Tim Shepard Cc: tcpm@ietf.org, Joe Touch Subject: Re: [tcpm] Extending TCP option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 03:05:52 -0000 > Stick the option to a given SEQ. Whenever you retransmit that SEQ, you > retransmit the option. And when that SEQ is ACKed, that means the option > arrived to the other end (assuming no packet scrubber stripped the > option, obviously). That hack is problematic if the TCP connection will carry no data in that direction. (The sequence number will always be that same sequence number on every packet sent going the other way, including the FIN (if we ever get around to sending a FIN). -Tim Shepard shep@alum.mit.edu