From tcpm-bounces@ietf.org Fri Aug 1 02:50:03 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8B7C3A6D72; Fri, 1 Aug 2008 02:50:03 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C78E73A697F for ; Fri, 1 Aug 2008 02:50:02 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L+pMk5DiXiZY for ; Fri, 1 Aug 2008 02:50:02 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.104]) by core3.amsl.com (Postfix) with ESMTP id 168DD3A6B4E for ; Fri, 1 Aug 2008 02:49:32 -0700 (PDT) Received: from mx-av-06.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-01.forthnet.gr (8.14.3/8.14.3) with ESMTP id m719ll8i009502; Fri, 1 Aug 2008 12:47:47 +0300 Received: from MX-IN-05.forthnet.gr (mx-in-05.forthnet.gr [193.92.150.32]) by mx-av-06.forthnet.gr (8.14.3/8.14.3) with ESMTP id m719lljV005947; Fri, 1 Aug 2008 12:47:47 +0300 Received: from hell.hell.gr (adsl69-188.lsf.forthnet.gr [79.103.196.188]) by MX-IN-05.forthnet.gr (8.14.3/8.14.3) with ESMTP id m719lhqu008007; Fri, 1 Aug 2008 12:47:45 +0300 Authentication-Results: MX-IN-05.forthnet.gr smtp.mail=v13@v13.gr; spf=neutral Authentication-Results: MX-IN-05.forthnet.gr header.from=v13@v13.gr; sender-id=neutral From: Stefanos Harhalakis To: tcpm@ietf.org Date: Fri, 1 Aug 2008 12:47:26 +0300 User-Agent: KMail/1.9.9 References: <4891FB44.50704@cisco.com> <78C9135A3D2ECE4B8162EBDCE82CAD7704041514@nekter> In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD7704041514@nekter> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808011247.26976.v13@v13.gr> Cc: Caitlin Bestler Subject: Re: [tcpm] Please read X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Thursday 31 July 2008, Caitlin Bestler wrote: > Is an RFC really needed? > > I've always assumed that the application layer MAY > do pretty much whatever it wants. Further application > layer servers SHOULD protect their own resources against > abusive clients. Those protection mechanisms MAY include > terminating connections. > > All of that is true independent of any specific method > of abusing server resources. Since this is an OS issue that will affect all running applications and it is impossible to ensure that all TCP-listening applications won't be exploitable, I believe it is best to take some (customizable) measures at the OS side too (if understand correctly, that's what the resource management entity, even if it is implemented as a user-space part). Of course any application is able to enforce stricter rules. Apart from that, I believe that the problem is not well defined. I don't exactly understand what differentiates a zero sized window with a one-byte window, etc... Transferring a 1MB file with 1-byte window is essentially the same (no?). It is also almost the same as never acking the last data segment and sending dup-acks for the previous for some time, or just acking 1 byte every N retransmits, etc... Where exactly do you draw the line? Taking a broader look, since TCP's fundamental assumption is that the remote end is trustworthy, perhaps it is better to look at this and other TCP attack methods as a resource allocation problem and handle it as such. Most of the time there won't be such an issue but in cases of an attack, there can be algorithms that "evenly" allocate the shared resource (like available sockets or available buffer space). Also, to my knowledge there are cases where it is impossible to distinguish between legitimate behavior and malicious behavior. Most probably, taking at look at the shared resource approach will solve this and perhaps other future problems too that can be caused by attacks or legitimate remote-ends. At the end, we may only need to point to that problem and indicate what a good policy is made of. Nonce? p.s. I'll be away from keyboard for the next two weeks (starting tomorrow) so please excuse any delayed replies. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Aug 1 03:07:25 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52C803A6D8C; Fri, 1 Aug 2008 03:07:25 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EDDF3A6D8E for ; Fri, 1 Aug 2008 03:07:24 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rspzwdRt1Ig6 for ; Fri, 1 Aug 2008 03:07:23 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.104]) by core3.amsl.com (Postfix) with ESMTP id E48143A6D8C for ; Fri, 1 Aug 2008 03:07:22 -0700 (PDT) Received: from mx-av-06.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-03.forthnet.gr (8.14.3/8.14.3) with ESMTP id m71A7NE5022122; Fri, 1 Aug 2008 13:07:23 +0300 Received: from MX-IN-01.forthnet.gr (mx-in-01.forthnet.gr [193.92.150.23]) by mx-av-06.forthnet.gr (8.14.3/8.14.3) with ESMTP id m71A74YH021905; Fri, 1 Aug 2008 13:07:05 +0300 Received: from hell.hell.gr (adsl69-188.lsf.forthnet.gr [79.103.196.188]) by MX-IN-01.forthnet.gr (8.14.3/8.14.3) with ESMTP id m71A6uF0015729; Fri, 1 Aug 2008 13:06:58 +0300 Authentication-Results: MX-IN-01.forthnet.gr smtp.mail=v13@v13.gr; spf=neutral Authentication-Results: MX-IN-01.forthnet.gr header.from=v13@v13.gr; sender-id=neutral From: Stefanos Harhalakis To: tcpm@ietf.org Date: Fri, 1 Aug 2008 13:06:40 +0300 User-Agent: KMail/1.9.9 References: <4892063D.3010703@cisco.com> In-Reply-To: <4892063D.3010703@cisco.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808011306.40543.v13@v13.gr> Cc: Caitlin Bestler Subject: Re: [tcpm] Persist condition clarification draft, now "clarification of sending behavior" draft - comments solicited X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org I'm resending this as a reply to the 'new' thread just to change the spammy subject. Sorry for the duplicate. On Thursday 31 July 2008, Caitlin Bestler wrote: > Is an RFC really needed? > > I've always assumed that the application layer MAY > do pretty much whatever it wants. Further application > layer servers SHOULD protect their own resources against > abusive clients. Those protection mechanisms MAY include > terminating connections. > > All of that is true independent of any specific method > of abusing server resources. Since this is an OS issue that will affect all running applications and it is impossible to ensure that all TCP-listening applications won't be exploitable, I believe it is best to take some (customizable) measures at the OS side too (if understand correctly, that's what the resource management entity, even if it is implemented as a user-space part). Of course any application is able to enforce stricter rules. Apart from that, I believe that the problem is not well defined. I don't exactly understand what differentiates a zero sized window with a one-byte window, etc... Transferring a 1MB file with 1-byte window is essentially the same (no?). It is also almost the same as never acking the last data segment and sending dup-acks for the previous for some time, or just acking 1 byte every N retransmits, etc... Where exactly do you draw the line? Taking a broader look, since TCP's fundamental assumption is that the remote end is trustworthy, perhaps it is better to look at this and other TCP attack methods as a resource allocation problem and handle it as such. Most of the time there won't be such an issue but in cases of an attack, there can be algorithms that "evenly" allocate the shared resource (like available sockets or available buffer space). Also, to my knowledge there are cases where it is impossible to distinguish between legitimate behavior and malicious behavior. Most probably, taking at look at the shared resource approach will solve this and perhaps other future problems too that can be caused by attacks or legitimate remote-ends. At the end, we may only need to point to that problem and indicate what a good policy is made of. Nonce? p.s. I'll be away from keyboard for the next two weeks (starting tomorrow) so please excuse any delayed replies. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Aug 1 08:13:03 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0D833A695F; Fri, 1 Aug 2008 08:13:03 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF4343A6949 for ; Fri, 1 Aug 2008 08:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.269 X-Spam-Level: X-Spam-Status: No, score=-6.269 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id US+NSiWd-Ww4 for ; Fri, 1 Aug 2008 08:13:01 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7ob114.obsmtp.com [64.18.2.214]) by core3.amsl.com (Postfix) with ESMTP id 0C1BC3A6827 for ; Fri, 1 Aug 2008 08:12:59 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP; Fri, 01 Aug 2008 08:12:07 PDT Received: from antipi.jnpr.net ([10.10.2.34]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 1 Aug 2008 08:11:36 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by antipi.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Aug 2008 11:11:29 -0400 Received: from [172.23.1.182] ([172.23.1.182] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Aug 2008 11:08:15 -0400 Message-ID: <489326B2.4090204@juniper.net> Date: Fri, 01 Aug 2008 11:07:30 -0400 From: Ron Bonica User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: =?UTF-8?B?WU9TSElGVUpJIEhpZGVha2kgLyDlkInol6Toi7HmmI4=?= References: <20080729.060448.112613043.yoshfuji@linux-ipv6.org> <488EF15F.4070302@isi.edu> <20080729.065149.22600370.yoshfuji@linux-ipv6.org> In-Reply-To: <20080729.065149.22600370.yoshfuji@linux-ipv6.org> X-Enigmail-Version: 0.95.6 X-OriginalArrivalTime: 01 Aug 2008 15:08:15.0831 (UTC) FILETIME=[6C7F6670:01C8F3E8] Cc: tcpm@ietf.org, touch@ISI.EDU Subject: Re: [tcpm] TCP-AO Option Layout - Alignment and Padding X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org WU9TSElGVUpJIEhpZGVha2kgLyDlkInol6Toi7HmmI4gd3JvdGU6Cj4gCj4gV2UgaGF2ZSAyNTYg a2V5cywgYW5kIGl0IGlzIG5vdCBlbm91Z2guCgoKRm9sa3MsCgpNb3N0IG9mIHRoZSB0aW1lLCB0 aGUgVFNBRCBjb250YWlucyBleGFjdGx5IG9uZSBrZXkgZm9yIGVhY2ggZGlyZWN0aW9ucy4gCiAg KFRoYXQgaXMsIHRoZSBrZXkgY3VycmVudGx5IGluIHVzZSkuIER1cmluZyBwZXJpb2RzIG9mIHRy YW5zaXRpb24sIHRoZSAKVFNBRCBjYW4gY29udGFpbiB0d28ga2V5cyBpbiBlYWNoIGRpcmVjdGlv bi4gKFRoYXQgaXMsIHRoZSBvbGQgb25lIGFuZCAKdGhlIG5ldyBvbmUpLiBTbywgYSBvbmUtYml0 IGtleS1pZCBpcyByZWFsbHkgYmlnIGVub3VnaC4gQnV0LCBpZiB0aGVyZSAKaXMgYW55IHRob3Vn aHQgb2YgcmVzZXJ2aW5nIGtleWlkPT0wLCB3ZSBoYWQgYmV0dGVyIHJlc2VydmUgMiBiaXRzLiBJ IApkb24ndCB0aGluayB0aGF0IHRoZXJlIGlzIGEgbmVlZCBmb3IgbW9yZS4KCkFuIGFwcGxpY2F0 aW9uIG1heSB3YW50IHRvIG1haW50YWluIGEgbGFyZ2VyIGtleWNoYWluIChwb3NzaWJseSAKY29u dGFpbmluZyBodW5kcmVkcyBvZiBrZXlzKS4gSWYgdGhhdCBpcyB0aGUgY2FzZSwgYSB1c2VyLWxh bmQgCmFwcGxpY2F0aW9uIHNob3VsZCBtYWludGFpbiB0aGF0IGxhcmdlIGtleWNoYWluLiBUaGUg YXBwbGljYXRpb24gd2lsbCAKYWxzbyBzZW5kIGtleXMgdG8gYW5kIGZyb20gdGhlIFRTQUQgYXMg YXByb3ByaWF0ZS4KCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9uCgpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwp0Y3BtIG1haWxp bmcgbGlzdAp0Y3BtQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdGNwbQo= From tcpm-bounces@ietf.org Fri Aug 1 10:24:20 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0CE93A6890; Fri, 1 Aug 2008 10:24:19 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0152E3A6890 for ; Fri, 1 Aug 2008 10:24:19 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtzWjzPSl1A1 for ; Fri, 1 Aug 2008 10:24:18 -0700 (PDT) Received: from owa.neterion.com (mx.neterion.com [72.1.205.142]) by core3.amsl.com (Postfix) with ESMTP id EE35D3A680F for ; Fri, 1 Aug 2008 10:24:17 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 1 Aug 2008 13:23:39 -0400 Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD77040417BC@nekter> In-Reply-To: <200808011306.40543.v13@v13.gr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Persist condition clarification draft, now "clarification of sending behavior" draft - comments solicited Thread-Index: AcjzvnEZvyeer9goSRSsPQ0TxlC6CQAO7XzA References: <4892063D.3010703@cisco.com> <200808011306.40543.v13@v13.gr> From: "Caitlin Bestler" To: "Stefanos Harhalakis" , Subject: Re: [tcpm] Persist condition clarification draft, now "clarification of sending behavior" draft - comments solicited X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Stefanos Haralakis wrote: > > On Thursday 31 July 2008, Caitlin Bestler wrote: > > Is an RFC really needed? > > > > I've always assumed that the application layer MAY > > do pretty much whatever it wants. Further application > > layer servers SHOULD protect their own resources against > > abusive clients. Those protection mechanisms MAY include > > terminating connections. > > > > All of that is true independent of any specific method > > of abusing server resources. > > Since this is an OS issue that will affect all running > applications and it is impossible to ensure that all > TCP-listening applications won't be exploitable, I believe > it is best to take some (customizable) measures at the OS > side too (if understand correctly, that's what the resource > management entity, even if it is implemented as a user-space > part). Of course any application is able to enforce stricter > rules. > By "application layer" I did not mean to limit the scope to a user-space application running under a classic user/kernel OS. Rather, I simply met the set of entities that uses the TCP layer as a client. Even when the TCP layer allocates resources itself, it is doing so as an agent of a specific client/connection/listen. Setting policy on what is a wise use of resources will always belong above the TCP layer, even if some implementations delegate enforcement of that policy to the TCP layer. Please keep in mind that any document coming through TCPM has to make sense not only for the conventional user/kernel style OS, but for embedded web servers that are part of devices or TCP offload devices with the TCP layer implemented in silicon. Treating everything above the TCP layer as an amorphous blob is the only way to do this. Standardization within specific sub-families of those amorphous blobs are best done in other forums. We need to focus on telling them how TCP is supposed to function, without telling them how to manage memory. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Aug 1 11:47:08 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14A7B3A68CE; Fri, 1 Aug 2008 11:47:08 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C10553A6938 for ; Fri, 1 Aug 2008 11:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.829 X-Spam-Level: X-Spam-Status: No, score=-1.829 tagged_above=-999 required=5 tests=[AWL=-0.770, BAYES_00=-2.599, SARE_LWHUGE=1.54] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDwdqE2NoGtr for ; Fri, 1 Aug 2008 11:47:05 -0700 (PDT) Received: from mailer2.psc.edu (mailer2v6.psc.edu [IPv6:2001:5e8:2:42::6a]) by core3.amsl.com (Postfix) with ESMTP id 3C3E73A68CE for ; Fri, 1 Aug 2008 11:47:05 -0700 (PDT) Received: from tesla.psc.edu (tesla.psc.edu [128.182.58.233]) by mailer2.psc.edu (8.14.2/8.13.3) with ESMTP id m6VMHtUS003005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Jul 2008 18:17:55 -0400 (EDT) Received: from localhost.psc.edu (localhost.psc.edu [127.0.0.1]) by tesla.psc.edu (8.13.1/8.13.1) with ESMTP id m6VMHtdu008981; Thu, 31 Jul 2008 18:17:55 -0400 Date: Thu, 31 Jul 2008 18:17:55 -0400 (EDT) From: Matt Mathis To: Mahesh Jethanandani In-Reply-To: <4891FB44.50704@cisco.com> Message-ID: References: <4891FB44.50704@cisco.com> MIME-Version: 1.0 Cc: tcpm@ietf.org Subject: Re: [tcpm] Please read X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Doesn't this create a huge opportunity for a DoS attack, since an attacker can send requests with forged from addresses, and the server has to burn cycles and/or commit memory, when it is never going to see the next packet? I believe that this problem is fundamental to anything that is piggybacked on the SYN and has killed every attempt at using the handshake to eliminate later transactions. The server wants to know for sure that the client is alive and responding before committing more than incidental resources (e.g. SYN queue, constructing a SYN-cookie, etc) to the connection. Thanks, --MM-- ------------------------------------------- Matt Mathis http://staff.psc.edu/mathis Work:412.268.3319 Home/Cell:412.654.7529 ------------------------------------------- On Thu, 31 Jul 2008, Mahesh Jethanandani wrote: > During the TCPM meeting in Dublin, Wes wanted to encourage readers on this > mailing list to read the short (2 pages if you remove the boiler plate part) > draft on "Clarification of Sender Behavior Under Persist Condition" draft. > > To enable a quick read, I have cut and pasted the relevant sections here. As > noted in the meeting, this draft tries to clarify the sender behavior > without getting into the details of the DoS scenario and the possible > solutions. Just to reiterate, it is this draft and not the original persist > draft that we are trying to table for adoption as a WG item. > > 1. Introduction > > RFC 1122 [RFC1122] Section 4.2.2.17, page 92 says that: A TCP MAY > keep it's offered receive window closed indefinitely. As long as the > receiving TCP continues to send acknowledgments in response to the > probe segments, the sending TCP MUST allow the connection to stay > open. The RFC goes on to say that it is important to remember that > ACK (acknowledgment) segments that contain no data are not reliably > transmitted by TCP. Therefore zero window probing SHOULD be > supported to prevent a connection from hanging forever if ACK > segments that re-opens the window is lost. The condition where the > sender goes into the ZWP mode is typically known as the persist > condition. The problem is applicable to TCP and TCP derived > transport protocols like SCTP. > > A consequence of adhering to the above requirement mandated by RFC > 1122 is that multiple TCP receivers (clients) advertising a zero > window to a busy server indefinitely (by reliably acknowledging the > ZWP), could exhaust the connection and buffer resources of the sender > (server). In such cases, to achieve robustness, the system should be > able to take appropriate action on those TCP connections and reclaim > resources. The purpose of this document is to clarify that such > actions are in the spirit of RFC 1122 and they don't violate RFC > 1122. The remainder of the document briefly describes the DoS > scenario, analyzes the current verbiage surrounding the ZWP in RFC > 1122 and attempts to disambiguate the notion presented by RFC 1122. > > 2. Discussion > > Having the sender accumulate buffers and connection table entries > when the receiver has deliberately and maliciously closed the window > ultimately leads to resource exhaustion on the sender. This > particular dependence on the receiver to open its zero window can be > easily exploited by a malicious receiver TCP application to launch a > DoS attack against the sender. In this scenario the sender's > legitimate connections do not get established and already established > well behaved TCP connections are unable to transmit any data. The > sender enters the persist condition and is stuck waiting indefinitely > for the receiver to open up its window. > > To illustrate this, consider the case where the client application > opens a TCP connection with a HTTP [RFC2616] server, sends a GET > request for a large page and stops reading the response. This would > cause the client TCP to advertise a zero window to the server. For > every large HTTP response, the server is left holding on to all the > response data in it's send queue. If the client never clears the > persist condition, the server will continue to hold that data > indefinitely. Multiple such TCP connections stuck in the same > scenario on the server would cause resource depletion resulting in a > DoS situation on the server. > > In such scenarios it should be possible for the application or the > system or a resource management entity to instruct TCP to terminate > connections stalled in the persist condition. These actions are > necessary to prevent resource exhaustion on the server. > > An extensive discussion took place recently about this issue on the > TCPM WG mailing list [TCPM]. The general opinion seemed to be that > terminating a TCP connection in persist condition does not violate > RFC 1122. In particular the operating system, a resource manager, or > an application can instruct TCP to abort a connection in the persist > condition. TCP itself SHOULD not take any action and continue to > keep the connection open as mandated by RFC 1122 unless otherwise > instructed to do so. The exact mechanism by which the instruction to > abort the connection is conveyed to TCP is an implementation decision > and falls beyond the scope of the current memo. To determine which > TCP connection to abort the entity can use the connection attributes > obtained from some interface similar to STATUS call mentioned in RFC > 793. > > > > > > > > > -- mahesh > _______________________________________________ > 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 From tcpm-bounces@ietf.org Fri Aug 1 12:04:25 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E0CD3A68B2; Fri, 1 Aug 2008 12:04:25 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8342A3A68B2 for ; Fri, 1 Aug 2008 12:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.444 X-Spam-Level: X-Spam-Status: No, score=-1.444 tagged_above=-999 required=5 tests=[AWL=-0.385, BAYES_00=-2.599, SARE_LWHUGE=1.54] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGNPm0sq4aPL for ; Fri, 1 Aug 2008 12:04:23 -0700 (PDT) Received: from mailer2.psc.edu (mailer2v6.psc.edu [IPv6:2001:5e8:2:42::6a]) by core3.amsl.com (Postfix) with ESMTP id CE2453A67B6 for ; Fri, 1 Aug 2008 12:04:22 -0700 (PDT) Received: from tesla.psc.edu (tesla.psc.edu [128.182.58.233]) by mailer2.psc.edu (8.14.2/8.13.3) with ESMTP id m71J4fee024850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Aug 2008 15:04:41 -0400 (EDT) Received: from localhost.psc.edu (localhost.psc.edu [127.0.0.1]) by tesla.psc.edu (8.13.1/8.13.1) with ESMTP id m71J4fcO028208; Fri, 1 Aug 2008 15:04:41 -0400 Date: Fri, 1 Aug 2008 15:04:41 -0400 (EDT) From: Matt Mathis To: Adam Langley In-Reply-To: <396556a20807311252j67b1ab26mf6511dbdae780fdd@mail.gmail.com> Message-ID: References: <396556a20807311252j67b1ab26mf6511dbdae780fdd@mail.gmail.com> MIME-Version: 1.0 Cc: tcpm@ietf.org Subject: Re: [tcpm] Faster application handshakes with SYN/ACK payloads (RESEND) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Opps I posted to the wrong thread. Sorry folks.. Doesn't this create a huge opportunity for a DoS attack, since an attacker can send requests with forged from addresses, and the server has to burn cycles and/or commit memory, when it is never going to see the next packet? I believe that this problem is fundamental to anything that is piggybacked on the SYN and has killed every attempt at using the handshake to eliminate later transactions. The server wants to know for sure that the client is alive and responding before committing more than incidental resources (e.g. SYN queue, constructing a SYN-cookie, etc) to the connection. Thanks, --MM-- ------------------------------------------- Matt Mathis http://staff.psc.edu/mathis Work:412.268.3319 Home/Cell:412.654.7529 ------------------------------------------- Evil is defined by mortals who think they know "The Truth" and use force to apply it to others. On Thu, 31 Jul 2008, Adam Langley wrote: > I posted this a while back and it gathered a little discussion: > > http://www.ietf.org/internet-drafts/draft-agl-tcpm-sadata-00.txt > (implementation in [1]) > > I would like to have this published as Experimental and to get an > option number assigned. > > The spec itself includes a somewhat rambling justification because I > wanted to decouple the spec, which is more general, from the exact > reason that I wish to start testing this over the Internet at large. > However, in order to provoke discussion I think I should explain my > motivation: > > This spec allows for opportunistic encryption of TCP connections with > no additional round trips. Details of the project can be found at [2], > however a quick summary follows: > > Although SYN/ACK payloads could be used to accelerate many protocols, > I'm proposing that, for HTTP, the SYN/ACK payload contains an 8-byte > random nonce and a 32-byte eliptic-curve public value. The client can > then perform key agreement and send it's own public value, nonce and > any encrypted payload in the final ACK. (Or in a following packet, > that works fine too). Data is then encrypted using Salsa20/8 where the > key is SHA256(diffie-hellman output + server nonce + client nonce) and > the IVs are 0 and 2**63 for client->server and server->client, resp. > > Obviously, this open to both a downgrade and man-in-the-middle attack. > For a specific user, it offers little real security. However, > amortised over a large set of users, any ISPs performing these attacks > on a large scale will be detected. (I plan on building a network of > hosts probing for large scale attacks.) Thus, eavesdroppers are > removed from the equation and, against the rest, it can protect most > of the people, most of the time. > > I also plan to sign the resulting packets with TCP-AO at some point, > if possible. However, given that that is still under development I'm > going to make that part of the negotiation, above, so that it can be > deployed without it for now. > > Obviously, this system can only prove itself in time. However, it > can't prove itself with an option number assigned. And thus, I'm > looking for a consensus that this is an interesting experiment. > > Thanks > > Having spoken to quite a few people about this, I now have an FAQ on > the design which is included below: > > * Why Elliptic-curves? > > The payload must be short otherwise SYN-floods could use this as an > amplification > to backscatter DDoS another host. > > Also, the reduced computation cost (as compared to Diffie-Hellman over a > multiplicative finite field) is very nice. > > * Why 25519? > > It's very fast (2000 ops/sec with my C code. 4000 ops/sec with asm). Also, the > server's public value must be constant, otherwise an attacker could eat CPU > time with a SYN flood and curve25519 is designed for that. > > Since this is constant for all connections, there is no perfect forward > secrecy. > > * Can't you fit the client's public value in the SYN? > > A SYN generally has 20 bytes of free option space these days. (We can't use the > payload space in a SYN). Since this can't be the last option ever, we need to > leave 4 bytes spare. 2 bytes for the option header means 14 bytes for the > public value. The closest prime is 2**112-75. > > I'm a bear of little brain and picking my own curve is already a hell of a > task, but assuming that I can: > > The best, general algorithm currently known for breaking the DH problem on > elliptic curves is Pollard's Rho. The work involved in this attack is sqrt(n), > which is 2**56 in this case. Critically, once you have solved a single instance > you can precompute tables to speed up breaking more instances. With a petabyte > of storage, you could break 112-bit curves in 2**12 operations, which is very > fast. > > * Can't you use a smaller field anyway? > > Some speedup could be gained by using an EC with a field size around 200 bits. > However the effort of defining such a curve is pretty huge. The standard NIST > curves around that size are slower: > > http://www.cacr.math.uwaterloo.ca/techreports/2003/corr2003-18.pdf (table 6) > > * Why Salsa20/8? > > It encrypts at two cycles per byte on modern CPUs[1]. The best attack on this, > reduced round, variant is 2**251. It's very unlikely that an attack would ever > break it to the point that it's easier than performing a downgrade attack. > > http://cr.yp.to/streamciphers/phase3speed-20080331.pdf > > > > [1] http://code.google.com/p/obstcp/source/browse/trunk/patches/synack-payload > [2] http://code.google.com/p/obstcp/ > > -- > Adam Langley agl@imperialviolet.org http://www.imperialviolet.org > _______________________________________________ > 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 From tcpm-bounces@ietf.org Fri Aug 1 12:23:39 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA5953A6895; Fri, 1 Aug 2008 12:23:39 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FF5C3A6895 for ; Fri, 1 Aug 2008 12:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.207 X-Spam-Level: X-Spam-Status: No, score=-1.207 tagged_above=-999 required=5 tests=[AWL=-0.770, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, SARE_LWHUGE=1.54] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fg-12VL+64F for ; Fri, 1 Aug 2008 12:23:38 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by core3.amsl.com (Postfix) with ESMTP id 61D823A6827 for ; Fri, 1 Aug 2008 12:23:38 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so1048590rvf.49 for ; Fri, 01 Aug 2008 12:23:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=Ekunz3QInRDMxMDDq3MHNv+QzhjzBx+r0tL1cTO0Is8=; b=eMVfdXzf+d1d7/C7tLbHi23GEtIuIAAAmGLc9IhL+IQyOxUiy3x7g1IdONPg7wpkng q0Z35LyxWbOjhxFK0HgiLn6qq3DNDU6d2UGQ/2DYJwIwEqb8YpEoOJtzERxkxpgzUdIi 24Ga0KJX0Q5a+AWbcv91atftWV4p0QC7ZQzGA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=IfKe8HjbF8MqzlSexhivuIXxjg/P6K7xOfnkxr5e5pyo/ZakzX0Mz5GGrNbM/WuMc1 eqfbDkkjSRUqD4c/N06k4q9BM3JCBVvBzUoa2+5v1HwT0j8qK00EOX43880qocA8YS95 R23rCeGYq9FPd+8KUutu3HKkPDKPf09nSeqkM= Received: by 10.141.193.1 with SMTP id v1mr6133682rvp.245.1217618637292; Fri, 01 Aug 2008 12:23:57 -0700 (PDT) Received: by 10.141.186.3 with HTTP; Fri, 1 Aug 2008 12:23:57 -0700 (PDT) Message-ID: <396556a20808011223u57d3f4dk39b491ab5f9aa277@mail.gmail.com> Date: Fri, 1 Aug 2008 12:23:57 -0700 From: "Adam Langley" To: "Matt Mathis" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <396556a20807311252j67b1ab26mf6511dbdae780fdd@mail.gmail.com> X-Google-Sender-Auth: cd355a15d11a3399 Cc: tcpm@ietf.org Subject: Re: [tcpm] Faster application handshakes with SYN/ACK payloads (RESEND) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Fri, Aug 1, 2008 at 12:04 PM, Matt Mathis wrote: > Doesn't this create a huge opportunity for a DoS attack, since an attacker > can send requests with forged from addresses, and the server has to > burn cycles and/or commit memory, when it is never going to see the next > packet? The additional requirements on the server when processing a SYN under my scheme are: * At most, an additional 12 bytes of state in the request sock. At least, another 5 bytes (depending on alignment etc) * Generating 8 random bytes * Transmitting an additional 45 bytes in the SYNACK frame (3 bytes of option + 8 random bytes + 32 bytes of elliptic curve point + 2 bytes header) The additional storage isn't that bad. Currently, in Linux a tcp_request_sock is 96 bytes: (gdb) print ((struct tcp_request_sock *) 0)[1] Cannot access memory at address 0x60 So the additional space isn't that great. Random number generation isn't too bad either. Also, the spec explicitly says that hosts can decide not to support it under load (e.g. if they are switching to SYN cookies). I did consider defining a special echo option to save on the server's storage, but decided that I didn't think it was worth the extra complexity. Of course, these are subjective judgements; one might reasonably consider that to be too much work for a SYN. Cheers AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Aug 1 12:58:01 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 071673A696F; Fri, 1 Aug 2008 12:58:01 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C8783A696F for ; Fri, 1 Aug 2008 12:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6lI4N+Dxa5A6 for ; Fri, 1 Aug 2008 12:57:55 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.246]) by core3.amsl.com (Postfix) with ESMTP id C34713A6A21 for ; Fri, 1 Aug 2008 12:57:54 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so1355015and.122 for ; Fri, 01 Aug 2008 12:58:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=5oL1t8nOkhcoQBozwyZoILe1us80fVl5xeb66gLmJo8=; b=pp88fuUTaDbRPTC7kHo/ToyqfQfprAyEdXlNWn+niaAPnSLAv1IY4pBcLq2yKJuFhI eeeZuLR3Hb8Lg2gNqrZ0OHqmESVgPkTpsejSOMGVtnMqzYTDgXItGfMdgppew8hDeKAY 5uGXMT7/hF1W74O1zJTqCWgtEwf99xU9pXr1s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=ECkWnYAFUCyf16yLCfWDgAKQmoH7EgYb5SATdYh4qlmm6rbCqjBwQvQ0Zo6xEU4+/q Vc7CZjyk5pm8v27E3zyyKsuC2YZzE5+D6ZY8RtuupIOF2t5J4jhJ+4Y3tTyu8Nmomktk tZrxJcJbJW1TtUMyKyL2/z8yqnhQRLWBpBWVg= Received: by 10.100.216.12 with SMTP id o12mr17201867ang.117.1217620694367; Fri, 01 Aug 2008 12:58:14 -0700 (PDT) Received: by 10.100.216.13 with HTTP; Fri, 1 Aug 2008 12:58:14 -0700 (PDT) Message-ID: <9c8209a10808011258n1f87ce9nc7de3dfce6f98acf@mail.gmail.com> Date: Fri, 1 Aug 2008 12:58:14 -0700 From: "Murali Bashyam" To: "Stefanos Harhalakis" In-Reply-To: <200808011247.26976.v13@v13.gr> MIME-Version: 1.0 References: <4891FB44.50704@cisco.com> <78C9135A3D2ECE4B8162EBDCE82CAD7704041514@nekter> <200808011247.26976.v13@v13.gr> Cc: tcpm@ietf.org, Caitlin Bestler Subject: Re: [tcpm] Please read X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0566901646==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0566901646== Content-Type: multipart/alternative; boundary="----=_Part_17766_14254005.1217620694380" ------=_Part_17766_14254005.1217620694380 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Fri, Aug 1, 2008 at 2:47 AM, Stefanos Harhalakis wrote: > On Thursday 31 July 2008, Caitlin Bestler wrote: > > Is an RFC really needed? > > > > I've always assumed that the application layer MAY > > do pretty much whatever it wants. Further application > > layer servers SHOULD protect their own resources against > > abusive clients. Those protection mechanisms MAY include > > terminating connections. > > > > All of that is true independent of any specific method > > of abusing server resources. > > Since this is an OS issue that will affect all running applications and it > is > impossible to ensure that all TCP-listening applications won't be > exploitable, I believe it is best to take some (customizable) measures at > the > OS side too (if understand correctly, that's what the resource management > entity, even if it is implemented as a user-space part). Of course any > application is able to enforce stricter rules. The resource management entity can be part of TCP or it can be in the OS/application and do its work based on feedback from TCP. > > Apart from that, I believe that the problem is not well defined. I don't > exactly understand what differentiates a zero sized window with a one-byte > window, etc... Transferring a 1MB file with 1-byte window is essentially > the > same (no?). It is also almost the same as never acking the last data > segment > and sending dup-acks for the previous for some time, or just acking 1 byte > every N retransmits, etc... Where exactly do you draw the line? There are solutions for those scenarios, UTO based. UTO doesn't kick in when the peer is offering zero window. The attempt in this draft is to *enable* alternatives to the TCP sender side by clarifying the 1122 verbiage and allowing resource management approaches, UTO based approaches to handle this condition etc. > > > Taking a broader look, since TCP's fundamental assumption is that the > remote > end is trustworthy, perhaps it is better to look at this and other TCP > attack > methods as a resource allocation problem and handle it as such. Most of the > time there won't be such an issue but in cases of an attack, there can be > algorithms that "evenly" allocate the shared resource (like available > sockets > or available buffer space). Also, to my knowledge there are cases where it > is > impossible to distinguish between legitimate behavior and malicious > behavior. > Most probably, taking at look at the shared resource approach will solve > this > and perhaps other future problems too that can be caused by attacks or > legitimate remote-ends. At the end, we may only need to point to that > problem > and indicate what a good policy is made of. That's the attempt here, to highlight the implications of this condition and possible solutions (to be posted in the second draft and in the combined draft earlier). The solutions are general enough to extend to the other scenarios you are describing. > > Nonce? > > p.s. I'll be away from keyboard for the next two weeks (starting tomorrow) > so > please excuse any delayed replies. > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > -- Rgds, Murali Bashyam (c) (510)6736915 ----------------------------- CONFIDENTIAL -------------------- ***************************************************** This telecommunication and any data attached to, or included in it is considered confidential, and is intended only for use by the named recipient. The contents may be legally protected as any one or more of: copyrighted material, trade-secret protected material, attorney-client privileged material, attorney workproduct, or as material covered by any other legally available means. If you received this material in error, please notify the sender and destroy the original and all copies, whether electronic or otherwise. Thank you. ***************************************************** ------------------------------ CONFIDENTIAL -------------------- ------=_Part_17766_14254005.1217620694380 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline


On Fri, Aug 1, 2008 at 2:47 AM, Stefanos Harhalakis <v13@v13.gr> wrote:
On Thursday 31 July 2008, Caitlin Bestler wrote:
> Is an RFC really needed?
>
> I've always assumed that the application layer MAY
> do pretty much whatever it wants. Further application
> layer servers SHOULD protect their own resources against
> abusive clients. Those protection mechanisms MAY include
> terminating connections.
>
> All of that is true independent of any specific method
> of abusing server resources.

Since this is an OS issue that will affect all running applications and it is
impossible to ensure that all TCP-listening applications won't be
exploitable, I believe it is best to take some (customizable) measures at the
OS side too (if understand correctly, that's what the resource management
entity, even if it is implemented as a user-space part). Of course any
application is able to enforce stricter rules.

The resource management entity can be part of TCP or it can be in the OS/application and do its work based on feedback from TCP.



Apart from that, I believe that the problem is not well defined. I don't
exactly understand what differentiates a zero sized window with a one-byte
window, etc... Transferring a 1MB file with 1-byte window is essentially the
same (no?). It is also almost the same as never acking the last data segment
and sending dup-acks for the previous for some time, or just acking 1 byte
every N retransmits, etc... Where exactly do you draw the line?

There are solutions for those scenarios, UTO based. UTO doesn't kick in when the peer is
offering zero window. The attempt in this draft is to  *enable* alternatives to the TCP sender side by
clarifying the 1122 verbiage and allowing resource management approaches, UTO based approaches to handle this condition
etc.

 


Taking a broader look, since TCP's fundamental assumption is that the remote
end is trustworthy, perhaps it is better to look at this and other TCP attack
methods as a resource allocation problem and handle it as such. Most of the
time there won't be such an issue but in cases of an attack, there can be
algorithms that "evenly" allocate the shared resource (like available sockets
or available buffer space). Also, to my knowledge there are cases where it is
impossible to distinguish between legitimate behavior and malicious behavior.
Most probably, taking at look at the shared resource approach will solve this
and perhaps other future problems too that can be caused by attacks or
legitimate remote-ends. At the end, we may only need to point to that problem
and indicate what a good policy is made of.

That's the attempt here, to highlight the implications of this condition and possible solutions (to be posted in the second draft and in the
combined draft earlier). The solutions are general enough to extend to the other scenarios you are describing.



Nonce?

p.s. I'll be away from keyboard for the next two weeks (starting tomorrow) so
please excuse any delayed replies.
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm



--
Rgds,
Murali Bashyam
(c) (510)6736915

----------------------------- CONFIDENTIAL --------------------
*****************************************************
This telecommunication and any data attached to, or included in it
is considered confidential, and is intended only for use by the named
recipient. The contents may be legally protected as any one or more of:
copyrighted material, trade-secret protected material, attorney-client
privileged material, attorney workproduct, or as material covered by
any other legally available means. If you received this material in
error, please notify the sender and destroy the original and all copies,
whether electronic or otherwise. Thank you.
*****************************************************
------------------------------ CONFIDENTIAL --------------------
------=_Part_17766_14254005.1217620694380-- --===============0566901646== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============0566901646==-- From tcpm-bounces@ietf.org Fri Aug 1 19:22:32 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5533B3A6B82; Fri, 1 Aug 2008 19:22:32 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D07033A6B83 for ; Fri, 1 Aug 2008 19:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.53 X-Spam-Level: X-Spam-Status: No, score=-1.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nz6kRH1uVW6S for ; Fri, 1 Aug 2008 19:22:29 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id A39593A6B7A for ; Fri, 1 Aug 2008 19:22:29 -0700 (PDT) Received: from [75.199.123.243] (243.sub-75-199-123.myvzw.com [75.199.123.243]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m722M7bQ003767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Aug 2008 19:22:16 -0700 (PDT) Message-ID: <48935337.5060205@isi.edu> Date: Fri, 01 Aug 2008 11:17:27 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Adam Langley References: <396556a20807311252j67b1ab26mf6511dbdae780fdd@mail.gmail.com> <48924496.9060907@isi.edu> <396556a20807311640w2b17d447ud0c51241dc84f682@mail.gmail.com> In-Reply-To: <396556a20807311640w2b17d447ud0c51241dc84f682@mail.gmail.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Faster application handshakes with SYN/ACK payloads X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Adam, Adam Langley wrote: | On Thu, Jul 31, 2008 at 4:02 PM, Joe Touch wrote: |> - - TCP is already permitted to send data in the SYN-ACK |> prohibiting it when the SA-PP option is missing violates |> RFC1122 sec 4.2.2.5 -- unknown options are silently ignored |> |> options that change TCP need to be explicitly acknowledged, |> and current (legacy) behavior should be assumed if not |> acknowledged | | Ah, I didn't know this. Thank you! | | I don't believe changing TCP to disallow this is a good idea. However, | it's important that userland knows weather this experiment is in | effect. It's not an experiment; it's valid TCP behavior. Why does the application need to know? As you note, it speeds up application performance, but the app never knows how long the SYN exchange takes anyway - or whether there are retransmissions. - ------ Although there is more detailed feedback below, it might be useful to raise this up a level. If the purpose of this option is to encourage servers that know about the option to potentially speed up their data transmission, then it might be sufficient to just send the hint in the SYN. The SA would then have the data if the server wanted to. What if the server just assumed this? It seems like nothing should break and it would work where it should anyway... I.e., Nike's rule applies: "Just do it." (no need for an option) (side note) Such an option might be useful, but might also be an issue. It tests the fact that TCPs ignore unknown options, a test that might fail. It also tests the fact that middleboxes should pass options unmodified, which also might fail. Although either of these behaviors would be out of spec, I wonder whether it's useful to try to optimize a connection at the expense of it possibly failing. If this option is intended to 'definitively speed up' connections, there's nothing in TCP that is 'realtime'. Applications can't see things like retransmission, or the fact that data in the SYN (and thus SYN-ACK) need not be ACKd when the SYN (or SYNACK) is ACK'd. Application data boundaries (writes) don't need to correspond to data segmentation either. Overall, there seem like too many ways in which valid TCP behavior can stall things for an extra RTT or so *anytime* during a connection (including the handshake); forcing data into the SYNACK doesn't seem productive if that's the case. A change to TCP that makes this option visible seems like it's a change to TCP semantics that requires broader modifications - the API needs to be redefined, socket options (or the equivalent) need to be defined, etc. For very short exchanges for which 1 RTT savings would be significant, perhaps TCP isn't the right protocol to use, IMO. For longer connections, the savings would be masked by other RTTs anyway. - ------ The following are details, but it would be more useful to focus on the above first... - -- Joe | Thus, I believe that I should echo the SA-PP option in the | SYNACK. You can, but it doesn't really matter. The SA-PP can be considered a hint to the other end to encourage it to send data in the SA. If the SA contains data, either the other end was suitably encouraged, or it didn't need encouragement. Either way, the presence of the data in the SA tells you what you need to know - that the other end sent data. Either way, once your end receives SA data, it can allow its app layer to access the data once the subsequent ACK is sent. As far as the initiating end is concerned, the TWHS ends when that ACK is sent anyway. | Also, it should probably change names: SYN/ACK Payloads | Processed or some similar. | |> - - The rule "For a given SYN, if any resulting SYNACK frame has a payload |> then all resulting frames MUST have a payload" appears to disable |> persists and ACKs as would be needed for proper operation when data is |> not available in one or more direction | | That's badly worded on my part. It should read: | "For a given SYN, if any resulting SYNACK frame has a payload then all | resulting SYNACK frames MUST have a payload" There is only one SYNACK segment in a connection in a given direction, excepting retransmissions. There is no reason why retransmissions need to include data - if the SA with data is received, either the SA is ACKd or the SA and data are ACKd; if the SA without data is received, it would be ACKd. The result is that either the ACK says the SA data got there or not. If not, then it would be retransmitted in a regular data packet. Again, since TCP is NOT a 'realtime' protocol - and doesn't have a 'realtime' handshake', the application can't know or care about the difference. | (i.e. the restriction only apply to SYNACK frames. It's just so a host | cannot decide the retransmit a different SYNACK) See above; I don't see why it would, but I don't see why the application could care. ... |> - - the diagrams need to include some corner cases: |> - when KX is larger than the PMTU in fig 3 (or NList is |> larger than the PMTU in fig 2) |> (i.e., it seems like there is a missing MUST NOT on the length) | | It's suggested that the payload be limited to 64-bytes to prevent | amplification backscatter from a SYN flood. Thus these bytestrings | have to fit within the MTU. If an implementation doesn't enforce this, | then it has to drop support when replying on a link where the MTU is | insufficient. A 576 MTU is the smallest size that endpoints agree to reassemble; it is NOT the smallest MTU all links agree to support in the Internet. The smallest MTU is 68 bytes - i.e., IP with all possible options, TCP with none, and the smallest possible fragment (8 bytes) [see RFC791]. As a result, a 64-byte payload is too large to assume that it won't be fragmented (that may be true practically in many cases, but it isn't a requirement). |> - how do you handle simultaneous opens? | | I believe that simultaneous opens work just fine, although both sides | will believe that the other doesn't support this experiment since the | option won't be echoed in the SYN. A SA is just a SYN with an ACK. In simultaneous opens, the ACK for each SYN comes alone. In that case, whether the ACK of the SYN (which, in simultaneous open is just an ACK) could include the option and data if it is sent after the other side's SYN is received. I.e., depending on how the SYNs cross, the handshake might succeed or might not. If confirming the option is critical, you need to handle this case. As noted above, it might not be critical (or even necessary). |> - - can you explain why you use a bit-field for the TCP option flag, |> rather than just using a 2-byte option? (i.e., KIND, length) | | My hope was that by defining a flags option like this, future options | that require only to signal their presence in a SYN could save space. That might be a useful to document as a separate issue, since it's orthogonal to this option. However, you'd need more rules, like the fact that the responder needs to clear (or truncate) all bits it doesn't understand or doesn't agree to. It'd be useful to develop this more fully and get WG feedback on it separately, IMO. It's not always as efficient as it appears, FWIW: it trades efficiency when many flags are set for inefficiency when only recent flags are defined. E.g., the 25th such flag pays an extra 3-byte penalty when no other flags are used. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiTUzcACgkQE5f5cImnZrvTAQCfSh/dutm/eQ0X5G7YjhgGB7rZ WcgAn2utEgJoT/WLwrl8Kam7H3x37MRj =o/TA -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Aug 1 19:23:45 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97F8828C1CA; Fri, 1 Aug 2008 19:23:45 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9B3828C1A2 for ; Fri, 1 Aug 2008 19:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.53 X-Spam-Level: X-Spam-Status: No, score=-1.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXdgHMUjMmlP for ; Fri, 1 Aug 2008 19:23:44 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 0384D28C199 for ; Fri, 1 Aug 2008 19:23:43 -0700 (PDT) Received: from [75.199.123.243] (243.sub-75-199-123.myvzw.com [75.199.123.243]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m722NI0x004128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Aug 2008 19:23:25 -0700 (PDT) Message-ID: <48935983.80701@isi.edu> Date: Fri, 01 Aug 2008 11:44:19 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Adam Langley References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488DD77D.9070608@isi.edu> <20080728144721.AC9184B905A@kilo.rtfm.com> <488DE021.7070307@isi.edu> <20080728164013.422D14B9600@kilo.rtfm.com> <20080730213253.B347F4D52E1@kilo.rtfm.com> <4890E9AE.3000607@isi.edu> <20080731001609.6511C4D5E34@kilo.rtfm.com> <489175BD.6040201@isi.edu> <396556a20807311010k78c22981xa0eebd1b46e9f619@mail.gmail.com> In-Reply-To: <396556a20807311010k78c22981xa0eebd1b46e9f619@mail.gmail.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] tcp-auth-opt issue: replay protection X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adam Langley wrote: ... |> | So, two salient points: |> | 1. When the sequence number is in the region of 0 (more precisely |> | while there are unacked segments on both sides of the region), |> | then the sides must maintain two keys and arrange to use |> | the appropriate one. |> |> Eric - can you explain "arrange to use the appropriate one"? | | I believe Eric is discussing the case where the keys change because of | a rollover. Since packets may be reordered, a host past to remember | both the keys for the previous period and the keys for the current | period in case a reordered packet comes in. It's unclear, to me, which | key retransmitted packets would use. IMO: retransmitted packets would use the currently active keyID (even if different from what was previously transmitted). The ESN they would use would depend on the sequence number in the packet (it can't depend on anything else, AFAICT). Using your 'nearness' algorithm should suffice for that. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiTWYMACgkQE5f5cImnZrvQwACePZOCwLg+MADrM7ar/siXmm8r vrkAn0GSkVfaShDyDUcBqNb/8X32n3aw =da0w -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Aug 1 19:23:57 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2CDA28C1D9; Fri, 1 Aug 2008 19:23:57 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA5D928C1D9 for ; Fri, 1 Aug 2008 19:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.53 X-Spam-Level: X-Spam-Status: No, score=-1.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4lDCQ2Gglyj for ; Fri, 1 Aug 2008 19:23:56 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id F397028C1D4 for ; Fri, 1 Aug 2008 19:23:55 -0700 (PDT) Received: from [75.199.123.243] (243.sub-75-199-123.myvzw.com [75.199.123.243]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m722NWlh004283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Aug 2008 19:23:37 -0700 (PDT) Message-ID: <48935FFD.4090805@isi.edu> Date: Fri, 01 Aug 2008 12:11:57 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Adam Langley References: <4890F4BE.6060302@isi.edu> <396556a20807301622l4cb33deuff73cd13d7a75ba1@mail.gmail.com> <4890FBE8.1020203@isi.edu> <396556a20807311700w1eda50b0o5da7ae52e6c1691a@mail.gmail.com> In-Reply-To: <396556a20807311700w1eda50b0o5da7ae52e6c1691a@mail.gmail.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] tcp-auth-opt issue: support for NATs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adam Langley wrote: | On Wed, Jul 30, 2008 at 4:40 PM, Joe Touch wrote: |> The current TSAD supports only a wildcard source port, which is |> instantiated for the first connection received that matches. It expects |> that the KMS installs additional keys as needed. | | I was assuming that the TSAD would support wildcards for source IPs | and ports. I would also suggest that it's not a bad idea, although if | it didn't happen, that's no problem. My impression is that the overall system should support what TCP supports, i.e., LISTEN on ANY in the same places TCP does. However, once a connection is established, the connection key is fixed. Note that this means the TSAD might allow wildcards in places the current draft doesn't describe. There are two possible solutions to work over NATs then: 1) install keys that are sufficiently wildcarded AND configure those keys to ignore the addresses and ports 2) require the KMS to determine the appropriate keys to install on the two ends, and compute the MAC based on the received socket pair (I had thus far been assuming #2, FWIW) #1 appears to have a few potential challenges: - once we omit the addresses and ports from the MAC, we can't assume that each connection's derived key is unique (it would depend only on the ISN pair) within a host - if keys are shared across a number of hosts, derived connection keys aren't unique across those hosts either. after an area reboot, non-randomized ISN generation might be leveraged to enable a replay attack - support for NATs assumes keys are installed in ways that support NATs i.e., the wildcards matter just as much as the 'ignore socket pair in MAC' setting - support for NATs appears to prohibit keys that depend on client addr or source ports, i.e., there would be no way to have different keys for different groups of clients |> The above appears to require that the KMS deploy the same key for all |> potentially overlapping NAT'd connections. This adds a requirement to |> the KMS, but suggests that the pseudoheader is included or excluded for |> all connections to a host from a given IP address. Is that what is |> intended, or can you clarify? If that is what is intended, how can the |> KMS enforce this? | | Indeed, something would have to arrange for the pseudoheader to be | excluded from the MAC input when a packet matches a wildcard source IP | rule. Also, the same key would indeed be used by many connections. | Thus the key should rotate based on the time (once a minute would be | reasonable.) Key rotations (presumably you're talking about the master key) may require some synchronization, which seems unlikely in the case of NATs as well. There are a few questions that may be useful to address to move forward: - is the use of wildcards/ingore addrs/ports compatible with the desire for unique per-connection keys? - is it OK to require that all NAT'd clients use the same key - is it OK to require that support for NATs means using wildcard'd keys? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiTX/0ACgkQE5f5cImnZrvanQCgmWWXXC76EzaTziol3sQUHavR aNQAoOZ0qyS0NddQn4qMg5IAj85dFe41 =decj -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Aug 1 19:24:57 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0A203A6B6A; Fri, 1 Aug 2008 19:24:56 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 016013A6B6A for ; Fri, 1 Aug 2008 19:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[AWL=0.513, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRBDRErFCvkC for ; Fri, 1 Aug 2008 19:24:55 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 01BF93A68E7 for ; Fri, 1 Aug 2008 19:24:54 -0700 (PDT) Received: from [75.199.123.243] (243.sub-75-199-123.myvzw.com [75.199.123.243]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m722O8dS004415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Aug 2008 19:24:11 -0700 (PDT) Message-ID: <48939933.3030601@isi.edu> Date: Fri, 01 Aug 2008 16:16:03 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <0C53DCFB700D144284A584F54711EC58058C2FD4@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC58058C2FD4@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] TCP-AO review comments. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ananth, Thanks for posting the comments. Some notes/questions below. Anantha Ramaiah (ananth) wrote: | Hi, | I went over the latest copy of the TCP authentication draft and | jotting down my observations and comments. | | #1 | I have problem with the term "obsoletes 2385" [ I did bring this up | before] It is going to be a long time before deployments move over to | the new TCP auth option. Practically, "obsoletes" doesn't obsolete anything. It does indicate that the IETF wants a protocol to be replaced by something else. That doesn't mean the older one can't be used for legacy support, e.g., AFAICT - and that clearly should apply here. If the IESG thinks that this is consistent with "Obsoltes", would that be OK? |... Also, TCP-AO is | taking a new TCP option number with backward compatibility in mind. The desire to use a new option KIND is not related to backward compatibility; that can already be determined by the length field, as noted in an earlier draft-touch precursor document. | Abstract | | - It mentions BGP and LDP. FWIW MSDP also uses TCP MD5 and some | proprietary protocols as well. Should we use the word, "long lived | connections" instead? It would probably be useful to use the latter, and give the former as some current examples. | Just wanted to convey the feeling that it is | intended to be a generic TCP authentication option. That was the WG intent AFIACT, and should be captured. | Section 1.1 | | "allows rekeying during a TCP connection " | | 2385 doesn't mention re-keying nor does it preclude one from doing so. | Like I mentioned earlier, deployments have been running code with some | implicit key rollover schemes. That should be clarified to "explicitly supports"... | Section 3 | (security association management (TSAD) | | - IMO, the contents and interpreation of TSAD should be implementation | specific. Applications can use some out of band (or configuration) | mechanism to set up the TSAD. We need to indicate the contents of the TSAD that the key management system would modify, and the ones we depend on. The interpretation of those values is part of the state of the TCP-AO protocol. | - It says : "there MUST be no more than one matching TSAD entry" Not | sure why, you could have a primary and secondary key here. (I understand | that this is not robust) but using a MUST here seems too much of a | restriction. In other words, IMO, this document shouldn't be specifying | too much about TSAD. The goal is to avoid overlapping matches, or sufficiently limit them that the preference is deterministic. Multiple keys would be handled within a single TSAD entry, as well. | - TCP option exclusion : reading this it seems unclear to me as to | whether TCP-AO is excluded in the option calculation or not. Good point. I believe there is no utility in including the option in the calculation. Handling the option confirms the KIND. Matching the MAC confirms the keyID and length. There's nothing left to include. | - it says : "TCP option kind exclusion list MUST NOT change during TCP | connection" Not sure why? Needs explanation. One target requirement (IMO) is to avoid stateful changes during a connection. Otherwise, things like retransmission get messy, and we'd need flags for every parameter that could change, to indicate the appropriate state for a given segment. | - It says "keyID MAY have value of 0" - really what is the point here? This just confirms that there are no reserved values. Some protocols break on corner cases, and this just notes the corner case is the normal case. | Also, shouldn't we allow non-numeric key ID's ? The keyID is just an index; what would the utility of non-numeric keyIDs be? | - "Asymmetric use of TCP-AO" - I am kind of confused here, are we saying | that the ACK's are not going to be signed, from the peer which has | negotaited "NONE" ? Yes. | If so, isn't a security hole since someone can spoof | an ACK and cause issues for the side which HAS signed up for | authentication? Yes - but both sides are agreeing to the authentication used in both directions (even when NONE). If that's not a mode you want to use, then you don't enable it. | - Question : | I have heard cases where some customers (although rare) want the | authentication to be turned off at some point of time, and also turned | on dynamically. TCP, today doesn't allow options negotiation "on | demand", so the latter point is moot for now. What are the thoughts | about turning off the AO option ? IMO, because TCP doesn't turn options on and off during a connection, we shouldn't either. We're trying to create a simple replacement for TCP MD5, not break new ground in TCP option issues. | - TCP user interface - I am not sure why this document (no other TCP | option document even mentions that), for eg:- STATUS call, there is no | such thing as TCP API document, typically BSD sockets are the popular | API set, the point is that you may want to simply say "appropriate API's | for the application to read/configure entries" Just a nitpick since I | haven't seen any other TCP option document even talk about such things.. | This comment can be ignored if needed.. All of the API calls noted in this document are listed exactly because they are described in 793. BSD sockets happen to implement the 793 commands as calls, but the API is actually specified in 793. | - On connectionless resets. | Today, the way implementations work is that when a RST is generated, if | the incoming TCP segment has the TCP MD5 option, then it consults the | database to obtain the key for the the 4 tuple in question. In the case | TCP-AO option with the use of index, you could still obtain this piece | of information and generate the RST. Well, this is a "best effort", but | has been proven to be useful field experience. I'm not sure what you're suggesting here; are you saying we can say we handle connectionless resets the same way as TCP MD5? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiTmTMACgkQE5f5cImnZrvNCgCg31ahJ6uNQ2V12js02aaqfiKP WUAAn0Z6DXgvV5SYWSg+cNLFZvJ4I7Ai =cBkq -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Aug 2 12:00:38 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E8723A6B05; Sat, 2 Aug 2008 12:00:38 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73DE73A6B25 for ; Sat, 2 Aug 2008 12:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.068 X-Spam-Level: X-Spam-Status: No, score=0.068 tagged_above=-999 required=5 tests=[AWL=-1.943, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_STOCK2=3.988] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NICE6wdEOdOC for ; Sat, 2 Aug 2008 12:00:29 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by core3.amsl.com (Postfix) with ESMTP id 12FBD3A6ABB for ; Sat, 2 Aug 2008 12:00:29 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so1308823rvf.49 for ; Sat, 02 Aug 2008 12:00:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=sNLO0X9rF3JeotVDfitGv7U4gDVRKfVWSGsSdQHJDf0=; b=hlWNOi2PLs6A2hpHPYE+8/3JhxotXrgR8W/PXD9KhqTXClJji2VFgflU9pqppxeZ+Q 5xLyXCFXvfTvn5BZU3EcQWiSr0CyeUF4N5viLHCgqY0lfTu7ZspNC7TdGn4gMPsmSBjE aUxvQc/Gj8zalndzpUgtRu45cpx0AzuDkiMPw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=M10gj4d0xaLYKYksiq/Ie9p9YQkS8A4U/3DwgNbW3vdrgpXhemHohDSUhSV7YvZ3iT 9CM7Xm0M+pW9MMkW0gXzk+GYUbGzWLhbVIVtsjEYmVvwHkEUa1saRP+GJ/1tzMHL/7Sb BtFItbAGtfiVF9Ed41xe0XcxsCVp7P62A4yV4= Received: by 10.141.210.13 with SMTP id m13mr6667651rvq.25.1217703650072; Sat, 02 Aug 2008 12:00:50 -0700 (PDT) Received: by 10.141.186.3 with HTTP; Sat, 2 Aug 2008 12:00:50 -0700 (PDT) Message-ID: <396556a20808021200u75c3bdd5h77c328a9b61f8d78@mail.gmail.com> Date: Sat, 2 Aug 2008 12:00:50 -0700 From: "Adam Langley" To: "Joe Touch" In-Reply-To: <48935337.5060205@isi.edu> MIME-Version: 1.0 Content-Disposition: inline References: <396556a20807311252j67b1ab26mf6511dbdae780fdd@mail.gmail.com> <48924496.9060907@isi.edu> <396556a20807311640w2b17d447ud0c51241dc84f682@mail.gmail.com> <48935337.5060205@isi.edu> X-Google-Sender-Auth: f0614fe3df5b5c25 Cc: tcpm@ietf.org Subject: Re: [tcpm] Faster application handshakes with SYN/ACK payloads X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Fri, Aug 1, 2008 at 11:17 AM, Joe Touch wrote: > It's not an experiment; it's valid TCP behavior. Whenever I'm speaking about an experiment, I mean this draft - it being "experimental" > Although there is more detailed feedback below, it might be useful to > raise this up a level. Thanks for your detailed response, I fear that there's a misunderstanding somewhere and that's almost certainly the fault of my inadequate writeups. Please let me try again: At the moment, almost no stacks will send payloads in the SYNACK even though they could as an optimisation. This springs from a few reasons: R1) Processing time for a SYN must be minimal to mitigate the effects of SYN floods. Even waking up an application to process a SYN would greatly increase the costs. R2) Replies to SYNs must be small, otherwise it provides a way to amplify a DDoS attacks using false source IP addresses. R3) The ubiquitous sockets API doesn't make it easy to do so. I'm proposing that a constant payload (optionally with 8 random bytes) overcomes R1 and R3. And limiting the size of that payload to 64 bytes overcomes R2. There are protocols that could immediately benefit from a gradual deployment of hosts which supported a setsockopt to set a constant payload and hosts that would ACK and enqueue such a payload. (I currently know of no stacks that do either however.) SMTP would be one such protocol: clients wait for a 200 code banner from the server before starting their part of the exchange and the banner is small and constant. SMTP is also a protocol which ends up making many, short connections. Additionally, this would also be easy to deploy. For clients that don't support it, they will ACK only the SYN flag and then the server knows to include the payload again in the next frame. However, the sockets API has guided the design of many application level protocols. Because of this, these protocols are often designed such that * The client starts the exchange: see HTTP * The exchange is large, since there's little space pressure: SSH algorithm agreement uses strings like "diffie-hellman-group14-sha1" (28 bytes) because of this. Modifications to take advantage of SYNACK payloads would then require changes to the application level protocol. This could be managed by assigning new ports, trying connections on the new ports first, backing off etc. However, given that this is a partly a latency optimisation, that's an anathema. So I additionally define an option that the application layer can set and query that advertises support for this trick and allows many more application level protocols to take advantage of it. So, fundamentally, we end up with an opportunistic experiment that can provide advantages, but may also have some costs if middleware gets upset etc, as you note: > (side note) Such an option might be useful, but might also be an issue. > It tests the fact that TCPs ignore unknown options, a test that might > fail. It also tests the fact that middleboxes should pass options > unmodified, which also might fail. Because of this, I wanted to make sure that clients were free to retry a connection without the option in the case that something was reacting badly to it. Many of the words in the draft are then dedicated to making sure that both endpoints reach a consistent view of when this option is in effect. Like the prohibition of not including the option in a SYNACK if the previous SYNACK included it. If that were to happen, the endpoint couldn't know which SYNACK the peer saw and thus wouldn't know if the option was in effect or not. For all of your comments that I have removed below, I hope that I've addressed them in the above. If not, please highlight them again and I will attempt to better do so. Also, if the above was clearer then I should consider using it in the draft. To address the remainder of your points: > A 576 MTU is the smallest size that endpoints agree to reassemble; it is > NOT the smallest MTU all links agree to support in the Internet. The > smallest MTU is 68 bytes - i.e., IP with all possible options, TCP with > none, and the smallest possible fragment (8 bytes) [see RFC791]. As a > result, a 64-byte payload is too large to assume that it won't be > fragmented (that may be true practically in many cases, but it isn't a > requirement). I don't believe that we should specify this. If a host finds itself in a situation where the SYNACK payload is problematic in the face of the MTU it may, validly, choose to fragment or to not echo the option. I think the implementations have better information about which is the best course of action. > |> - how do you handle simultaneous opens? > If confirming the option is critical, you need to handle this case. As > noted above, it might not be critical (or even necessary). I believe that both sides will end up with a consistent view of weather the option is in effect (neither will believe it to be so). > | My hope was that by defining a flags option like this, future options > | that require only to signal their presence in a SYN could save space. > That might be a useful to document as a separate issue, since it's > orthogonal to this option. However, you'd need more rules, like the fact > that the responder needs to clear (or truncate) all bits it doesn't > understand or doesn't agree to. Yes, I'll add that words to that effect. Looking at the list of currently assigned options, very few of them are binary flags like this (SACK permitted is the other major one, "Partial Order Connection Permitted", etc), suggesting that it might not be worthwhile. As you point out: > the 25th such flag pays an extra 3-byte penalty when no > other flags are used. Which is true. I'm happy with whatever the consensus is. Cheers AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Aug 3 06:26:35 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 623AF3A6A71; Sun, 3 Aug 2008 06:26:35 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2E533A6A71 for ; Sun, 3 Aug 2008 06:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.389 X-Spam-Level: * X-Spam-Status: No, score=1.389 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_STOCK2=3.988] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRFYjW-1dxG7 for ; Sun, 3 Aug 2008 06:26:32 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id BDCE03A63D3 for ; Sun, 3 Aug 2008 06:26:32 -0700 (PDT) Received: from [192.168.2.121] (bolongo.jbtelenet.com [204.11.152.116]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m73DQk0L006469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 3 Aug 2008 06:26:49 -0700 (PDT) Message-ID: <4895B1F0.3070102@isi.edu> Date: Sun, 03 Aug 2008 06:26:08 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Adam Langley References: <396556a20807311252j67b1ab26mf6511dbdae780fdd@mail.gmail.com> <48924496.9060907@isi.edu> <396556a20807311640w2b17d447ud0c51241dc84f682@mail.gmail.com> <48935337.5060205@isi.edu> <396556a20808021200u75c3bdd5h77c328a9b61f8d78@mail.gmail.com> In-Reply-To: <396556a20808021200u75c3bdd5h77c328a9b61f8d78@mail.gmail.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Faster application handshakes with SYN/ACK payloads X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Adam, Again, popping up a level, you've made a good case for a socket option that lets the server app signal its TCP to try to send data in the SYNACK. TCPs that do this will; TCPs that don't will fail on the socket option, and the server will know. I am unclear why the client TCP is involved in this; if the data is sent, it will either be acknowledged or retransmitted. There is no change to the semantics, and only a change to timing (which NOTHING in TCP ensures anyway). As a minor note, it doesn't seem useful to extend that socket option to say how much data to put in the SYNACK; nothing else in TCP knows about application data boundaries, and I think it would be a mistake to assume that. You might add something like: setsockopt(SEND_SA_DATA, bytecount) where: bytecount = number of data bytes the app is *suggesting* the SA include; this is NOT guaranteed to be enforced by TCP if the sockopt succeeds, the app should reasonably assume that bytecount bytes are sent in the SYNACK if available when the SYNACK is sent As a final question (I'm not a sockets expert), it might be that there are other socket modifications to allow users to write to connections that are not yet open (or can they just be queued up? in which case, it seems like the socket must be completely bound, i.e., this might not work for unbound LISTENs). Specific notes below... Joe Adam Langley wrote: ... | Thanks for your detailed response, I fear that there's a | misunderstanding somewhere and that's almost certainly the fault of my | inadequate writeups. Please let me try again: | | At the moment, almost no stacks will send payloads in the SYNACK even | though they could as an optimisation. This springs from a few reasons: | R1) Processing time for a SYN must be minimal to mitigate the | effects of SYN floods. Even waking up an application to process a SYN | would greatly increase the costs. | R2) Replies to SYNs must be small, otherwise it provides a way to | amplify a DDoS attacks using false source IP addresses. | R3) The ubiquitous sockets API doesn't make it easy to do so. This sounds like a really good reason to extend the API to have a flag that allows the server app to ask its TCP to send data in the SYN-ACK if possible. That sounds consistent with the overall TCP model, AFAICT. I see no good way to have the application tell TCP how many bytes to send, or to have TCP tell the app this. That is an API change that lets the app know about segment boundaries, and that's inconsistent with TCP's API semantics. | I'm proposing that a constant payload (optionally with 8 random bytes) | overcomes R1 and R3. And limiting the size of that payload to 64 bytes | overcomes R2. I don't understand the "8 random bytes" issue; the data path should be sending data from the app only, and that's not random. | There are protocols that could immediately benefit from a gradual | deployment of hosts which supported a setsockopt to set a constant | payload and hosts that would ACK and enqueue such a payload. The sockopt sounds OK - but I'm not too sure about knowing the payload boundaries at the app layer. Again, that is inconsistent with TCP presenting a stream model. ~ > Additionally, this would also be easy to deploy. For clients that | don't support it, they will ACK only the SYN flag and then the server | knows to include the payload again in the next frame. Sure. | However, the sockets API has guided the design of many application | level protocols. Because of this, these protocols are often designed | such that | * The client starts the exchange: see HTTP | * The exchange is large, since there's little space pressure: SSH | algorithm agreement uses strings like "diffie-hellman-group14-sha1" | (28 bytes) because of this. Sure. | Modifications to take advantage of SYNACK payloads would then require | changes to the application level protocol. This could be managed by | assigning new ports, trying connections on the new ports first, | backing off etc. However, given that this is a partly a latency | optimisation, that's an anathema. I don't see this at all. Apps don't need any modification, other than to set the "send data early in the SYNACK" flag. That can be set by default on a per-port basis, or set within the app directly. | So I additionally define an option that the application layer can set | and query that advertises support for this trick and allows many more | application level protocols to take advantage of it. ***this is the big question*** Why do you need an option that does this? Seems like the app can always TRY to do it, and the data just gets retransmitted if dropped (i.e., not supported at the receiver). |> (side note) Such an option might be useful, but might also be an issue. |> It tests the fact that TCPs ignore unknown options, a test that might |> fail. It also tests the fact that middleboxes should pass options |> unmodified, which also might fail. | | Because of this, I wanted to make sure that clients were free to retry | a connection without the option in the case that something was | reacting badly to it. Wouldn't it be simpler to do this without an option at all, then? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiVsfAACgkQE5f5cImnZrvA8gCcD2lJafEkZH4Ue5prXgQAWySv FtsAoPIfNXaZzYqLZCNFlOml85FTi52+ =5dMt -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Aug 3 11:06:09 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E3153A6C1C; Sun, 3 Aug 2008 11:06:09 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85D483A6C1F for ; Sun, 3 Aug 2008 11:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.49 X-Spam-Level: X-Spam-Status: No, score=0.49 tagged_above=-999 required=5 tests=[AWL=-2.121, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_STOCK2=3.988, J_CHICKENPOX_57=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQb-bLYsuG4S for ; Sun, 3 Aug 2008 11:06:06 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by core3.amsl.com (Postfix) with ESMTP id 9F7143A6A11 for ; Sun, 3 Aug 2008 11:06:06 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so1487180rvf.49 for ; Sun, 03 Aug 2008 11:06:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=XPN1xq89NqamBy3nDdEc/XE5449tudAvYKqeoVZclXA=; b=XAOOHCy2TlpPI4CKBMYeRUbkHDmcFO16mEuFyAt19RwUCEVsEn3R+bNfLrFE8heFJL u1MMvtI5liggStoMgO2XohcSGRF6vr8ZjLNRNHcvhw2otQDGKooL7yW0ba4DheDzpprK mGOtt6ZcEv+Ml7EverUumibRr8sGDoLliQGjg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=YUl3qLBjjT1U2ZjoJEmBSc7J7TV0r8iACamUZzDCJEfDhxVDzHchuoQXL+D0MMlVZe fbFio0OCJ3R8PyxFUFWo94QKQQzYYEbk8zhG8jkuQLYNxdWyGT2sF3kAizJ3pU/a/Ml5 zwMrGDGVmnC5zjdBFTsMSh4YaZsRsCQS1+UsQ= Received: by 10.140.139.3 with SMTP id m3mr5741790rvd.44.1217786791275; Sun, 03 Aug 2008 11:06:31 -0700 (PDT) Received: by 10.141.186.3 with HTTP; Sun, 3 Aug 2008 11:06:31 -0700 (PDT) Message-ID: <396556a20808031106q18f6145cu7f6911ad8277d60c@mail.gmail.com> Date: Sun, 3 Aug 2008 11:06:31 -0700 From: "Adam Langley" To: "Joe Touch" In-Reply-To: <4895B1F0.3070102@isi.edu> MIME-Version: 1.0 Content-Disposition: inline References: <396556a20807311252j67b1ab26mf6511dbdae780fdd@mail.gmail.com> <48924496.9060907@isi.edu> <396556a20807311640w2b17d447ud0c51241dc84f682@mail.gmail.com> <48935337.5060205@isi.edu> <396556a20808021200u75c3bdd5h77c328a9b61f8d78@mail.gmail.com> <4895B1F0.3070102@isi.edu> X-Google-Sender-Auth: a60a0fe791e2affc Cc: tcpm@ietf.org Subject: Re: [tcpm] Faster application handshakes with SYN/ACK payloads X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Sun, Aug 3, 2008 at 6:26 AM, Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > As a minor note, it doesn't seem useful to extend that socket option to > say how much data to put in the SYNACK; nothing else in TCP knows about > application data boundaries, and I think it would be a mistake to assume > that. For protocols like SMTP where a constant banner is sent at the beginning of every connection, that's true. As long as the data, if not sent in the SYNACK, is enqueued to be sent anyway, that would certainly work. However, it appears that I've not made the case for the option yet. To do this, let me take HTTP as an example. HTTP is very latency sensitive[1]. Because of this, and guided by the sockets API, the client starts the exchange. Thus, if the client wishes to probe for optional features (like TLS upgrade: RFC2817) the exchange works like this: Client --- OPTIONS ---> Server Client <--- 101 Switching --- Server Client --- GET ---> Server ... Given the latency sensitivity, nobody actually probes for opportunistic TLS like this. If HTTP sent a banner, like SMTP servers, then my life would be a lot easier! The banner could advertise all the extensions supported. However, without SYNACK payloads, this banner would cost another round trip. With SYNACK payloads, we can add this very useful banner without add a round trip. However, servers can't just start including the banner whenever the server's kernel supports the SYNACK payload setsockopt because it would break all the existing clients who wouldn't know what to make of it. Had SYNACK payloads been generally available when HTTP was created, we would have ended up with a different protocol. So, to take advantage of SYNACK payloads in HTTP we need to make a backwards incompatible modification to the protocol. Thus, the option is to decide if this different protocol is in effect. That's why both sides need to reach a consistent view of it. This same logic applies to any protocol that eschewed a server banner for latency reasons. So the new application level exchange looks like: Client <--- Banner --- Server Client --- Request ---> Server Client <--- Reply --- Server But, because of SYNACK payloads, the number of round trips can be the same. > As a final question (I'm not a sockets expert), it might be that there > are other socket modifications to allow users to write to connections > that are not yet open (or can they just be queued up? in which case, it > seems like the socket must be completely bound, i.e., this might not > work for unbound LISTENs). This would be a major change to the sockets API. Additionally, it would require waking up userspace processes for every SYN, making SYN floods more effective. To avoid this, I'm fixing the logic that the application can use and moving it to the kernel. I propose that the logic be: unsigned payload_length; u8 *payload = applications_constant_payload(&payload_length); if (include_random_nonce && payload_length >= 8) { u8 random[8]; generate_random_bytes(random, 8); memcpy(payload, random, 8); } if (only_send_if_requested) { if (SA_PP_option_seen_in_syn) { write(payload, payload_length); } } else { write(payload, payload_length); } > I see no good way to have the application tell TCP how many bytes to > send, or to have TCP tell the app this. That is an API change that lets > the app know about segment boundaries, and that's inconsistent with > TCP's API semantics. In correctness terms, you are correct. It doesn't matter when the banner gets sent, or if it gets split over several packets. However, applications would very much like to know how many bytes the kernel will agree to transmit in reply to a SYN frame because, if a banner would cost an extra round trip they might prefer not to include it. It's because of this that the draft specifies the 64 bytes number. This does expose aspects of segmentation to userspace. However, many scarifies are made in the name of DDoS mitigation. > | I'm proposing that a constant payload (optionally with 8 random bytes) > | overcomes R1 and R3. And limiting the size of that payload to 64 bytes > | overcomes R2. > > I don't understand the "8 random bytes" issue; the data path should be > sending data from the app only, and that's not random. The optional inclusion of random bytes covers the one case where requiring a constant payload is problematic: cryptographic protocols very often want to include a random nonce. Because of this, I'm making an exception to the "constant payload" rule because the kernel can easily fulfill this. [1] (justification that HTTP is very latency sensitive:) I have access to private data that confirms that user-perceived latency is very important, but here are some public quotes to that effect: "In A/B tests (at Amazon.com), we tried delaying the page in increments of 100 milliseconds and found that even very small delays would result in substantial and costly drops in revenue." (http://glinden.blogspot.com/2006/11/marissa-mayer-at-web-20.html) "would you like 10, 20, or 30 results (from a Google search). Users unanimously wanted 30. But 10 did way better in A/B testing (30 was 20% worse) due to lower latency of 10 results. 30 is about twice the latency of 10" (http://perspectives.mvdirona.com/2008/05/29/IO2008RoughNotesFromMarissaMayerDay2KeynoteAtGoogleIO.aspx) Cheers, AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Aug 3 14:14:43 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47BF83A6C5E; Sun, 3 Aug 2008 14:14:43 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5795628C1D6 for ; Sun, 3 Aug 2008 14:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.689 X-Spam-Level: * X-Spam-Status: No, score=1.689 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FRT_STOCK2=3.988, J_CHICKENPOX_57=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7wpnqCcc8Gx for ; Sun, 3 Aug 2008 14:14:40 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id A56533A6C5E for ; Sun, 3 Aug 2008 14:14:39 -0700 (PDT) Received: from [192.168.2.121] (bolongo.jbtelenet.com [204.11.152.116]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m73LEYZP008244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 3 Aug 2008 14:14:37 -0700 (PDT) Message-ID: <48961F94.2040507@isi.edu> Date: Sun, 03 Aug 2008 14:13:56 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Adam Langley References: <396556a20807311252j67b1ab26mf6511dbdae780fdd@mail.gmail.com> <48924496.9060907@isi.edu> <396556a20807311640w2b17d447ud0c51241dc84f682@mail.gmail.com> <48935337.5060205@isi.edu> <396556a20808021200u75c3bdd5h77c328a9b61f8d78@mail.gmail.com> <4895B1F0.3070102@isi.edu> <396556a20808031106q18f6145cu7f6911ad8277d60c@mail.gmail.com> In-Reply-To: <396556a20808031106q18f6145cu7f6911ad8277d60c@mail.gmail.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Faster application handshakes with SYN/ACK payloads X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Adam, Adam Langley wrote: | On Sun, Aug 3, 2008 at 6:26 AM, Joe Touch wrote: |> -----BEGIN PGP SIGNED MESSAGE----- |> As a minor note, it doesn't seem useful to extend that socket option to |> say how much data to put in the SYNACK; nothing else in TCP knows about |> application data boundaries, and I think it would be a mistake to assume |> that. | | For protocols like SMTP where a constant banner is sent at the | beginning of every connection, that's true. As long as the data, if | not sent in the SYNACK, is enqueued to be sent anyway, that would | certainly work. | | However, it appears that I've not made the case for the option yet. To | do this, let me take HTTP as an example. | | HTTP is very latency sensitive[1]. This has been known for a while ;-) e.g.: John Heidemann, Katia Obraczka, and Joe Touch, "Modeling the Performance of HTTP Over Several Transport Protocols", IEEE/ACM Transactions on Networking, V5, N5, Oct. 1997, pp.616-630. | Because of this, and guided by the | sockets API, the client starts the exchange. Thus, if the client | wishes to probe for optional features (like TLS upgrade: RFC2817) the | exchange works like this: | Client --- OPTIONS ---> Server | Client <--- 101 Switching --- Server | Client --- GET ---> Server | ... | | Given the latency sensitivity, nobody actually probes for | opportunistic TLS like this. | | If HTTP sent a banner, like SMTP servers, then my life would be a lot | easier! The banner could advertise all the extensions supported. That sounds like a useful thing to raise to the httpbis WG, FWIW. | However, without SYNACK payloads, this banner would cost another round | trip. I have noted this before; an extra RTT doesn't do much of anything. There are more delays in HTTP over TCP that incur round trips, e.g., dealing with interactions with sending an ACK every other segment, as well as apps that fail to disable Nagle optimizations (as they should when they're interactive and have messages longer than a single byte). | With SYNACK payloads, we can add this very useful banner without add a | round trip. However, servers can't just start including the banner | whenever the server's kernel supports the SYNACK payload setsockopt | because it would break all the existing clients who wouldn't know what | to make of it. This is where you've lost me. Server TCPs can send data in the SYNACK. Clients that ACK just the SYN cause the server to retransmit; clients that ACK the whole segment work as you intend. What part if this isn't sufficient? | Had SYNACK payloads been generally available when HTTP was created, we | would have ended up with a different protocol. Please explain. From the app point of view, *nothing changes*. TCP is a stream oriented protocol, and ***NOTHING*** the app does necessarily correlates to particular segments. The app sees the data get there. I.e., apps that require any sort of realtime behavior ought not be using TCP. ... |> As a final question (I'm not a sockets expert), it might be that there |> are other socket modifications to allow users to write to connections |> that are not yet open (or can they just be queued up? in which case, it |> seems like the socket must be completely bound, i.e., this might not |> work for unbound LISTENs). | | This would be a major change to the sockets API. I agree, but isn't that where this is going? If not, how do you expect it to be used? ... | To avoid this, I'm fixing the logic that the application can use and | moving it to the kernel. I propose that the logic be: | | unsigned payload_length; | u8 *payload = applications_constant_payload(&payload_length); | | if (include_random_nonce && payload_length >= 8) { | u8 random[8]; | generate_random_bytes(random, 8); | memcpy(payload, random, 8); | } | | if (only_send_if_requested) { | if (SA_PP_option_seen_in_syn) { | write(payload, payload_length); | } | } else { | write(payload, payload_length); | } This code is confusing; is it a library that happens to be in the kernel, or is it intended to be code inside TCP? If it's just a library, it doesn't matter where it is. To TCP, the "write" calls are its "application". There is no such thing as a payload length at that point; the app has no knowledge of how writes correspond to payload entities. If this is intended inside TCP, you're having TCP insert data into the user stream. That changes TCP semantics. Can you explain which of the above applies, or some other interpretation that explains the code without such inconsistencies? |> I see no good way to have the application tell TCP how many bytes to |> send, or to have TCP tell the app this. That is an API change that lets |> the app know about segment boundaries, and that's inconsistent with |> TCP's API semantics. | | In correctness terms, you are correct. It doesn't matter when the | banner gets sent, or if it gets split over several packets. However, | applications would very much like to know how many bytes the kernel | will agree to transmit in reply to a SYN frame because, if a banner | would cost an extra round trip they might prefer not to include it. ***WHY???*** I know I'm repeating myself here, but ***TCP IS NOT A REALTIME PROTOCOL***, and there is *no correlation between user writes and segment boundaries*. ... | [1] (justification that HTTP is very latency sensitive:) | | I have access to private data that confirms that user-perceived | latency is very important, but here are some public quotes to that | effect: | | "In A/B tests (at Amazon.com), we tried delaying the page in | increments of 100 milliseconds and found that even very small delays | would result in substantial and costly drops in revenue." | (http://glinden.blogspot.com/2006/11/marissa-mayer-at-web-20.html) | | "would you like 10, 20, or 30 results (from a Google search). Users | unanimously wanted 30. But 10 did way better in A/B testing (30 was | 20% worse) due to lower latency of 10 results. 30 is about twice the | latency of 10" (http://perspectives.mvdirona.com/2008/05/29/IO2008RoughNotesFromMarissaMayerDay2KeynoteAtGoogleIO.aspx) Did you actually try reducing the overal latency of a single TCP connection by 1 RTT and see if it actually matters? If these apps are using persistent connections, then the first RTT exchange is all they'll see anyway. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiWH5QACgkQE5f5cImnZrti5ACgvMuGJimDVOxm+vVPYl1OjYGK aKQAn2Qid+EPficLglJ+AiXItYQNs0FS =1lzN -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Aug 3 20:07:20 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9844D3A6AFB; Sun, 3 Aug 2008 20:07:20 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64DAD3A6A05 for ; Sun, 3 Aug 2008 20:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.851 X-Spam-Level: X-Spam-Status: No, score=-5.851 tagged_above=-999 required=5 tests=[AWL=0.749, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmqdXniuNbhr for ; Sun, 3 Aug 2008 20:07:18 -0700 (PDT) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id 715593A6984 for ; Sun, 3 Aug 2008 20:07:18 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id D5FE33280F7; Sun, 3 Aug 2008 22:07:44 -0500 (CDT) Received: from ndjsxgw04.ndc.nasa.gov (ndjsxgw04.ndc.nasa.gov [129.166.32.112]) by ndjsppt03.ndc.nasa.gov (8.14.1/8.14.1) with ESMTP id m7437iAv016688; Sun, 3 Aug 2008 22:07:44 -0500 Received: from NDJSEVS25A.ndc.nasa.gov ([129.166.32.124]) by ndjsxgw04.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.3959); Sun, 3 Aug 2008 22:07:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 3 Aug 2008 22:07:53 -0500 Message-ID: In-Reply-To: <4892063D.3010703@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Persist condition clarification draft, now "clarification of sending behavior" draft - comments solicited Thread-Index: AcjzPM5WcIgEnUoWQXCU+0RTfPqVLwCoMtTg References: <4892063D.3010703@cisco.com> From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" To: "Mahesh Jethanandani" , X-OriginalArrivalTime: 04 Aug 2008 03:07:44.0885 (UTC) FILETIME=[4415CA50:01C8F5DF] Subject: Re: [tcpm] Persist condition clarification draft, now "clarification of sending behavior" draft - comments solicited X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org >-----Original Message----- >From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On >Behalf Of Mahesh Jethanandani >Sent: Thursday, July 31, 2008 2:37 PM >To: tcpm@ietf.org >Subject: [tcpm] Persist condition clarification draft, now >"clarification of sending behavior" draft - comments solicited > >Apologies for sending this message twice, but did not realize that my >previous subject line attracted some spam filters (including my own). > >During the TCPM meeting in Dublin, Wes wanted to encourage readers on >this mailing list to read the short (2 pages if you remove the boiler >plate part) draft on "Clarification of Sender Behavior Under Persist >Condition" draft. > >To enable a quick read, I have cut and pasted the relevant sections >here. As noted in the meeting, this draft tries to clarify the sender >behavior without getting into the details of the DoS scenario and the >possible solutions. Just to reiterate, it is this draft and not the >original persist draft that we are trying to table for >adoption as a WG >item. Thanks for sending the text. As just a TCPM participant: I've read it, and I don't have any major problem with it, though there are some editorial items I noticed. I'm personally in-favor of sending it through TCPM. It seems very non-controversial to me in its conclusion and the examination of existing code seemed to show that it made sense to lay out in an RFC rather than just trusting that implementers will understand 1122 and the potential for DoS if they don't have some mechanism for reaping TCBs stalled in persist. As TCPM co-chair, I hope other people will chime in for or against taking this on as a WG item in the next couple weeks. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Aug 3 20:57:43 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4870A3A6A35; Sun, 3 Aug 2008 20:57:43 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 482D53A69B3 for ; Sun, 3 Aug 2008 20:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.024 X-Spam-Level: X-Spam-Status: No, score=-6.024 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwG-kqa-otTI for ; Sun, 3 Aug 2008 20:57:38 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id E0E883A683B for ; Sun, 3 Aug 2008 20:57:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,302,1215388800"; d="scan'208";a="135298091" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 04 Aug 2008 03:58:05 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m743w5bY003631; Sun, 3 Aug 2008 20:58:05 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m743w5QF019463; Mon, 4 Aug 2008 03:58:05 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 3 Aug 2008 20:58:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 3 Aug 2008 20:56:56 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5805923E25@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <48939933.3030601@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] TCP-AO review comments. Thread-Index: Acj0RuxMZJiU6iePRM+oBA9CrFffTABl+G2g References: <0C53DCFB700D144284A584F54711EC58058C2FD4@xmb-sjc-21c.amer.cisco.com> <48939933.3030601@isi.edu> From: "Anantha Ramaiah (ananth)" To: "Joe Touch" X-OriginalArrivalTime: 04 Aug 2008 03:58:05.0152 (UTC) FILETIME=[4C4DF600:01C8F5E6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7251; t=1217822285; x=1218686285; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20 |Subject:=20RE=3A=20[tcpm]=20TCP-AO=20review=20comments. |Sender:=20; bh=B9r589V2eTDGGyzYPpbVhbSWyD7gzJ7h74035iIGq6M=; b=Gazf0WB6+fUvZcOvK8MtwuPQbphqOXYfpHERc1NySQRO+L/BtxYZ7baTbh azi1uKymleN/YQoGhKllCCKbLN8AyhUknyUe07S2cQ0SsfHVjBaVwi2AUCvG GYkiakpAnCip2GZpyA3V4S7HU8OnfhGg+oIguBRlCjVjWC+eJjp0o=; Authentication-Results: sj-dkim-1; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: tcpm@ietf.org Subject: Re: [tcpm] TCP-AO review comments. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Joe, > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU] > Sent: Friday, August 01, 2008 4:16 PM > To: Anantha Ramaiah (ananth) > Cc: tcpm@ietf.org > Subject: Re: [tcpm] TCP-AO review comments. > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Ananth, > > Thanks for posting the comments. Some notes/questions below. Pl find inline responses. > > Anantha Ramaiah (ananth) wrote: > | Hi, > | I went over the latest copy of the TCP authentication draft and > | jotting down my observations and comments. > | > | #1 > | I have problem with the term "obsoletes 2385" [ I did > bring this up > | before] It is going to be a long time before deployments > move over to > | the new TCP auth option. > > Practically, "obsoletes" doesn't obsolete anything. It does > indicate that the IETF wants a protocol to be replaced by > something else. That doesn't mean the older one can't be used > for legacy support, e.g., AFAICT - and that clearly should > apply here. If the IESG thinks that this is consistent with > "Obsoltes", would that be OK? Sure, ok let me rephrase the question here : "TCP MD5 option would continue to exist and should be supported for quite sometime" Does "obselete" allow this fact? I would have preferred "Updates/Revises" which gives some leeway for co-existence to support legacy. That's just me.. Anyways I was hoping to see more discussion on this and the collective wisdom of this WG on this aspect. > > | Section 3 > | (security association management (TSAD) > | > | - IMO, the contents and interpreation of TSAD should be > implementation > | specific. Applications can use some out of band (or configuration) > | mechanism to set up the TSAD. > > We need to indicate the contents of the TSAD that the key > management system would modify, and the ones we depend on. > The interpretation of those values is part of the state of > the TCP-AO protocol. Hmm.. This makes the specification more complicated, IMO. I would have preferred to move these stuff under implemntation section. Anyways if the WG is ok with the current structure, I am fine with it too. > > | - It says : "there MUST be no more than one matching TSAD > entry" Not > | sure why, you could have a primary and secondary key here. (I > | understand that this is not robust) but using a MUST here seems too > | much of a restriction. In other words, IMO, this document > shouldn't be > | specifying too much about TSAD. > > The goal is to avoid overlapping matches, or sufficiently > limit them that the preference is deterministic. Multiple > keys would be handled within a single TSAD entry, as well. Ok, that clarifies. > | - it says : "TCP option kind exclusion list MUST NOT change > during TCP > | connection" Not sure why? Needs explanation. > > One target requirement (IMO) is to avoid stateful changes > during a connection. Otherwise, things like retransmission > get messy, and we'd need flags for every parameter that could > change, to indicate the appropriate state for a given segment. Repacketization combines multiple segments into one, thereby dictating a new ipid for example, so such things aren't considered messy, the question becomes how much flexibility you want to provide here... > > The keyID is just an index; what would the utility of > non-numeric keyIDs be? Key ID's are generally going to be an index assuming you have a TSAD like database ( agreed this is what we do in our implementations today). I was just asking whether we should allow non-numeric key ID's as well? I can't think of any utility value on top of my head.. > > | If so, isn't a security hole since someone can spoof an ACK > and cause > | issues for the side which HAS signed up for authentication? > > Yes - but both sides are agreeing to the authentication used > in both directions (even when NONE). If that's not a mode you > want to use, then you don't enable it. Fair enough :-) At the least the document needs to narrate the repurcussions of doing so. > > | - Question : > | I have heard cases where some customers (although rare) want the > | authentication to be turned off at some point of time, and > also turned > | on dynamically. TCP, today doesn't allow options negotiation "on > | demand", so the latter point is moot for now. What are the thoughts > | about turning off the AO option ? > > > IMO, because TCP doesn't turn options on and off during a > connection, we shouldn't either. We're trying to create a > simple replacement for TCP MD5, not break new ground in TCP > option issues. Ok. > | - On connectionless resets. > | Today, the way implementations work is that when a RST is > generated, > | if the incoming TCP segment has the TCP MD5 option, then it > consults > | the database to obtain the key for the the 4 tuple in > question. In the > | case TCP-AO option with the use of index, you could still > obtain this > | piece of information and generate the RST. Well, this is a "best > | effort", but has been proven to be useful field experience. > > I'm not sure what you're suggesting here; are you saying we > can say we handle connectionless resets the same way as TCP MD5? The point I am trying to make is that 2385 didn't elaborate on connectionless resets, nor does TCP AO. However the implementations (like IOS) have done the following today w.r.t TCP MD5 : - if there is no control block (for whatever reason) && if the incoming segment has MD5 option present, TCP consults the application (or TSAD) to retrieve the key associated with this 4 tuple (src addr, .....). - It then uses that to sign (compute digest) the RST packet. Doing this has proven to be a good scheme to recover from half open TCB's, since if you don't sign your RST the other end won't accept it. [ it has to incur an application timeout, we have seen ACK wars in some cases etc.,) I was thinking that this can be explicitly stated in the document. [Yes, I agree that there is corner case here, what if the key value changed in between Or you can't retrieve the key for some valid reasons (the whole box crashed and the key database is gone), etc., but those events are rare and hence I call this a best-effort approach which has worked well for us] Thinking a bit differently here, both TCP MD5 and TCP AO, in some sense have violated the RFC 793 mechanism of host/TCP crash recovery (RST's) and silently resorted to application timeouts to fix this! Well this sort of mandates an application timeout. For applications like BGP etc., this is probably not an issue, but if we are looking at TCP AO as a generic auth mechanism, then it seems like an issue. This fact needs to be docuemnted. [ I see the security consideration does mention it briefly but there is scope to expand on this somewhere in a separate section by itself] Hope this is clear, now. -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Aug 3 21:56:59 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC73A3A6BFB; Sun, 3 Aug 2008 21:56:58 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F10353A6BFB for ; Sun, 3 Aug 2008 21:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.839 X-Spam-Level: X-Spam-Status: No, score=-5.839 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2P4sZavA4OR for ; Sun, 3 Aug 2008 21:56:52 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 1727A3A69C0 for ; Sun, 3 Aug 2008 21:56:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,302,1215388800"; d="scan'208";a="135314119" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 04 Aug 2008 04:57:10 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m744vAwU023503; Sun, 3 Aug 2008 21:57:10 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m744vArg009177; Mon, 4 Aug 2008 04:57:10 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 3 Aug 2008 21:57:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 3 Aug 2008 21:56:01 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5805923E2D@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <396556a20807311252j67b1ab26mf6511dbdae780fdd@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Faster application handshakes with SYN/ACK payloads Thread-Index: AcjzRwTQlivZSJ0cRuePYUMN2eCTGgCjQKZQ References: <396556a20807311252j67b1ab26mf6511dbdae780fdd@mail.gmail.com> From: "Anantha Ramaiah (ananth)" To: "Adam Langley" , X-OriginalArrivalTime: 04 Aug 2008 04:57:10.0050 (UTC) FILETIME=[8D3A7820:01C8F5EE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7654; t=1217825830; x=1218689830; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20 |Subject:=20RE=3A=20[tcpm]=20Faster=20application=20handsha kes=20with=20SYN/ACK=20payloads |Sender:=20; bh=pKOlTpXkFSC834VluhGpWlYZbNfKtnIgRaVwKOccpCw=; b=gzQS6GcyLR3HTUXiobSxApZke6nN+nNSaXAZXXG/V9p9ONRm4M0aSAgBOa 2k0jsi/33MFrHx3aVYNk3Yz9ccqL/5DPLxc57Ef54Ah6mpgyUl1Sh9CCINod Z5MvnU46m/v+/0Ebb/Wo4iR6B/xfZvKuI0sWjepEggIWKAK0wUtAg=; Authentication-Results: sj-dkim-1; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [tcpm] Faster application handshakes with SYN/ACK payloads X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Adam, I managed to read this draft on my return flight and had marked some comments. I have only cursorily glanced at the other comments and hence there could be a possibility of overlap with what has been already mentioned. Abstract - fix the sentence : "we should how this has...." - you mention "cryptographic applications" would benefit with this proposal, and give example of SSH in your draft. It would be really interesting to know how many very commonly used TCP applications would really benefit with this ? Atleast the draft can mention those.. - with the SSH example which you give, it appears that one of the advantages of this proposal is that you can tear down the connection before the connection moves to ESTAB if the authentication fails? (For eg:- some implementations don't create a full blown TCB before TWHS completes) Section 3 : - Can you elaborate on the flags option? It simply mentions that the meaning of this would be assigned by IANA? Again this is not infinite (2+n, n is finite) since it should be bounded by the TCP header length inclusive of options? - the doc says (section 3 ) "host MUST not include data payload in SYN+ACK resulting from a SYN frame without SYNACK payload permitted" But RFC 793 does permit data in SYN which includes SYN+ACK, so this statement raises a new level of ambiguity. Section 4: You mention 64 bytes of payload is enough to include sufficient crypto material. Just wondering the interoperability of this statement with TCP auth (TCP MD5 and TCP AO for example) What about Kamikaze like packets ? where SYN, FIN are set the applications can send data and also set the FIN bit in the oriinal SYN (Not sure if 793 talks about it but Stevens book does mention it and so as BSD implementatiosns which support this type of packets) Would those still work within your proposal? Also, the applications need to change to make use of this proposal (the HTTP example which you mention below) In other words, it would be nice if you can explain the "opportunistic encryption" scheme and how applications (which all) can benefit from your proposal in more detail in the draft. -Anantha > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > Behalf Of Adam Langley > Sent: Thursday, July 31, 2008 12:52 PM > To: tcpm@ietf.org > Subject: [tcpm] Faster application handshakes with SYN/ACK payloads > > I posted this a while back and it gathered a little discussion: > > http://www.ietf.org/internet-drafts/draft-agl-tcpm-sadata-00.txt > (implementation in [1]) > > I would like to have this published as Experimental and to > get an option number assigned. > > The spec itself includes a somewhat rambling justification > because I wanted to decouple the spec, which is more general, > from the exact reason that I wish to start testing this over > the Internet at large. > However, in order to provoke discussion I think I should explain my > motivation: > > This spec allows for opportunistic encryption of TCP > connections with no additional round trips. Details of the > project can be found at [2], however a quick summary follows: > > Although SYN/ACK payloads could be used to accelerate many > protocols, I'm proposing that, for HTTP, the SYN/ACK payload > contains an 8-byte random nonce and a 32-byte eliptic-curve > public value. The client can then perform key agreement and > send it's own public value, nonce and any encrypted payload > in the final ACK. (Or in a following packet, that works fine > too). Data is then encrypted using Salsa20/8 where the key is > SHA256(diffie-hellman output + server nonce + client nonce) > and the IVs are 0 and 2**63 for client->server and > server->client, resp. > > Obviously, this open to both a downgrade and man-in-the-middle attack. > For a specific user, it offers little real security. However, > amortised over a large set of users, any ISPs performing > these attacks on a large scale will be detected. (I plan on > building a network of hosts probing for large scale attacks.) > Thus, eavesdroppers are removed from the equation and, > against the rest, it can protect most of the people, most of the time. > > I also plan to sign the resulting packets with TCP-AO at some > point, if possible. However, given that that is still under > development I'm going to make that part of the negotiation, > above, so that it can be deployed without it for now. > > Obviously, this system can only prove itself in time. > However, it can't prove itself with an option number > assigned. And thus, I'm looking for a consensus that this is > an interesting experiment. > > Thanks > > Having spoken to quite a few people about this, I now have an > FAQ on the design which is included below: > > * Why Elliptic-curves? > > The payload must be short otherwise SYN-floods could use this > as an amplification to backscatter DDoS another host. > > Also, the reduced computation cost (as compared to > Diffie-Hellman over a multiplicative finite field) is very nice. > > * Why 25519? > > It's very fast (2000 ops/sec with my C code. 4000 ops/sec > with asm). Also, the server's public value must be constant, > otherwise an attacker could eat CPU time with a SYN flood and > curve25519 is designed for that. > > Since this is constant for all connections, there is no > perfect forward secrecy. > > * Can't you fit the client's public value in the SYN? > > A SYN generally has 20 bytes of free option space these days. > (We can't use the payload space in a SYN). Since this can't > be the last option ever, we need to leave 4 bytes spare. 2 > bytes for the option header means 14 bytes for the public > value. The closest prime is 2**112-75. > > I'm a bear of little brain and picking my own curve is > already a hell of a task, but assuming that I can: > > The best, general algorithm currently known for breaking the > DH problem on elliptic curves is Pollard's Rho. The work > involved in this attack is sqrt(n), which is 2**56 in this > case. Critically, once you have solved a single instance you > can precompute tables to speed up breaking more instances. > With a petabyte of storage, you could break 112-bit curves in > 2**12 operations, which is very fast. > > * Can't you use a smaller field anyway? > > Some speedup could be gained by using an EC with a field size > around 200 bits. > However the effort of defining such a curve is pretty huge. > The standard NIST curves around that size are slower: > > http://www.cacr.math.uwaterloo.ca/techreports/2003/corr2003-18 > .pdf (table 6) > > * Why Salsa20/8? > > It encrypts at two cycles per byte on modern CPUs[1]. The > best attack on this, reduced round, variant is 2**251. It's > very unlikely that an attack would ever break it to the point > that it's easier than performing a downgrade attack. > > http://cr.yp.to/streamciphers/phase3speed-20080331.pdf > > > > [1] > http://code.google.com/p/obstcp/source/browse/trunk/patches/sy > nack-payload > [2] http://code.google.com/p/obstcp/ > > -- > Adam Langley agl@imperialviolet.org > http://www.imperialviolet.org > _______________________________________________ > 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 From tcpm-bounces@ietf.org Mon Aug 4 06:25:40 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8552E3A683E; Mon, 4 Aug 2008 06:25:40 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E1133A683E for ; Mon, 4 Aug 2008 06:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.271 X-Spam-Level: X-Spam-Status: No, score=-7.271 tagged_above=-999 required=5 tests=[AWL=1.327, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwDx4UvVX8uo for ; Mon, 4 Aug 2008 06:25:34 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 504B73A680B for ; Mon, 4 Aug 2008 06:25:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,304,1215388800"; d="scan'208,217";a="135459641" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 04 Aug 2008 13:26:02 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m74DQ2Hv009383; Mon, 4 Aug 2008 06:26:02 -0700 Received: from [10.21.51.104] ([10.21.51.104]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m74DQ0Ls007655; Mon, 4 Aug 2008 13:26:01 GMT Message-ID: <48970365.6070402@cisco.com> Date: Mon, 04 Aug 2008 06:25:57 -0700 From: Mahesh Jethanandani Organization: Cisco Systems Inc. User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Caitlin Bestler References: <78C9135A3D2ECE4B8162EBDCE82CAD7704041514@nekter> In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD7704041514@nekter> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8280; t=1217856362; x=1218720362; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mahesh@cisco.com; z=From:=20Mahesh=20Jethanandani=20 |Subject:=20RE=3A=20[tcpm]=20Persist=20condition=20clarific ation=20draft,=20now=20=22clarification=0A=20of=20sending=20 behavior=22=20draft=20-=20comments=20solicited |Sender:=20; bh=2/3PzNOBC94rsHlg9wxavVZdWyDVlpIaL6KEwryYE0g=; b=NJJ2CDApYA6gPl7z65ngvltb608JpEyjQO3L29krIf6oCqbeVZ1BlHv40N fPfvYhE3HqtYUtxXczdglXFEuRnZeMDi9RN3Ieno/uIY0bQJ5RVbRx3sWT5Y Q/Tq3i+h8S; Authentication-Results: sj-dkim-2; header.From=mahesh@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: tcpm@ietf.org Subject: Re: [tcpm] Persist condition clarification draft, now "clarification of sending behavior" draft - comments solicited X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1445604922==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is a multi-part message in MIME format. --===============1445604922== Content-Type: multipart/alternative; boundary="------------020102050308080707070706" This is a multi-part message in MIME format. --------------020102050308080707070706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Changing the Subject to align it with the other thread. Caitlin Bestler wrote: > > Is an RFC really needed? > > I've always assumed that the application layer MAY > do pretty much whatever it wants. Further application > layer servers SHOULD protect their own resources against > abusive clients. Those protection mechanisms MAY include > terminating connections. > That is true, and if you read 793 is states it as such. What causes some of confusion is the verbiage in 1122. While 1122 is not contradicting what is stated in 793, if you look at most implementations, the verbiage in 1122 is implemented to the letter T but hardly anyone has implemented anything mentioned in 793 for the same scenario. The result is a DoS attack. Take Linux as an example. Here are some sample comments from the code base and note the confusion > 241 *//* *WARNING* RFC 1122 forbids this/* > 242 */ */* > 243 */ * It doesn't AFAIK, because we kill the retransmit timer -AK/* > 244 */ */* > 245 */ * FIXME: We ought not to do it, Solaris 2.5 actually has fixing/* > 246 */ * this behaviour in Solaris down as a bug fix. [AC]/* > 247 */ */* > 248 */ * Let me to explain. icsk_probes_out is zeroed by incoming ACKs/* > 249 */ * even if they advertise zero window. Hence, connection is killed only/* > 250 */ * if we received no ACKs for normal connection timeout. It is not killed/* > 251 */ * only because window stays zero for some time, window may be zero/* > 252 */ * until armageddon and even later. We are in full accordance/* > 253 */ * with RFCs, only probe timer combines both retransmission timeout/* > 254 */ * and probe timeout in one bottle. --ANK/* > 255 */ *//* > The actual implementation of Linux has TCP keeping track of connections in persist condition and terminating them when the number of "orphaned connections" exceeds a certain threshold. We believe that is because of the confusion around the verbiage of 1122. And thus the clarification needed. > > > All of that is true independent of any specific method > of abusing server resources. > -- mahesh --------------020102050308080707070706 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Changing the Subject to align it with the other thread.

Caitlin Bestler wrote:
RE: [tcpm] Please read

Is an RFC really needed?

I've always assumed that the application layer MAY
do pretty much whatever it wants. Further application
layer servers SHOULD protect their own resources against
abusive clients. Those protection mechanisms MAY include
terminating connections.

That is true, and if you read 793 is states it as such. What causes some of confusion is the verbiage in 1122. While 1122 is not contradicting what is stated in 793, if you look at most implementations, the verbiage in 1122 is implemented to the letter T but hardly anyone has implemented anything mentioned in 793 for the same scenario. The result is a DoS attack.

Take Linux as an example. Here are some sample comments from the code base and note the confusion
241         /* *WARNING* RFC 1122 forbids this
242          *
243          * It doesn't AFAIK, because we kill the retransmit timer -AK
244          *
245          * FIXME: We ought not to do it, Solaris 2.5 actually has fixing
246          * this behaviour in Solaris down as a bug fix. [AC]
247          *
248          * Let me to explain. icsk_probes_out is zeroed by incoming ACKs
249          * even if they advertise zero window. Hence, connection is killed only
250          * if we received no ACKs for normal connection timeout. It is not killed
251          * only because window stays zero for some time, window may be zero
252          * until armageddon and even later. We are in full accordance
253          * with RFCs, only probe timer combines both retransmission timeout
254          * and probe timeout in one bottle.                             --ANK
255          */
The actual implementation of Linux has TCP keeping track of connections in persist condition and terminating them when the number of "orphaned connections" exceeds a certain threshold.

We believe that is because of the confusion around the verbiage of 1122. And thus the clarification needed.


All of that is true independent of any specific method
of abusing server resources.


-- mahesh
--------------020102050308080707070706-- --===============1445604922== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============1445604922==-- From tcpm-bounces@ietf.org Mon Aug 4 07:29:42 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D3EC28C2B9; Mon, 4 Aug 2008 07:29:42 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CED6028C2AD for ; Mon, 4 Aug 2008 07:29:40 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rw68K3sVj9OY for ; Mon, 4 Aug 2008 07:29:39 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 05E5428C2B4 for ; Mon, 4 Aug 2008 07:29:39 -0700 (PDT) Received: from [75.210.73.243] (243.sub-75-210-73.myvzw.com [75.210.73.243]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m74ETFjg002882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 4 Aug 2008 07:29:23 -0700 (PDT) Message-ID: <48971214.6070303@isi.edu> Date: Mon, 04 Aug 2008 07:28:36 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <0C53DCFB700D144284A584F54711EC58058C2FD4@xmb-sjc-21c.amer.cisco.com> <48939933.3030601@isi.edu> <0C53DCFB700D144284A584F54711EC5805923E25@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC5805923E25@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] TCP-AO review comments. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Ananth, Just a few remaining points to clarify... Anantha Ramaiah (ananth) wrote: |> | #1 |> | I have problem with the term "obsoletes 2385" [ I did |> bring this up |> | before] It is going to be a long time before deployments |> move over to |> | the new TCP auth option. |> |> Practically, "obsoletes" doesn't obsolete anything. It does |> indicate that the IETF wants a protocol to be replaced by |> something else. That doesn't mean the older one can't be used |> for legacy support, e.g., AFAICT - and that clearly should |> apply here. If the IESG thinks that this is consistent with |> "Obsoltes", would that be OK? | | Sure, ok let me rephrase the question here : "TCP MD5 option would | continue to exist and should be supported for quite sometime" Does | "obselete" allow this fact? My impression is that it does, i.e., it recommends replacement, but doesn't prevent it being used for legacy purposes. < I would have preferred "Updates/Revises" | which gives some leeway for co-existence to support legacy. We're not changing anything in TCP MD5, so we neither update nor revise it. It seems like those of us replying are in agreement on this overall point, but don't quite know what the best language to use is (if others want to debate that point, though, please do). It might be useful to ask the IESG for advice (which I will do). |> | Section 3 |> | (security association management (TSAD) |> | |> | - IMO, the contents and interpreation of TSAD should be |> implementation |> | specific. Applications can use some out of band (or configuration) |> | mechanism to set up the TSAD. |> |> We need to indicate the contents of the TSAD that the key |> management system would modify, and the ones we depend on. |> The interpretation of those values is part of the state of |> the TCP-AO protocol. | | Hmm.. This makes the specification more complicated, IMO. I would have | preferred to move these stuff under implemntation section. Anyways if | the WG is ok with the current structure, I am fine with it too. We can continue to examine this issue; if it's considered an implementation detail (as with IPsec), we can omit the specifics. The goal is to enable others to design key management systems that interoperate with TCP-AO (in IPsec, there is only one such KMS - IKE). |> | - it says : "TCP option kind exclusion list MUST NOT change |> during TCP |> | connection" Not sure why? Needs explanation. |> |> One target requirement (IMO) is to avoid stateful changes |> during a connection. Otherwise, things like retransmission |> get messy, and we'd need flags for every parameter that could |> change, to indicate the appropriate state for a given segment. | | Repacketization combines multiple segments into one, thereby dictating a | new ipid for example, so such things aren't considered messy, the | question becomes how much flexibility you want to provide here... It would be difficult to support repacketization and ensure authentication, AFAICT. How do others feel? |> The keyID is just an index; what would the utility of |> non-numeric keyIDs be? | | Key ID's are generally going to be an index assuming you have a TSAD | like database ( agreed this is what we do in our implementations today). | I was just asking whether we should allow non-numeric key ID's as well? | I can't think of any utility value on top of my head.. It's interpreted as an index; if you want it to be, e.g., a single ASCII character, it wouldn't matter to us. |> | If so, isn't a security hole since someone can spoof an ACK |> and cause |> | issues for the side which HAS signed up for authentication? |> |> Yes - but both sides are agreeing to the authentication used |> in both directions (even when NONE). If that's not a mode you |> want to use, then you don't enable it. | | Fair enough :-) At the least the document needs to narrate the | repurcussions of doing so. Agreed. |> | - On connectionless resets. |> | Today, the way implementations work is that when a RST is |> generated, |> | if the incoming TCP segment has the TCP MD5 option, then it |> consults |> | the database to obtain the key for the the 4 tuple in |> question. In the |> | case TCP-AO option with the use of index, you could still |> obtain this |> | piece of information and generate the RST. Well, this is a "best |> | effort", but has been proven to be useful field experience. |> |> I'm not sure what you're suggesting here; are you saying we |> can say we handle connectionless resets the same way as TCP MD5? | | The point I am trying to make is that 2385 didn't elaborate on | connectionless resets, nor does TCP AO. However the implementations | (like IOS) have done the following today w.r.t TCP MD5 : | | - if there is no control block (for whatever reason) && if the incoming | segment has MD5 option present, TCP consults the application (or TSAD) | to retrieve the key associated with this 4 tuple (src addr, .....). | | - It then uses that to sign (compute digest) the RST packet. | | Doing this has proven to be a good scheme to recover from half open | TCB's, since if you don't sign your RST the other end won't accept it. [ | it has to incur an application timeout, we have seen ACK wars in some | cases etc.,) | | I was thinking that this can be explicitly stated in the document. Agreed. ... | Thinking a bit differently here, both TCP MD5 and TCP AO, in some sense | have violated the RFC 793 mechanism of host/TCP crash recovery (RST's) | and silently resorted to application timeouts to fix this! Well this | sort of mandates an application timeout. For applications like BGP etc., | this is probably not an issue, but if we are looking at TCP AO as a | generic auth mechanism, then it seems like an issue. This fact needs to | be docuemnted. [ I see the security consideration does mention it | briefly but there is scope to expand on this somewhere in a separate | section by itself] We should discuss this on the list further; this is definitely a tricky case. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiXEhQACgkQE5f5cImnZrtLbACgtofaL+yx8L4Ge21EJctgpoJG oj0An1cJMaXNNLnAC3xTnBueWNanZlBb =nxX4 -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Aug 4 08:01:16 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43C9128C292; Mon, 4 Aug 2008 08:01:16 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 343E428C2D0 for ; Mon, 4 Aug 2008 08:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.957 X-Spam-Level: X-Spam-Status: No, score=-5.957 tagged_above=-999 required=5 tests=[AWL=0.642, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3X0wG-rlg23 for ; Mon, 4 Aug 2008 08:01:13 -0700 (PDT) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id 4391128C292 for ; Mon, 4 Aug 2008 08:01:13 -0700 (PDT) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 44A4E3281C1; Mon, 4 Aug 2008 10:01:40 -0500 (CDT) Received: from ndjsxgw03.ndc.nasa.gov (ndjsxgw03.ndc.nasa.gov [129.166.32.111]) by ndjsppt02.ndc.nasa.gov (8.14.1/8.14.1) with ESMTP id m74F1dii029303; Mon, 4 Aug 2008 10:01:40 -0500 Received: from NDJSEVS25A.ndc.nasa.gov ([129.166.32.124]) by ndjsxgw03.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Aug 2008 10:01:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 4 Aug 2008 10:01:39 -0500 Message-ID: In-Reply-To: <48971214.6070303@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] TCP-AO review comments. Thread-Index: Acj2PqYX3qAxxnP3SYyfpmXsiUz4SAAAvSvQ References: <0C53DCFB700D144284A584F54711EC58058C2FD4@xmb-sjc-21c.amer.cisco.com><48939933.3030601@isi.edu><0C53DCFB700D144284A584F54711EC5805923E25@xmb-sjc-21c.amer.cisco.com> <48971214.6070303@isi.edu> From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" To: "Joe Touch" X-OriginalArrivalTime: 04 Aug 2008 15:01:40.0094 (UTC) FILETIME=[FFDBF9E0:01C8F642] Cc: tcpm@ietf.org Subject: Re: [tcpm] TCP-AO review comments. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org >-----Original Message----- >From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On >Behalf Of Joe Touch >Sent: Monday, August 04, 2008 10:29 AM > >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Hi, Ananth, > >Just a few remaining points to clarify... > >Anantha Ramaiah (ananth) wrote: >|> | #1 >|> | I have problem with the term "obsoletes 2385" [ I did >|> bring this up >|> | before] It is going to be a long time before deployments >|> move over to >|> | the new TCP auth option. >|> >|> Practically, "obsoletes" doesn't obsolete anything. It does >|> indicate that the IETF wants a protocol to be replaced by >|> something else. That doesn't mean the older one can't be used >|> for legacy support, e.g., AFAICT - and that clearly should >|> apply here. If the IESG thinks that this is consistent with >|> "Obsoltes", would that be OK? >| >| Sure, ok let me rephrase the question here : "TCP MD5 option would >| continue to exist and should be supported for quite sometime" Does >| "obselete" allow this fact? > >My impression is that it does, i.e., it recommends replacement, but >doesn't prevent it being used for legacy purposes. > >< I would have preferred "Updates/Revises" >| which gives some leeway for co-existence to support legacy. > >We're not changing anything in TCP MD5, so we neither update >nor revise it. > >It seems like those of us replying are in agreement on this overall >point, but don't quite know what the best language to use is (if others >want to debate that point, though, please do). It might be >useful to ask >the IESG for advice (which I will do). I think that "obsoletes" is correct. There are problems with 2385, and AO is the solution that we're creating to replace it. We *do* want to discourage 2385 use when AO is ready, so obsoleting seems like the right thing to do. Of course someone could still use 2385; the status of a document has no power over what's in an implementation or enabled in a deployment, we just don't want to encourage it. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Aug 4 09:44:20 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 175F53A6CF2; Mon, 4 Aug 2008 09:44:20 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33F2B3A6CF2 for ; Mon, 4 Aug 2008 09:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1-kMLdcEPUh for ; Mon, 4 Aug 2008 09:44:18 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by core3.amsl.com (Postfix) with ESMTP id 6813F3A6AB8 for ; Mon, 4 Aug 2008 09:44:18 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so1803751rvf.49 for ; Mon, 04 Aug 2008 09:44:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=Xc8uRwMs30Aetd9JUNe6lCmYH9gLDxOJxPZILEYLGkM=; b=o6blW7TAN9JOLELGuAneH0uGFpB2ACA0r+Ty/dkyQdlB32TDzfV9MxtqVQD6EM5EY2 8fPdCqjZBvlMcnEM5FmoLeqQhXZk4qZ7rabci5+AigQkk/lCcw2rW0o11cXNVU09/P/y /KLA4pbqFsNdkv/GY6IXwidP/eGmVPseETK5Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=abtdb5LycHxpmiOJ2zvoaI12Xn1qsAGTDtDzdaJNve6lWR/FepaRC7twzsoPTBs/Yd hqpnFKu1BEZJt0AlYxk5r30tbn7FgnXLvSb5t+C74EnG24E/Evo2fT1wNRxrpN8O2h1O 1+wri3FmLPYWAIul4yLwW+EdI824OtZp9Ftxo= Received: by 10.141.203.7 with SMTP id f7mr7643724rvq.7.1217868273106; Mon, 04 Aug 2008 09:44:33 -0700 (PDT) Received: by 10.141.37.3 with HTTP; Mon, 4 Aug 2008 09:44:32 -0700 (PDT) Message-ID: <396556a20808040944q1dcaa286h143fba4c31e788d8@mail.gmail.com> Date: Mon, 4 Aug 2008 09:44:32 -0700 From: "Adam Langley" To: "Joe Touch" In-Reply-To: <48971214.6070303@isi.edu> MIME-Version: 1.0 Content-Disposition: inline References: <0C53DCFB700D144284A584F54711EC58058C2FD4@xmb-sjc-21c.amer.cisco.com> <48939933.3030601@isi.edu> <0C53DCFB700D144284A584F54711EC5805923E25@xmb-sjc-21c.amer.cisco.com> <48971214.6070303@isi.edu> X-Google-Sender-Auth: 22c4d9051c1e90e5 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] TCP-AO review comments. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Mon, Aug 4, 2008 at 7:28 AM, Joe Touch wrote: > | Repacketization combines multiple segments into one, thereby dictating a > | new ipid for example, so such things aren't considered messy, the > | question becomes how much flexibility you want to provide here... > > It would be difficult to support repacketization and ensure > authentication, AFAICT. How do others feel? At the moment, TCP MD5 requires disabling LRO and TSO (both software and hardware). There's no reason that hardware couldn't support AO aware repacketisation in the future, but at the moment, it's incompatible. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Aug 4 10:24:41 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E43033A6A9D; Mon, 4 Aug 2008 10:24:41 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53CA03A6783 for ; Mon, 4 Aug 2008 10:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.298 X-Spam-Level: X-Spam-Status: No, score=0.298 tagged_above=-999 required=5 tests=[AWL=-1.713, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_STOCK2=3.988] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TECSxEnZ8ps for ; Mon, 4 Aug 2008 10:24:38 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by core3.amsl.com (Postfix) with ESMTP id C69913A69C8 for ; Mon, 4 Aug 2008 10:24:33 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so1818736rvf.49 for ; Mon, 04 Aug 2008 10:25:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=Jyjti3e1Omw3g0Lj2QJs68if2HpcXGHlFRflt1NSue8=; b=OKKQEa6zLE6SGyhhgJaILV/6Zko4q/KnNijoS113bECi1kGIcSosPtJ0hXeq+ajDZh DFDDLjytgDZzj1rU0derVQNzHH3qaSQnH54aOgZyeUNMWTDQPaRnfG86LSxI6iUdjEjE 7L3XN0xS/YORC0rsHQB/KWQEyK1Nv0P08u36w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=pbYPfFOTnOaVQKIU7sl1T9nHHIR0mHIrhp2Y4toITTiZNtg2S4C95OXLJM8C3wFiu6 e3/3wh43SdWgMEU7cAQr6BmOTJSaiKI2nTPYwGDvmPZ9OwrVG3XhBqVs1hr5oYi07rZQ FLfRaEfXmMrFZSDVaP7N7l0XPaPORZHDstHBk= Received: by 10.140.208.17 with SMTP id f17mr7655698rvg.218.1217870701862; Mon, 04 Aug 2008 10:25:01 -0700 (PDT) Received: by 10.141.37.3 with HTTP; Mon, 4 Aug 2008 10:25:01 -0700 (PDT) Message-ID: <396556a20808041025r42e640famf8ae9e07e5d3bca@mail.gmail.com> Date: Mon, 4 Aug 2008 10:25:01 -0700 From: "Adam Langley" To: "Joe Touch" In-Reply-To: <48961F94.2040507@isi.edu> MIME-Version: 1.0 Content-Disposition: inline References: <396556a20807311252j67b1ab26mf6511dbdae780fdd@mail.gmail.com> <48924496.9060907@isi.edu> <396556a20807311640w2b17d447ud0c51241dc84f682@mail.gmail.com> <48935337.5060205@isi.edu> <396556a20808021200u75c3bdd5h77c328a9b61f8d78@mail.gmail.com> <4895B1F0.3070102@isi.edu> <396556a20808031106q18f6145cu7f6911ad8277d60c@mail.gmail.com> <48961F94.2040507@isi.edu> X-Google-Sender-Auth: 7373602a2693ef61 Cc: tcpm@ietf.org Subject: Re: [tcpm] Faster application handshakes with SYN/ACK payloads X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Sun, Aug 3, 2008 at 2:13 PM, Joe Touch wrote: > | However, without SYNACK payloads, this banner would cost another round > | trip. > > I have noted this before; an extra RTT doesn't do much of anything. > There are more delays in HTTP over TCP that incur round trips, e.g., > dealing with interactions with sending an ACK every other segment, as > well as apps that fail to disable Nagle optimizations (as they should > when they're interactive and have messages longer than a single byte). A extra round trip is very important. See the two quotes that I highlighted above for some evidence. At Google we work to shave off every millisecond and anything which required a whole extra round trip would, rightly, be dismissed immediately. I wouldn't even bother proposing such a scheme. > | With SYNACK payloads, we can add this very useful banner without add a > | round trip. However, servers can't just start including the banner > | whenever the server's kernel supports the SYNACK payload setsockopt > | because it would break all the existing clients who wouldn't know what > | to make of it. > > This is where you've lost me. Server TCPs can send data in the SYNACK. > Clients that ACK just the SYN cause the server to retransmit; clients > that ACK the whole segment work as you intend. > > What part if this isn't sufficient? Taking HTTP as an example, the very first bytes from the server must be the reply to the first request from the client. If servers started sending something else before hand, no matter what packet it's carried in, all existing HTTP clients would break. I'm suggesting that, if the ability to get a short banner from the server to the client in the SYNACK had been generally available when HTTP was created, the authors would have used it and the application-level protocol would have been different. The fact that it otherwise requires an extra round trip was strong reason for the client to start the exchange. However, since it wasn't availible, in order for some protocols (inc HTTP) to take advantage of such a capability we need an option to signal to both ends that they can use a slightly different application level protocol. At the server side, to add the extra banner, and at the client side to expect it. > | This would be a major change to the sockets API. > > I agree, but isn't that where this is going? If not, how do you expect > it to be used? I expect it to be a setsockopt at both the client and server ends. > This code is confusing; is it a library that happens to be in the > kernel, or is it intended to be code inside TCP? > > If this is intended inside TCP, you're having TCP insert data into the > user stream. That changes TCP semantics. > > Can you explain which of the above applies, or some other interpretation > that explains the code without such inconsistencies? Imaging that we change the sockets interface such that applications get a callback when a SYN frame is received on a listening socket. Applications could inspect the SYN frame and choose to enqueue data to be written. Hopefully the kernel would send some of that data in the SYNACK, but that's unimportant here. There are stacks which could do that[1]. However, for most stacks that would be painfully incongruent and the additional load would make SYN floods a real problem. So, as an implementation detail, we might have that function in the kernel. Since few kernels are happy with userspace machine code running in kernelspace, I expect that most implementations will choose to allow the application to configure a fixed function. The code was pseudocode for what that fixed function might look like. Applications would be able to configure the inputs: payload, payload_length, include_random_nonce and only_send_if_requested in that example. It might be the case that all such details, being implementation specific, shouldn't be included in the spec. I didn't want to spec to be too abstract, however. [1] http://tservice.net.ru/~s0mbre/old/?section=projects&item=unetstack > | In correctness terms, you are correct. It doesn't matter when the > | banner gets sent, or if it gets split over several packets. However, > | applications would very much like to know how many bytes the kernel > | will agree to transmit in reply to a SYN frame because, if a banner > | would cost an extra round trip they might prefer not to include it. > > ***WHY???*** > > I know I'm repeating myself here, but ***TCP IS NOT A REALTIME > PROTOCOL***, and there is *no correlation between user writes and > segment boundaries*. "realtime" to me means that there are known latency bounds. My this definition, TCP isn't a realtime protocol. However, average latency still matters very much. > Did you actually try reducing the overal latency of a single TCP > connection by 1 RTT and see if it actually matters? If these apps are > using persistent connections, then the first RTT exchange is all they'll > see anyway. Yes. These are internal numbers, sadly, but a RTT really does matter. For well connected users, an RTT might be only 20ms to multi-homed service. That, I'll agree, is fairly inconsequential. But San Francisco <-> London is about 150ms and if you're in less well connected continents (like Africa), RTTs are hundreds of milliseconds to anywhere. An RTT really matters. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Aug 4 10:36:12 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C40ED3A6A39; Mon, 4 Aug 2008 10:36:12 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C6663A691F for ; Mon, 4 Aug 2008 10:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.424 X-Spam-Level: X-Spam-Status: No, score=-6.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VN8RlLU+00wQ for ; Mon, 4 Aug 2008 10:36:10 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id C8A793A68E4 for ; Mon, 4 Aug 2008 10:36:07 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP; Mon, 04 Aug 2008 10:35:47 PDT Received: from antipi.jnpr.net ([10.10.2.34]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Aug 2008 10:36:09 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by antipi.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Aug 2008 13:36:07 -0400 Received: from [172.28.13.57] ([172.28.13.57] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Aug 2008 13:36:07 -0400 Message-ID: <48973E04.6070400@juniper.net> Date: Mon, 04 Aug 2008 13:36:04 -0400 From: Ron Bonica User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Adam Langley References: <4890EFB0.5020301@isi.edu> <396556a20807301557q608ff91er95e46fa8e6167f6c@mail.gmail.com> In-Reply-To: <396556a20807301557q608ff91er95e46fa8e6167f6c@mail.gmail.com> X-Enigmail-Version: 0.95.6 X-OriginalArrivalTime: 04 Aug 2008 17:36:07.0402 (UTC) FILETIME=[939AF4A0:01C8F658] Cc: tcpm@ietf.org, Joe Touch Subject: Re: [tcpm] tcp-auth-opt issue: header format and alignment X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Mine, too! Adam Langley wrote: > On Wed, Jul 30, 2008 at 3:48 PM, Joe Touch wrote: >> The consensus appears to be emerging that we retain a simple, >> deterministic header format, and leave alignment issues to implementations: > > I thought that KeyID was a clearer name, but either way is fine. > Putting it at the front like this definitely has my vote. > > > AGL > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Aug 4 10:38:57 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B1F33A6CF3; Mon, 4 Aug 2008 10:38:57 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD14C3A6CF3 for ; Mon, 4 Aug 2008 10:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5Y9AvsFEBDe for ; Mon, 4 Aug 2008 10:38:55 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 285F13A6A39 for ; Mon, 4 Aug 2008 10:38:53 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Mon, 04 Aug 2008 10:39:05 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Aug 2008 10:38:53 -0700 Received: from emailwf1.jnpr.net ([10.10.2.33]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Aug 2008 10:38:52 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by emailwf1.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Aug 2008 13:38:51 -0400 Received: from [172.28.13.57] ([172.28.13.57] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Aug 2008 13:38:51 -0400 Message-ID: <48973EA8.3090307@juniper.net> Date: Mon, 04 Aug 2008 13:38:48 -0400 From: Ron Bonica User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Joe Touch References: <4890F1FE.6060900@isi.edu> In-Reply-To: <4890F1FE.6060900@isi.edu> X-Enigmail-Version: 0.95.6 X-OriginalArrivalTime: 04 Aug 2008 17:38:51.0481 (UTC) FILETIME=[F5676C90:01C8F658] Cc: tcpm@ietf.org Subject: Re: [tcpm] tcp-auth-opt issue: reserved keyID value X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Folks, I am against reserving the value 0. If we don't reserve 0, we only need one bit for the TSPI. Otherwise, we need two bits. Ron Joe Touch wrote: > Ran suggested that some implementations would benefit from reserving a > keyID as invalid (e.g., keyID 0): > > This assists the efficiency of some implementations. > > This also adds an additional requirement (e.g., keyID 0 MUST not be > used) which must be validated during conformance testing. > > Comments on additional pros and cons would be useful. Examples of how > this might impact implementation efficiency would be particularly useful > (esp. if not encumbered) > > _______________________________________________ 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 From tcpm-bounces@ietf.org Mon Aug 4 10:41:29 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 649713A6D1A; Mon, 4 Aug 2008 10:41:29 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDE373A6D1A for ; Mon, 4 Aug 2008 10:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.468 X-Spam-Level: X-Spam-Status: No, score=-6.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELRPmYhWmW2Y for ; Mon, 4 Aug 2008 10:41:27 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7ob114.obsmtp.com [64.18.2.214]) by core3.amsl.com (Postfix) with ESMTP id F01333A6914 for ; Mon, 4 Aug 2008 10:41:24 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP; Mon, 04 Aug 2008 10:41:53 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Aug 2008 10:41:51 -0700 Received: from pi-smtp.jnpr.net ([10.10.2.36]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Aug 2008 10:41:51 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 4 Aug 2008 13:41:50 -0400 Received: from [172.28.13.57] ([172.28.13.57] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Aug 2008 13:41:50 -0400 Message-ID: <48973F5B.8030108@juniper.net> Date: Mon, 04 Aug 2008 13:41:47 -0400 From: Ron Bonica User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Joe Touch References: <4890F270.8000902@isi.edu> In-Reply-To: <4890F270.8000902@isi.edu> X-Enigmail-Version: 0.95.6 X-OriginalArrivalTime: 04 Aug 2008 17:41:50.0435 (UTC) FILETIME=[6011A330:01C8F659] Cc: tcpm@ietf.org Subject: Re: [tcpm] tcp-auth-opt issue: keyID randomness X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Joe, I don't think that the TSPI/keyID should be selected at random. The range of values is so small that guessing the value is trivial. Ron Joe Touch wrote: > As per Ran's request, should the keyID be selected at random to enable > early discard algorithms, e.g., to reduce the impact of an attacker who > would need to guess a valid keyID value? > > I discussed this issue with Ran, and suggested that all crypto > properties should be contained in the MAC field; such a field > might include a 'hard to guess' arbitrary fixed part and a > computed (e.g., HMAC) part, to enable efficient 'triage' > of randomly-generated DOS packets. > > Overall, this suggests that the document could note that the keyID is > NOT intended for protection, and any valid values may be used at any time. > > Comments (esp. from Ran, who raised the issue)? > > > _______________________________________________ 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 From tcpm-bounces@ietf.org Mon Aug 4 10:52:07 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7731C3A691F; Mon, 4 Aug 2008 10:52:07 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 449733A67A1 for ; Mon, 4 Aug 2008 10:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wB8HkDdjGobF for ; Mon, 4 Aug 2008 10:52:05 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by core3.amsl.com (Postfix) with ESMTP id 3D0E63A6783 for ; Mon, 4 Aug 2008 10:52:05 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so1828800rvf.49 for ; Mon, 04 Aug 2008 10:52:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=mhd55LYdPEfOqV1jmPKHoeZGYWfgKNbCCtBM4M/1uE8=; b=AQkxPoqSENOVaPIw0+672DZ+wnXnUsdcDdYWZEnrXySksbreR/azoCyBcsHGF1PEF0 IAmN9VUGcIo9eoi3na2iggcYuOn4IsG8pS3Gw/OM0hOJv/aQxZoJI5teVEExFWTU3K23 MEYOyeD9YlFZLyjT437WjA5GG1o9k6xPMpc+Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=f7vFXvNZOGusSis6y9iaW1Bk5Ri7EG0JiOsIWjAdOZHoPqmkcUWN3w6xOgdd9esabe smOYsCAZqVG+zV2fZeX0sUvcUqGtaQExYOECy4UpLK8Uk9ldrN/2EebxapzaS4jEWzv6 /I6LFk6tzoXDpys5zfEQ8eEoNx/OvphT5KzGA= Received: by 10.141.115.6 with SMTP id s6mr7670880rvm.239.1217872354023; Mon, 04 Aug 2008 10:52:34 -0700 (PDT) Received: by 10.141.37.3 with HTTP; Mon, 4 Aug 2008 10:52:33 -0700 (PDT) Message-ID: <396556a20808041052n1758a472kcbe5b7e851a54c5a@mail.gmail.com> Date: Mon, 4 Aug 2008 10:52:33 -0700 From: "Adam Langley" To: "Anantha Ramaiah (ananth)" In-Reply-To: <0C53DCFB700D144284A584F54711EC5805923E2D@xmb-sjc-21c.amer.cisco.com> MIME-Version: 1.0 Content-Disposition: inline References: <396556a20807311252j67b1ab26mf6511dbdae780fdd@mail.gmail.com> <0C53DCFB700D144284A584F54711EC5805923E2D@xmb-sjc-21c.amer.cisco.com> X-Google-Sender-Auth: dac1ca8d42a7af8b Cc: tcpm@ietf.org Subject: Re: [tcpm] Faster application handshakes with SYN/ACK payloads X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Sun, Aug 3, 2008 at 9:56 PM, Anantha Ramaiah (ananth) wrote: > - fix the sentence : "we should how this has...." Thanks! will do. > - you mention "cryptographic applications" would benefit with this > proposal, and give example of SSH in your draft. It would be really > interesting to know how many very commonly used TCP applications would > really benefit with this ? Atleast the draft can mention those.. Will do with the next draft. > - with the SSH example which you give, it appears that one of the > advantages of this proposal is that you can tear down the connection > before the connection moves to ESTAB if the authentication fails? (For > eg:- some implementations don't create a full blown TCB before TWHS > completes) Indeed. Although I believe that a (short lived) TCB would actually be created in this case for current, common stacks, that's an implementation limit. It would be possible, with the authentication that I sketched, for neither end to create a TCB if the server's public value didn't match. > - Can you elaborate on the flags option? It simply mentions that the > meaning of this would be assigned by IANA? Again this is not infinite > (2+n, n is finite) since it should be bounded by the TCP header length > inclusive of options? The flags option was designed to allow future flag options to be assigned bits, rather than option numbers. Consider that, if SACK permitted has been designed this way, then this proposed option wouldn't need any extra options space, it could just take a bit in an option that it already ubiquitous. However, it might well be the case that I should just stick to a standard, 2 byte, option for this. > - the doc says (section 3 ) "host MUST not include data payload in > SYN+ACK resulting from a SYN frame without SYNACK payload permitted" > But RFC 793 does permit data in SYN which includes SYN+ACK, so this > statement raises a new level of ambiguity. Thanks. Joe pointed out this ambiguity also. It will be fixed in the next draft by echoing the option in the SYNACK. > Section 4: > > You mention 64 bytes of payload is enough to include sufficient crypto > material. Just wondering the interoperability of this statement with TCP > auth (TCP MD5 and TCP AO for example) The method for upgrading a normal connection to TCP AO is currently not specified, although there has been discussion of it. In my current, very rough, patches there's an option that I'm calling LATCH that allows a connection to upgrade to TCP AO. Also, I have userspace software that uses SYNACK payloads and LATCH to establish a connection and upgrade to TCP AO using the agreed key (and no additional round trips). Fundamentally, however, these drafts are independent. > What about Kamikaze like packets ? where SYN, FIN are set the > applications can send data and also set the FIN bit in the oriinal SYN > (Not sure if 793 talks about it but Stevens book does mention it and so > as BSD implementatiosns which support this type of packets) Would those > still work within your proposal? I would have to investigate how the BSD stacks handle this. Linux would ack only the SYN flag, to the other host would have to retransmit any data and the FIN anyway. BSD stacks, I hope, would not deliver data to userspace with an unauthenticated source IP address, so may do the same. But it isn't incompatible with my scheme. The SYNACK payload, if configured, would be sent as part of the data stream. > Also, the applications need to change to make use of this proposal (the > HTTP example which you mention below) In other words, it would be nice > if you can explain the "opportunistic encryption" scheme and how > applications (which all) can benefit from your proposal in more detail > in the draft. Since several people have suggested this, I certain shall in the next draft (which should be in the next couple of days) Thanks for your comments. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Aug 4 11:21:37 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EB3F28C1A8; Mon, 4 Aug 2008 11:21:37 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3FED3A6923 for ; Mon, 4 Aug 2008 11:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.265 X-Spam-Level: X-Spam-Status: No, score=-0.265 tagged_above=-999 required=5 tests=[AWL=-2.334, BAYES_00=-2.599, FRT_STOCK2=3.988, SARE_ADLTOBFU=0.68] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2o8QdSjHJdn for ; Mon, 4 Aug 2008 11:21:34 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id BA8BE3A691F for ; Mon, 4 Aug 2008 11:21:34 -0700 (PDT) Received: from [12.196.53.164] ([12.196.53.164]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m74ILHZX012203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 4 Aug 2008 11:21:20 -0700 (PDT) Message-ID: <48974877.6050202@isi.edu> Date: Mon, 04 Aug 2008 11:20:39 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Adam Langley References: <396556a20807311252j67b1ab26mf6511dbdae780fdd@mail.gmail.com> <48924496.9060907@isi.edu> <396556a20807311640w2b17d447ud0c51241dc84f682@mail.gmail.com> <48935337.5060205@isi.edu> <396556a20808021200u75c3bdd5h77c328a9b61f8d78@mail.gmail.com> <4895B1F0.3070102@isi.edu> <396556a20808031106q18f6145cu7f6911ad8277d60c@mail.gmail.com> <48961F94.2040507@isi.edu> <396556a20808041025r42e640famf8ae9e07e5d3bca@mail.gmail.com> In-Reply-To: <396556a20808041025r42e640famf8ae9e07e5d3bca@mail.gmail.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Faster application handshakes with SYN/ACK payloads X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Adam. Adam Langley wrote: | On Sun, Aug 3, 2008 at 2:13 PM, Joe Touch wrote: |> | However, without SYNACK payloads, this banner would cost another round |> | trip. |> |> I have noted this before; an extra RTT doesn't do much of anything. |> There are more delays in HTTP over TCP that incur round trips, e.g., |> dealing with interactions with sending an ACK every other segment, as |> well as apps that fail to disable Nagle optimizations (as they should |> when they're interactive and have messages longer than a single byte). | | A extra round trip is very important. See the two quotes that I | highlighted above for some evidence. At Google we work to shave off | every millisecond and anything which required a whole extra round trip | would, rightly, be dismissed immediately. IMO, you are confusing TCP with RTP if that's the case. I appreciate the idea of optimizing TCP, but there are so many other places where RTTs are not under your control, and so many RTTs in a connection, that removing (or adding) a single one anywhere seems in the noise. Let's agree to disagree on that point, and let others weigh in. Moving on... |> | With SYNACK payloads, we can add this very useful banner without add a |> | round trip. However, servers can't just start including the banner |> | whenever the server's kernel supports the SYNACK payload setsockopt |> | because it would break all the existing clients who wouldn't know what |> | to make of it. |> |> This is where you've lost me. Server TCPs can send data in the SYNACK. |> Clients that ACK just the SYN cause the server to retransmit; clients |> that ACK the whole segment work as you intend. |> |> What part if this isn't sufficient? | | Taking HTTP as an example, the very first bytes from the server must | be the reply to the first request from the client. If servers started | sending something else before hand, no matter what packet it's carried | in, all existing HTTP clients would break. | | I'm suggesting that, if the ability to get a short banner from the | server to the client in the SYNACK had been generally available when | HTTP was created, the authors would have used it and the | application-level protocol would have been different. The fact that it | otherwise requires an extra round trip was strong reason for the | client to start the exchange. | | However, since it wasn't availible, in order for some protocols (inc | HTTP) to take advantage of such a capability we need an option to | signal to both ends that they can use a slightly different application | level protocol. At the server side, to add the extra banner, and at | the client side to expect it. That seems like - as you note - an application layer protocol issue. It doesn't seem to have anything to do with TCP. ... |> This code is confusing; is it a library that happens to be in the |> kernel, or is it intended to be code inside TCP? |> |> If this is intended inside TCP, you're having TCP insert data into the |> user stream. That changes TCP semantics. |> |> Can you explain which of the above applies, or some other interpretation |> that explains the code without such inconsistencies? | | Imaging that we change the sockets interface such that applications | get a callback when a SYN frame is received on a listening socket. | Applications could inspect the SYN frame and choose to enqueue data to | be written. Hopefully the kernel would send some of that data in the | SYNACK, but that's unimportant here. Why wouldn't the application just enqueue the data? Why does it need to know that the other end supports this? ... |> Did you actually try reducing the overal latency of a single TCP |> connection by 1 RTT and see if it actually matters? If these apps are |> using persistent connections, then the first RTT exchange is all they'll |> see anyway. | | Yes. These are internal numbers, sadly, but a RTT really does matter. | For well connected users, an RTT might be only 20ms to multi-homed | service. That, I'll agree, is fairly inconsequential. But San | Francisco <-> London is about 150ms and if you're in less well | connected continents (like Africa), RTTs are hundreds of milliseconds | to anywhere. An RTT really matters. 150ms is large when considered in the context of a small number of RTTs, but in the context of a connection that lasts 10 RTTs, it's 10%; the impact drops as you keep the connection going. I.e., a reduction of a single RTT is important only when the total exchange lasts 2-3 RTTs. That's 8KB-16KB of data - and it matters only for the first chunk of data in a persistent connection. For web pages with dozens of embedded components (in specific, more than 4, which is the typical limit for simultaneous connections), again this seems very much in the noise... Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiXSHYACgkQE5f5cImnZrvqIQCgt2ge9+11Nv/P4cFZIA/RXeku R0MAnR14wOyBQgKnQsdwF9LnRD8ZIT2K =TAt5 -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Aug 4 11:45:36 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8333E3A691E; Mon, 4 Aug 2008 11:45:36 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DD593A68E8 for ; Mon, 4 Aug 2008 11:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAJCVm1iG6AH for ; Mon, 4 Aug 2008 11:45:33 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id DC0623A6BAA for ; Mon, 4 Aug 2008 11:45:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,306,1215388800"; d="scan'208";a="61299003" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 04 Aug 2008 18:45:58 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m74IjwNk031353; Mon, 4 Aug 2008 11:45:58 -0700 Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m74IjwP5013642; Mon, 4 Aug 2008 18:45:58 GMT Received: (from achandra@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA07075; Mon, 4 Aug 2008 11:45:52 -0700 (PDT) Date: Mon, 4 Aug 2008 11:45:52 -0700 From: Chandrashekhar Appanna To: "Eddy, Wesley M. (GRC-RCN0)[VZ]" Message-ID: <20080804184552.GG29466@cisco.com> References: <48971214.6070303@isi.edu> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3140; t=1217875558; x=1218739558; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=achandra@cisco.com; z=From:=20Chandrashekhar=20Appanna=20 |Subject:=20Re=3A=20[tcpm]=20TCP-AO=20review=20comments. |Sender:=20; bh=O5lVdojCla5DfR0GXZJ+82nUjs/s3FxcI13UiUO6J7g=; b=Ww8N0LjHD75TCtQPiz2Q7kk7EfSVbvVzwFVyb96U1q+8HSw7QMJGITv3Ll FHXnsam2h4yJrwJP9M+Q2mh0lxj75cfe7JHrOau4nprfjcdy2Ph7SOU80oP5 /zCHzVTBb2etP3vL591FLgheGpcTLGCTzcLPSvX8786xDktmVDZVw=; Authentication-Results: sj-dkim-1; header.From=achandra@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: tcpm@ietf.org, Joe Touch Subject: Re: [tcpm] TCP-AO review comments. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Mon, Aug 04, 2008 at 10:01:39AM -0500, Eddy, Wesley M. (GRC-RCN0)[VZ] wrote: > >-----Original Message----- > >From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > >Behalf Of Joe Touch > >Sent: Monday, August 04, 2008 10:29 AM > > > >-----BEGIN PGP SIGNED MESSAGE----- > >Hash: SHA1 > > > >Hi, Ananth, > > > >Just a few remaining points to clarify... > > > >Anantha Ramaiah (ananth) wrote: > >|> | #1 > >|> | I have problem with the term "obsoletes 2385" [ I did > >|> bring this up > >|> | before] It is going to be a long time before deployments > >|> move over to > >|> | the new TCP auth option. > >|> > >|> Practically, "obsoletes" doesn't obsolete anything. It does > >|> indicate that the IETF wants a protocol to be replaced by > >|> something else. That doesn't mean the older one can't be used > >|> for legacy support, e.g., AFAICT - and that clearly should > >|> apply here. If the IESG thinks that this is consistent with > >|> "Obsoltes", would that be OK? > >| > >| Sure, ok let me rephrase the question here : "TCP MD5 option would > >| continue to exist and should be supported for quite sometime" Does > >| "obselete" allow this fact? > > > >My impression is that it does, i.e., it recommends replacement, but > >doesn't prevent it being used for legacy purposes. > > > >< I would have preferred "Updates/Revises" > >| which gives some leeway for co-existence to support legacy. > > > >We're not changing anything in TCP MD5, so we neither update > >nor revise it. > > > >It seems like those of us replying are in agreement on this overall > >point, but don't quite know what the best language to use is (if others > >want to debate that point, though, please do). It might be > >useful to ask > >the IESG for advice (which I will do). > > > > I think that "obsoletes" is correct. There are problems with 2385, and > AO is the solution that we're creating to replace it. We *do* want to > discourage 2385 use when AO is ready, so obsoleting seems like the right > thing to do. Of course someone could still use 2385; the status of a > document has no power over what's in an implementation or enabled in a > deployment, we just don't want to encourage it. > Not sure if this will obselete that.. this is a new option with different goals and we are not even sure if at this point how much consensus there is about moving AO forward.. there is much discussion on the keying aspects, the design team seems to be just one person speaking up mostly; and given the comments from other design team members at the mike at the ietf I would not be in favour of making AO obselete the other method.. like you say the status of the document has no power and therefore it is better to not think it has some if it does not line up ;).. forcing a document through without the implied working code and rough consensus may end up doing more harm to the doc itself.. Rgds, Chandra. > _______________________________________________ > 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 From tcpm-bounces@ietf.org Tue Aug 5 11:27:27 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ABDA3A6856; Tue, 5 Aug 2008 11:27:27 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4607D28C30C for ; Tue, 5 Aug 2008 11:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.609 X-Spam-Level: X-Spam-Status: No, score=-1.609 tagged_above=-999 required=5 tests=[AWL=0.368, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsYKl9UcyADo for ; Tue, 5 Aug 2008 11:27:25 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by core3.amsl.com (Postfix) with ESMTP id 50C5E3A6774 for ; Tue, 5 Aug 2008 11:27:25 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so2290397rvf.49 for ; Tue, 05 Aug 2008 11:27:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=0l8tCgTNp1ysr6qLhIoqsm4mOjBOILixHpVrFNe+rNM=; b=K5DegxsYl6/V4UvKXnnssumJptEiBzToAsuCbVLEVC6TToJeGnMIT3JZnjJ80BToIj ol+UO87UT35lg1s+5vCg0NmPqHu9P0VbQ/04Y8nmKmN0QQLPLa7Y0+fmCsL0GwAJr0NO QOOpcVamUGlc06nA1gLgkCJ5YM4YGxHWFAfb8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=EBfm9Jk7dJdodC/m5PxqBtFGT2XmHEkRyDUcswMvixeuMFdpkPoC5a13ieQhiqG+XZ TTYPxM1/C9lJ4MMtZprCEEcXSS/8yWGBH2DrU+jUJFW4pWGAgYeBl/eSuIlfhytJc11J dDqB32xzc7C3CpnRxeK4jgemsCi+wkoC4nJgw= Received: by 10.140.191.14 with SMTP id o14mr8382693rvf.130.1217960875972; Tue, 05 Aug 2008 11:27:55 -0700 (PDT) Received: by 10.141.37.3 with HTTP; Tue, 5 Aug 2008 11:27:55 -0700 (PDT) Message-ID: <396556a20808051127m4c03dd9cr4bfa0209fdb059b2@mail.gmail.com> Date: Tue, 5 Aug 2008 11:27:55 -0700 From: "Adam Langley" To: "Joe Touch" In-Reply-To: <48974877.6050202@isi.edu> MIME-Version: 1.0 Content-Disposition: inline References: <396556a20807311252j67b1ab26mf6511dbdae780fdd@mail.gmail.com> <48924496.9060907@isi.edu> <396556a20807311640w2b17d447ud0c51241dc84f682@mail.gmail.com> <48935337.5060205@isi.edu> <396556a20808021200u75c3bdd5h77c328a9b61f8d78@mail.gmail.com> <4895B1F0.3070102@isi.edu> <396556a20808031106q18f6145cu7f6911ad8277d60c@mail.gmail.com> <48961F94.2040507@isi.edu> <396556a20808041025r42e640famf8ae9e07e5d3bca@mail.gmail.com> <48974877.6050202@isi.edu> X-Google-Sender-Auth: d8032bae403148d3 Cc: tcpm@ietf.org Subject: Re: [tcpm] Faster application handshakes with SYN/ACK payloads X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Mon, Aug 4, 2008 at 11:20 AM, Joe Touch wrote: > | Imaging that we change the sockets interface such that applications > | get a callback when a SYN frame is received on a listening socket. > | Applications could inspect the SYN frame and choose to enqueue data to > | be written. Hopefully the kernel would send some of that data in the > | SYNACK, but that's unimportant here. > > Why wouldn't the application just enqueue the data? Why does it need to > know that the other end supports this? It doesn't always. SMTP, IRC and SSH protocols, for example, all include a banner from the server to the client. In this case, the data can be unconditionally enqueued for transmission. It's for protocols which don't already start with a server->client transmission, and for which we wish to add one, that the client must signal that we're changing the application level protocol for this connection. > 150ms is large when considered in the context of a small number of RTTs, > but in the context of a connection that lasts 10 RTTs, it's 10%; the > impact drops as you keep the connection going. > > I.e., a reduction of a single RTT is important only when the total > exchange lasts 2-3 RTTs. That's 8KB-16KB of data - and it matters only > for the first chunk of data in a persistent connection. For web pages > with dozens of embedded components (in specific, more than 4, which is > the typical limit for simultaneous connections), again this seems very > much in the noise... Many Google users are now using search bars to submit queries. Thus they type into a text field in the browser, hit enter and the browser makes a connection, sends the query encoded in a GET and displays the result. This is one example of a situation where the connection latency isn't amortised. There are many others, but obviously, this is the example that usually dominates my thinking. And, in this situation, it turns out that every 10ms makes a difference. I might be wrong here. This might be an overcomplex solution. But I think only time will tell, which is why I wish to have it published as an experimental spec. If, in a couple of years, it doesn't work the option number can be released, ready for the next guy. Cheers, AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Aug 5 16:47:29 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 066953A6B98; Tue, 5 Aug 2008 16:47:29 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 914953A6B93 for ; Tue, 5 Aug 2008 16:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.17 X-Spam-Level: X-Spam-Status: No, score=-1.17 tagged_above=-999 required=5 tests=[AWL=1.429, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSrSYmpaianw for ; Tue, 5 Aug 2008 16:47:26 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 79BD93A6A56 for ; Tue, 5 Aug 2008 16:47:26 -0700 (PDT) Received: from [192.168.2.121] (bolongo.jbtelenet.com [204.11.152.116]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m75NlOXp001608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 5 Aug 2008 16:47:28 -0700 (PDT) Message-ID: <4898E664.6030008@isi.edu> Date: Tue, 05 Aug 2008 16:46:44 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Adam Langley References: <396556a20807311252j67b1ab26mf6511dbdae780fdd@mail.gmail.com> <48924496.9060907@isi.edu> <396556a20807311640w2b17d447ud0c51241dc84f682@mail.gmail.com> <48935337.5060205@isi.edu> <396556a20808021200u75c3bdd5h77c328a9b61f8d78@mail.gmail.com> <4895B1F0.3070102@isi.edu> <396556a20808031106q18f6145cu7f6911ad8277d60c@mail.gmail.com> <48961F94.2040507@isi.edu> <396556a20808041025r42e640famf8ae9e07e5d3bca@mail.gmail.com> <48974877.6050202@isi.edu> <396556a20808051127m4c03dd9cr4bfa0209fdb059b2@mail.gmail.com> In-Reply-To: <396556a20808051127m4c03dd9cr4bfa0209fdb059b2@mail.gmail.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Faster application handshakes with SYN/ACK payloads X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Adam, Adam Langley wrote: | On Mon, Aug 4, 2008 at 11:20 AM, Joe Touch wrote: |> | Imaging that we change the sockets interface such that applications |> | get a callback when a SYN frame is received on a listening socket. |> | Applications could inspect the SYN frame and choose to enqueue data to |> | be written. Hopefully the kernel would send some of that data in the |> | SYNACK, but that's unimportant here. |> |> Why wouldn't the application just enqueue the data? Why does it need to |> know that the other end supports this? | | It doesn't always. SMTP, IRC and SSH protocols, for example, all | include a banner from the server to the client. In this case, the data | can be unconditionally enqueued for transmission. It's for protocols | which don't already start with a server->client transmission, and for | which we wish to add one, that the client must signal that we're | changing the application level protocol for this connection. Using a transport signal to change the application protocol seems very strange to me. Others can comment on that. My view is that this is a case where perhaps you want something that is better encoded by using a different port number (thus a different application service, explicitly) than a TCP option that implies that application behavior. |> 150ms is large when considered in the context of a small number of RTTs, |> but in the context of a connection that lasts 10 RTTs, it's 10%; the |> impact drops as you keep the connection going. |> |> I.e., a reduction of a single RTT is important only when the total |> exchange lasts 2-3 RTTs. That's 8KB-16KB of data - and it matters only |> for the first chunk of data in a persistent connection. For web pages |> with dozens of embedded components (in specific, more than 4, which is |> the typical limit for simultaneous connections), again this seems very |> much in the noise... | | Many Google users are now using search bars to submit queries. Thus | they type into a text field in the browser, hit enter and the browser | makes a connection, sends the query encoded in a GET and displays the | result. This is one example of a situation where the connection | latency isn't amortised. There are many others, but obviously, this is | the example that usually dominates my thinking. And, in this | situation, it turns out that every 10ms makes a difference. Understood and appreciated. Can you see if the port solution might work?? Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiY5mQACgkQE5f5cImnZrunEQCeJsum/G9ClwtD8cfX3zwrVZ8n EmAAoMlGT6BdWE3JfwTjTEcXVVjlJ9Qr =ctQh -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Aug 5 17:14:30 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A6BB3A6AA5; Tue, 5 Aug 2008 17:14:30 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 956403A6880 for ; Tue, 5 Aug 2008 17:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.627 X-Spam-Level: X-Spam-Status: No, score=-1.627 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRhNx+s6Cg30 for ; Tue, 5 Aug 2008 17:14:28 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by core3.amsl.com (Postfix) with ESMTP id A70333A6AA5 for ; Tue, 5 Aug 2008 17:14:28 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so2409848rvf.49 for ; Tue, 05 Aug 2008 17:15:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=1bFg9MxSuPP6+/E8jajXg5zdjJeze58fcPtHkDJ76YM=; b=ufoEEwj8B4sGWrZbT8r8ciI/Vs3+7AEtsxOOb1sLrVopWUDzpwVR8ZEpb/FdN+1pM5 RKuoqeCQWf2+O5BLhrlr1JFA/j0/JRgAAA3ZA6+QUqyiTwBFSY6xzLZacaAiiKCrC+tC afvD0jW232kZ/z4Ug0Rri35UspNrAnEKODan4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=XUpGMujgvvi6/pBKKblMQvK3pnDKOzTw5tAuoMo/gCwJN23GPwePphZf1PF6jJadTf 52zRV/oUC3Ksq74eomwSihEFvNQMT6dPKHqxfkDrDb3SgFl+bBQMcVYXnRcjrFz1fl25 KcnKxByEfb/Or8MsiclQYH9+nrpVQbrxbfJ6M= Received: by 10.140.125.1 with SMTP id x1mr8532600rvc.217.1217981697371; Tue, 05 Aug 2008 17:14:57 -0700 (PDT) Received: by 10.141.37.3 with HTTP; Tue, 5 Aug 2008 17:14:57 -0700 (PDT) Message-ID: <396556a20808051714n3baf3f9ag9e976f21f94a2cc@mail.gmail.com> Date: Tue, 5 Aug 2008 17:14:57 -0700 From: "Adam Langley" To: "Joe Touch" In-Reply-To: <4898E664.6030008@isi.edu> MIME-Version: 1.0 Content-Disposition: inline References: <396556a20807311252j67b1ab26mf6511dbdae780fdd@mail.gmail.com> <48935337.5060205@isi.edu> <396556a20808021200u75c3bdd5h77c328a9b61f8d78@mail.gmail.com> <4895B1F0.3070102@isi.edu> <396556a20808031106q18f6145cu7f6911ad8277d60c@mail.gmail.com> <48961F94.2040507@isi.edu> <396556a20808041025r42e640famf8ae9e07e5d3bca@mail.gmail.com> <48974877.6050202@isi.edu> <396556a20808051127m4c03dd9cr4bfa0209fdb059b2@mail.gmail.com> <4898E664.6030008@isi.edu> X-Google-Sender-Auth: a6d9a2459050c8fd Cc: tcpm@ietf.org Subject: Re: [tcpm] Faster application handshakes with SYN/ACK payloads X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Tue, Aug 5, 2008 at 4:46 PM, Joe Touch wrote: I've just posted a new version of the draft, incorporating your comments, which I hope is a lot clearer. Thanks for everything so far. > Using a transport signal to change the application protocol seems very > strange to me. Others can comment on that. My view is that this is a > case where perhaps you want something that is better encoded by using a > different port number (thus a different application service, explicitly) > than a TCP option that implies that application behavior. It is strange, I agree. My usual test about such things is if I get an "ick" reaction and, in this case, I don't. Although, that might just be me. Two reasonable questions arise: "Where will this stop?" - obviously, the TCP option space shouldn't be a repository for application data. In this case, at least, the option is advertising a certain minimum capability of the TCP stack, as defined in the draft. Also, I'll claim that this is the last such need in this area: The SYNACK payload sizes is a decision for the server (within the advertised window). No more client options could be needed to advertise support for larger ones. Since the SYNACK payload is (nearly) constant, and TCP stacks are not going to differ sufficiently to change this in the next 20 years, applications don't gain anything else by stuffing anything more in the SYN option space. So I don't think this sets an unreasonable precedent. "Is it really needed?" - If you consider examples one and three from the 01 draft that I just posted, I'm claiming that it would at least be very useful. Of course, alternative ports solve the problem but I believe that such a solution is messy enough as to be not a going concern. Much of the time, SYNs to a closed port on a public server will result in no reply at all, meaning that timeouts have to trigger the back off. The above is the sort of stuff that I should have put in the revised draft :) I probably shall include it in -02. Cheers AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Aug 5 17:15:47 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C14353A6D56; Tue, 5 Aug 2008 17:15:47 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C80E3A67A6 for ; Tue, 5 Aug 2008 17:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.643 X-Spam-Level: X-Spam-Status: No, score=-1.643 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLJCuTIECJBb for ; Tue, 5 Aug 2008 17:15:45 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by core3.amsl.com (Postfix) with ESMTP id 464663A6D56 for ; Tue, 5 Aug 2008 17:15:44 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so2410290rvf.49 for ; Tue, 05 Aug 2008 17:16:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=UoYq1QLNA1bEBp/FKDbKK0LR4WYB/Igig3PiHzHvPak=; b=k0Em4kSTNukS7vdHJrIh/MmNIvW2rjJofELBwJfZyKLc21Q8bnLNc49nRueKxLR1Ya uskcLSxpq+dv+QcisH7xM9Y/RnFqrxmrxMCaQTpRBu+b1CEuLnVejmluJyRRIdiskiKC z6mQD49Lf+FIzPcZCNmELAR8uBCea+NZcRaVk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=SlIlMjLfRbqSzO9K9VrJrnzbh2ATVtpLZ6W1vh0aMAF6nKAd5K6O/38JVzsStw6l7k 9qG2poTnPR1XFji5cFTUGbSpkly/EvyKdRZf11LENbzJp8Z+vqN7XGukcf9l8ge6XQUt J3/jR1d9/0aGswm4kCejMNgPVCyWa7FEulbA0= Received: by 10.141.36.10 with SMTP id o10mr8542807rvj.176.1217981776109; Tue, 05 Aug 2008 17:16:16 -0700 (PDT) Received: by 10.141.37.3 with HTTP; Tue, 5 Aug 2008 17:16:16 -0700 (PDT) Message-ID: <396556a20808051716j4ee75fbepe16b17581fc96a59@mail.gmail.com> Date: Tue, 5 Aug 2008 17:16:16 -0700 From: "Adam Langley" To: "Joe Touch" In-Reply-To: <396556a20808051714n3baf3f9ag9e976f21f94a2cc@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <396556a20807311252j67b1ab26mf6511dbdae780fdd@mail.gmail.com> <396556a20808021200u75c3bdd5h77c328a9b61f8d78@mail.gmail.com> <4895B1F0.3070102@isi.edu> <396556a20808031106q18f6145cu7f6911ad8277d60c@mail.gmail.com> <48961F94.2040507@isi.edu> <396556a20808041025r42e640famf8ae9e07e5d3bca@mail.gmail.com> <48974877.6050202@isi.edu> <396556a20808051127m4c03dd9cr4bfa0209fdb059b2@mail.gmail.com> <4898E664.6030008@isi.edu> <396556a20808051714n3baf3f9ag9e976f21f94a2cc@mail.gmail.com> X-Google-Sender-Auth: 3c0adc16b74fe1f5 Cc: tcpm@ietf.org Subject: Re: [tcpm] Faster application handshakes with SYN/ACK payloads X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Tue, Aug 5, 2008 at 5:14 PM, Adam Langley wrote: > I've just posted a new version of the draft, incorporating your > comments, which I hope is a lot clearer. Thanks for everything so far. The URL for which: http://www.ietf.org/internet-drafts/draft-agl-tcpm-sadata-01.txt AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Aug 5 18:26:07 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55F6E3A688D; Tue, 5 Aug 2008 18:26:07 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BFD83A68A8 for ; Tue, 5 Aug 2008 18:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.657 X-Spam-Level: X-Spam-Status: No, score=-1.657 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7vdXkk2jgOV for ; Tue, 5 Aug 2008 18:26:05 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by core3.amsl.com (Postfix) with ESMTP id 2CF9F3A67E5 for ; Tue, 5 Aug 2008 18:26:05 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so2433924rvf.49 for ; Tue, 05 Aug 2008 18:26:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=y4GP/Mryt5RjPJvQ2x65xL8BNW/9lVS+tNEv2Jat4a0=; b=XXYnhJ9eGcev06UoDK8K1SX/0fnky4avIkRohnm3tFmz14rP0eQNBDGidBBLsMoyqC OiVnM12t/0GS7quch6lLqqqxp30oWK1h1OQ49mQDfX+tfVyTN4b8oLyW1RqSCpW6BS9V Rpgt7mcDhNdT3xoZH9fGqD/Nra8QyysduN34Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=J1ZjhCgoRcjCaZRp1yeh6AUQ35o6mnRpg7ewdBCqoTqvNxKmpOfR8sYFb9TiOzyhYi GomGqiVRIrIAuN+SzCkU0/RA7pfGpfuoTaaCDhk84sMf2ZLdlZAUa42Byg8rBvYQ4IEO nUh3aT8/w+D5YCEvWxdXVXIeqloZ+T245JANA= Received: by 10.141.132.1 with SMTP id j1mr8570061rvn.64.1217985996798; Tue, 05 Aug 2008 18:26:36 -0700 (PDT) Received: by 10.141.37.3 with HTTP; Tue, 5 Aug 2008 18:26:36 -0700 (PDT) Message-ID: <396556a20808051826w1a839577q956f379f56db1165@mail.gmail.com> Date: Tue, 5 Aug 2008 18:26:36 -0700 From: "Adam Langley" To: "Joe Touch" In-Reply-To: <48935FFD.4090805@isi.edu> MIME-Version: 1.0 Content-Disposition: inline References: <4890F4BE.6060302@isi.edu> <396556a20807301622l4cb33deuff73cd13d7a75ba1@mail.gmail.com> <4890FBE8.1020203@isi.edu> <396556a20807311700w1eda50b0o5da7ae52e6c1691a@mail.gmail.com> <48935FFD.4090805@isi.edu> X-Google-Sender-Auth: c2dd3df7e02fdcb0 Cc: tcpm@ietf.org Subject: Re: [tcpm] tcp-auth-opt issue: support for NATs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Fri, Aug 1, 2008 at 12:11 PM, Joe Touch wrote: > Key rotations (presumably you're talking about the master key) may > require some synchronization, which seems unlikely in the case of NATs > as well. A time based key rotation would only require that endpoints have synchronised clocks to within an arbitrary amount of time. A minute would seem reasonable. > There are a few questions that may be useful to address to move forward: > > - is the use of wildcards/ingore addrs/ports compatible with > the desire for unique per-connection keys? Unless the SEQ/ACK randomness is compromised, 64-bits of random data should be enough I believe. If the randomness *is* compromised, then adding in the ports and addresses to the calculation does little for security since those values are known. > - is it OK to require that all NAT'd clients use the same > key In the cases where people would consider setting things up this way (when manual/automatic key distribution is too burdensome) then I would suggest, yes. > - is it OK to require that support for NATs means > using wildcard'd keys? Again, I would say yes. Noting that this scheme (wildcarding keys) does not prohibit manual or automatic key distribution. It's simply a low-setup-cost addition to those schemes. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Aug 5 19:02:31 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BC283A6939; Tue, 5 Aug 2008 19:02:31 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E229D3A6957 for ; Tue, 5 Aug 2008 19:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.641 X-Spam-Level: X-Spam-Status: No, score=-0.641 tagged_above=-999 required=5 tests=[AWL=-0.146, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oljJk4eb4zxz for ; Tue, 5 Aug 2008 19:02:29 -0700 (PDT) Received: from kilo.rtfm.com (unknown [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id DE3053A6939 for ; Tue, 5 Aug 2008 19:02:25 -0700 (PDT) Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id D1C69525D8F; Tue, 5 Aug 2008 19:02:57 -0700 (PDT) Date: Tue, 05 Aug 2008 19:02:57 -0700 From: Eric Rescorla To: "Adam Langley" In-Reply-To: <396556a20808051826w1a839577q956f379f56db1165@mail.gmail.com> References: <4890F4BE.6060302@isi.edu> <396556a20807301622l4cb33deuff73cd13d7a75ba1@mail.gmail.com> <4890FBE8.1020203@isi.edu> <396556a20807311700w1eda50b0o5da7ae52e6c1691a@mail.gmail.com> <48935FFD.4090805@isi.edu> <396556a20808051826w1a839577q956f379f56db1165@mail.gmail.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080806020257.D1C69525D8F@kilo.rtfm.com> Cc: tcpm@ietf.org, Joe Touch Subject: Re: [tcpm] tcp-auth-opt issue: support for NATs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At Tue, 5 Aug 2008 18:26:36 -0700, Adam Langley wrote: > > On Fri, Aug 1, 2008 at 12:11 PM, Joe Touch wrote: > > Key rotations (presumably you're talking about the master key) may > > require some synchronization, which seems unlikely in the case of NATs > > as well. > > A time based key rotation would only require that endpoints have > synchronised clocks to within an arbitrary amount of time. A minute > would seem reasonable. Isn't the whole point of the key-ids to avoid requiring this? -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Aug 6 04:29:22 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE2313A6BE0; Wed, 6 Aug 2008 04:29:22 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F5333A68BC for ; Wed, 6 Aug 2008 04:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.51 X-Spam-Level: X-Spam-Status: No, score=-6.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3MRcy8YPOEe for ; Wed, 6 Aug 2008 04:29:20 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 184C63A6BDA for ; Wed, 6 Aug 2008 04:29:19 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m76BTK09026604; Wed, 6 Aug 2008 14:29:44 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Aug 2008 14:29:19 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Aug 2008 14:29:13 +0300 Received: from [192.168.1.116] ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Aug 2008 14:29:13 +0300 Message-Id: <8558B862-CB5D-47A6-A7B4-8B08B5910423@nokia.com> From: Lars Eggert To: ext Mahesh Jethanandani In-Reply-To: <489201AE.1080706@cisco.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Wed, 6 Aug 2008 14:29:07 +0300 References: <489201AE.1080706@cisco.com> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 06 Aug 2008 11:29:13.0989 (UTC) FILETIME=[A76A3350:01C8F7B7] X-Nokia-AV: Clean Cc: tcpm@ietf.org Subject: Re: [tcpm] draft IETF 72 meeting notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On 2008-7-31, at 21:17, ext Mahesh Jethanandani wrote: >> Lars: if I was chair calling consensus - FAIL - don't adopt it as >> WG item. Call on WG for proposed std failed. >> > In offline discussion with Lars and others it was clear there was > confusion about which draft was being requested for WG item. Yes, > the original persist draft had not been accepted by WG. On > suggestion by the chairs (Mark and Ted at that time) a short > information draft describing just the sender behavior was written > and presented in the meeting. It is that draft which is being > requested for adoption by WG. > > Lars, I hope I have captured the spirit of the discussion. This is correct - I was confused as to which draft we were discussing. Sorry. Disregard my statement. Lars _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Aug 6 04:32:01 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F1FF3A68BC; Wed, 6 Aug 2008 04:32:01 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C75883A68BC for ; Wed, 6 Aug 2008 04:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.512 X-Spam-Level: X-Spam-Status: No, score=-6.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lp-LXIn+aUAA for ; Wed, 6 Aug 2008 04:32:00 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id CA9B13A682C for ; Wed, 6 Aug 2008 04:31:59 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m76BWSs9030025; Wed, 6 Aug 2008 14:32:30 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Aug 2008 14:32:29 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Aug 2008 14:32:17 +0300 Received: from [192.168.1.116] ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Aug 2008 14:32:16 +0300 Message-Id: <3FBA635A-0473-4B58-86E2-C7523A35CE24@nokia.com> From: Lars Eggert To: ext Joe Touch In-Reply-To: <48935983.80701@isi.edu> Mime-Version: 1.0 (Apple Message framework v926) Date: Wed, 6 Aug 2008 14:32:02 +0300 References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488DD77D.9070608@isi.edu> <20080728144721.AC9184B905A@kilo.rtfm.com> <488DE021.7070307@isi.edu> <20080728164013.422D14B9600@kilo.rtfm.com> <20080730213253.B347F4D52E1@kilo.rtfm.com> <4890E9AE.3000607@isi.edu> <20080731001609.6511C4D5E34@kilo.rtfm.com> <489175BD.6040201@isi.edu> <396556a20807311010k78c22981xa0eebd1b46e9f619@mail.gmail.com> <48935983.80701@isi.edu> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 06 Aug 2008 11:32:17.0330 (UTC) FILETIME=[14B1D120:01C8F7B8] X-Nokia-AV: Clean Cc: Adam Langley , tcpm@ietf.org Subject: Re: [tcpm] tcp-auth-opt issue: replay protection X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On 2008-8-1, at 21:44, ext Joe Touch wrote: > IMO: retransmitted packets would use the currently active keyID > (even if > different from what was previously transmitted). I agree. TCP retransmits previous data, not previous segments. Lars (as an individual contributor) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Aug 6 04:47:47 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 553AB3A6C42; Wed, 6 Aug 2008 04:47:47 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D435F3A6C42 for ; Wed, 6 Aug 2008 04:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKYeXWAdUOe6 for ; Wed, 6 Aug 2008 04:47:46 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 02F503A6C0F for ; Wed, 6 Aug 2008 04:47:45 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m76Bl14a002687; Wed, 6 Aug 2008 06:47:46 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Aug 2008 14:47:42 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Aug 2008 14:47:37 +0300 Received: from [192.168.1.116] ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Aug 2008 14:47:37 +0300 Message-Id: From: Lars Eggert To: ext Joe Touch In-Reply-To: <48939933.3030601@isi.edu> Mime-Version: 1.0 (Apple Message framework v926) Date: Wed, 6 Aug 2008 14:47:31 +0300 References: <0C53DCFB700D144284A584F54711EC58058C2FD4@xmb-sjc-21c.amer.cisco.com> <48939933.3030601@isi.edu> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 06 Aug 2008 11:47:37.0349 (UTC) FILETIME=[39119350:01C8F7BA] X-Nokia-AV: Clean Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] TCP-AO review comments. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On 2008-8-2, at 2:16, ext Joe Touch wrote: > | I have problem with the term "obsoletes 2385" [ I did bring > this up > | before] It is going to be a long time before deployments move over > to > | the new TCP auth option. > > Practically, "obsoletes" doesn't obsolete anything. It does indicate > that the IETF wants a protocol to be replaced by something else. That > doesn't mean the older one can't be used for legacy support, e.g., > AFAICT - and that clearly should apply here. If the IESG thinks that > this is consistent with "Obsoltes", would that be OK? We need to distinguish between one RFC obsoleting another RFC, and moving an RFC to "historic". Unfortunately, neither is very clearly defined. Here's my current thinking: Obsoleting is typically used when one RFC is a drop-in replacement for another RFC. For example, bug-fix revisions of an RFC typically obsolete the previous RFC, as do minor backwards-compatible implementations. That isn't quite the case for AO and TCP-MD5. AO is a replacement for TCP-MD5, but it isn't a simple revision or extension of TCP-MD5, it's a new mechanism to provide similar functionality in a (slightly) different way. So, my current thinking is that AO should maybe move TCP-MD5 to "historic". That would indicate that new implementations shouldn't implement TCP-MD5 and existing ones are encouraged to move away from it. But this isn't a clear -cut case. Comments? Lars _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Aug 6 06:37:51 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F207D3A6BD0; Wed, 6 Aug 2008 06:37:50 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD17828C286 for ; Wed, 6 Aug 2008 06:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AiISdypXwzTL for ; Wed, 6 Aug 2008 06:37:49 -0700 (PDT) Received: from kilo.rtfm.com (unknown [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 341F53A68BF for ; Wed, 6 Aug 2008 06:37:49 -0700 (PDT) Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 7721D527252; Wed, 6 Aug 2008 06:37:34 -0700 (PDT) Date: Wed, 06 Aug 2008 06:37:34 -0700 From: Eric Rescorla To: Lars Eggert In-Reply-To: <3FBA635A-0473-4B58-86E2-C7523A35CE24@nokia.com> References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488DD77D.9070608@isi.edu> <20080728144721.AC9184B905A@kilo.rtfm.com> <488DE021.7070307@isi.edu> <20080728164013.422D14B9600@kilo.rtfm.com> <20080730213253.B347F4D52E1@kilo.rtfm.com> <4890E9AE.3000607@isi.edu> <20080731001609.6511C4D5E34@kilo.rtfm.com> <489175BD.6040201@isi.edu> <396556a20807311010k78c22981xa0eebd1b46e9f619@mail.gmail.com> <48935983.80701@isi.edu> <3FBA635A-0473-4B58-86E2-C7523A35CE24@nokia.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080806133734.7721D527252@kilo.rtfm.com> Cc: Adam Langley , tcpm@ietf.org, ext Joe Touch Subject: Re: [tcpm] tcp-auth-opt issue: replay protection X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At Wed, 6 Aug 2008 14:32:02 +0300, Lars Eggert wrote: > > On 2008-8-1, at 21:44, ext Joe Touch wrote: > > IMO: retransmitted packets would use the currently active keyID > > (even if > > different from what was previously transmitted). > > I agree. TCP retransmits previous data, not previous segments. I agree it should be permissible to use the new key-id, but should it be required? I don't know a lot about TCP stack implementations, but do any of them currently save existing packets and just retransmit them? That's legal, right? If so, this would break that. I would argue that if we are to use internal key rollover to handle seqno rollover that you then use the old key even when you retransmit. [0] Otherwise, you end up with ambiguity about which key is in play. -Ekr [0] Incidentally, this is an argument for ESNs, I believe. If you have a key-id transition at the same time as a seqno rollover, you might have ambiguity about whether the key had rolled over in between in the face of packet loss. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Aug 6 07:00:04 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7022D28C385; Wed, 6 Aug 2008 07:00:04 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C3E428C383 for ; Wed, 6 Aug 2008 07:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOCzSrNoAHnE for ; Wed, 6 Aug 2008 07:00:02 -0700 (PDT) Received: from mail1.sea5.speakeasy.net (mail1.sea5.speakeasy.net [69.17.117.3]) by core3.amsl.com (Postfix) with ESMTP id 1667928C384 for ; Wed, 6 Aug 2008 07:00:02 -0700 (PDT) Received: (qmail 13870 invoked from network); 6 Aug 2008 13:58:36 -0000 Received: from imac.asomi.com (cait@asomi.com@[66.92.48.27]) (envelope-sender ) by mail1.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 6 Aug 2008 13:58:36 -0000 Message-ID: <4899AE0C.6080206@asomi.com> Date: Wed, 06 Aug 2008 06:58:36 -0700 From: Caitlin Bestler User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Lars Eggert References: <0C53DCFB700D144284A584F54711EC58058C2FD4@xmb-sjc-21c.amer.cisco.com> <48939933.3030601@isi.edu> In-Reply-To: Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , ext Joe Touch Subject: Re: [tcpm] TCP-AO review comments. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Lars Eggert wrote: > On 2008-8-2, at 2:16, ext Joe Touch wrote: >> | I have problem with the term "obsoletes 2385" [ I did bring this up >> | before] It is going to be a long time before deployments move over to >> | the new TCP auth option. >> >> Practically, "obsoletes" doesn't obsolete anything. It does indicate >> that the IETF wants a protocol to be replaced by something else. That >> doesn't mean the older one can't be used for legacy support, e.g., >> AFAICT - and that clearly should apply here. If the IESG thinks that >> this is consistent with "Obsoltes", would that be OK? > > We need to distinguish between one RFC obsoleting another RFC, and > moving an RFC to "historic". Unfortunately, neither is very clearly > defined. > > Here's my current thinking: Obsoleting is typically used when one RFC is > a drop-in replacement for another RFC. For example, bug-fix revisions of > an RFC typically obsolete the previous RFC, as do minor > backwards-compatible implementations. That isn't quite the case for AO > and TCP-MD5. AO is a replacement for TCP-MD5, but it isn't a simple > revision or extension of TCP-MD5, it's a new mechanism to provide > similar functionality in a (slightly) different way. > > So, my current thinking is that AO should maybe move TCP-MD5 to > "historic". That would indicate that new implementations shouldn't > implement TCP-MD5 and existing ones are encouraged to move away from it. > But this isn't a clear -cut case. Comments? > I have always viewed a new TCP-Auth RFC as a drop-in replacement for TCP-MD5. Basically, this is an application layer problem being foisted upon the transport layer. It creates unneeded clutter at the transport layer that is not of general utility. The fact that it is replacing an existing option is the only real justification for doing it. Stare decisis is good for constitutional law, it makes sense for standards as well. But we need to be clear that we are not creating an *additional* transport layer encryption solution to solve poor application design, we're just replacing an existing problem. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Aug 6 07:06:21 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BA553A6891; Wed, 6 Aug 2008 07:06:21 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81AA03A6891 for ; Wed, 6 Aug 2008 07:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.521 X-Spam-Level: X-Spam-Status: No, score=-6.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFLigVf+PVNj for ; Wed, 6 Aug 2008 07:06:18 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 86D653A63D3 for ; Wed, 6 Aug 2008 07:06:18 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m76E4Oc4000674; Wed, 6 Aug 2008 09:06:31 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Aug 2008 17:06:29 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Aug 2008 17:06:21 +0300 Received: from [192.168.1.116] ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Aug 2008 17:06:20 +0300 Message-Id: <045CB0E7-78B2-49B8-91C9-B2AB19C47A05@nokia.com> From: Lars Eggert To: ext Eric Rescorla In-Reply-To: <20080806133734.7721D527252@kilo.rtfm.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Wed, 6 Aug 2008 17:06:14 +0300 References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488DD77D.9070608@isi.edu> <20080728144721.AC9184B905A@kilo.rtfm.com> <488DE021.7070307@isi.edu> <20080728164013.422D14B9600@kilo.rtfm.com> <20080730213253.B347F4D52E1@kilo.rtfm.com> <4890E9AE.3000607@isi.edu> <20080731001609.6511C4D5E34@kilo.rtfm.com> <489175BD.6040201@isi.edu> <396556a20807311010k78c22981xa0eebd1b46e9f619@mail.gmail.com> <48935983.80701@isi.edu> <3FBA635A-0473-4B58-86E2-C7523A35CE24@nokia.com> <20080806133734.7721D527252@kilo.rtfm.com> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 06 Aug 2008 14:06:21.0196 (UTC) FILETIME=[9A77D4C0:01C8F7CD] X-Nokia-AV: Clean Cc: Adam Langley , tcpm@ietf.org, ext Joe Touch Subject: Re: [tcpm] tcp-auth-opt issue: replay protection X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On 2008-8-6, at 16:37, ext Eric Rescorla wrote: > At Wed, 6 Aug 2008 14:32:02 +0300, > Lars Eggert wrote: >> >> On 2008-8-1, at 21:44, ext Joe Touch wrote: >>> IMO: retransmitted packets would use the currently active keyID >>> (even if >>> different from what was previously transmitted). >> >> I agree. TCP retransmits previous data, not previous segments. > > I agree it should be permissible to use the new key-id, but > should it be required? I don't think we need to require that the new key be used. I was trying to argue that we shouldn't require that the old key be used. > I don't know a lot about > TCP stack implementations, but do any of them currently save > existing packets and just retransmit them? That's legal, right? > If so, this would break that. I don't think saving sent segments makes a lot of sense. It may work, but ACK/SACK and timestamp information of the old packets would be out of sync relative to the current connection state, so I'd expect there could at the very least be inefficiencies. Unless I'm misremembering, all the stacks that I'm familiar with create a new segment for retransmitting lost data with TCP control information that accurately reflects the current connection state. Lars > I would argue that if we are to use internal key rollover to handle > seqno rollover that you then use the old key even when you > retransmit. [0] > Otherwise, you end up with ambiguity about which key is in play. > > -Ekr > > [0] Incidentally, this is an argument for ESNs, I believe. If you > have a key-id transition at the same time as a seqno rollover, you > might have ambiguity about whether the key had rolled over in > between in the face of packet loss. > > > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Aug 6 07:57:43 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C65B228C367; Wed, 6 Aug 2008 07:57:43 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A81128C367 for ; Wed, 6 Aug 2008 07:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.228 X-Spam-Level: X-Spam-Status: No, score=-6.228 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2X0PSOxCW74X for ; Wed, 6 Aug 2008 07:57:42 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 396BF28C356 for ; Wed, 6 Aug 2008 07:57:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,315,1215388800"; d="scan'208";a="62232394" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 06 Aug 2008 14:58:16 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m76EwGN9023702; Wed, 6 Aug 2008 07:58:16 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m76EwGJE021526; Wed, 6 Aug 2008 14:58:16 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Aug 2008 07:58:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 6 Aug 2008 07:57:05 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC58059847E3@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <045CB0E7-78B2-49B8-91C9-B2AB19C47A05@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] tcp-auth-opt issue: replay protection Thread-Index: Acj3zbA4PpIJO84dQT2cwVyRc68IkQABLCYg References: <20080728042451.C7A174B7AD3@kilo.rtfm.com><488DD77D.9070608@isi.edu><20080728144721.AC9184B905A@kilo.rtfm.com><488DE021.7070307@isi.edu><20080728164013.422D14B9600@kilo.rtfm.com><20080730213253.B347F4D52E1@kilo.rtfm.com><4890E9AE.3000607@isi.edu><20080731001609.6511C4D5E34@kilo.rtfm.com><489175BD.6040201@isi.edu><396556a20807311010k78c22981xa0eebd1b46e9f619@mail.gmail.com><48935983.80701@isi.edu><3FBA635A-0473-4B58-86E2-C7523A35CE24@nokia.com><20080806133734.7721D527252@kilo.rtfm.com> <045CB0E7-78B2-49B8-91C9-B2AB19C47A05@nokia.com> From: "Anantha Ramaiah (ananth)" To: "Lars Eggert" , "ext Eric Rescorla" X-OriginalArrivalTime: 06 Aug 2008 14:58:15.0929 (UTC) FILETIME=[DAFE5E90:01C8F7D4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1164; t=1218034696; x=1218898696; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20 |Subject:=20RE=3A=20[tcpm]=20tcp-auth-opt=20issue=3A=20repl ay=20protection |Sender:=20; bh=+UVV0KI9AidKf1Ner7XHxtQtTPqJatmrGB69Rx+s0T4=; b=m9CkvwW61g3YAVvflC9ym1MhtMG08CgZkEi2lT3EfFA7po33OJw4mAMjGx 3sHxd3QG5ruuuqKnAEIx4GmK0a6HmnXHaWygUaAEgLP1Gad/e4Spy9MeAH3V czj893mKehdlV2jMsVxwErFbzrZs6v0UZfvHiHyBO/+LPgKKKHMYY=; Authentication-Results: sj-dkim-1; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Adam Langley , tcpm@ietf.org, ext Joe Touch Subject: Re: [tcpm] tcp-auth-opt issue: replay protection X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org > I don't think saving sent segments makes a lot of sense. It > may work, but ACK/SACK and timestamp information of the old > packets would be out of sync relative to the current > connection state, so I'd expect there could at the very least > be inefficiencies. Unless I'm misremembering, all the stacks > that I'm familiar with create a new segment for > retransmitting lost data with TCP control information that > accurately reflects the current connection state. FWIW : Since you are talking about implementations, stacks which care about efficiency would still use the same old packet (assuming no re-packetization needs to be done) and will simply re-do the necessary fields (timestamps, ACK/SACK, MD5 etc.,) and transmit the packet. Clearly, the ammount of work you need to do to fix-up the packet for retransmission depends on how many options are there and how much information has changed. [Again you don't expect the IP options to be changed in between retransmissions]. This is different from fetching a new packet and copying the data and fixing up all the information, which is less efficient. -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Aug 6 08:05:07 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27C7A28C393; Wed, 6 Aug 2008 08:05:07 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D289D28C354 for ; Wed, 6 Aug 2008 08:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.527 X-Spam-Level: X-Spam-Status: No, score=-1.527 tagged_above=-999 required=5 tests=[AWL=1.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXA6CJw0wCzl for ; Wed, 6 Aug 2008 08:05:04 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 98EAF28C358 for ; Wed, 6 Aug 2008 08:05:04 -0700 (PDT) Received: from [192.168.2.121] (bolongo.jbtelenet.com [204.11.152.116]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m76F4JHv006690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 6 Aug 2008 08:04:36 -0700 (PDT) Message-ID: <4899BD4A.9040509@isi.edu> Date: Wed, 06 Aug 2008 08:03:38 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Eric Rescorla References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488DD77D.9070608@isi.edu> <20080728144721.AC9184B905A@kilo.rtfm.com> <488DE021.7070307@isi.edu> <20080728164013.422D14B9600@kilo.rtfm.com> <20080730213253.B347F4D52E1@kilo.rtfm.com> <4890E9AE.3000607@isi.edu> <20080731001609.6511C4D5E34@kilo.rtfm.com> <489175BD.6040201@isi.edu> <396556a20807311010k78c22981xa0eebd1b46e9f619@mail.gmail.com> <48935983.80701@isi.edu> <3FBA635A-0473-4B58-86E2-C7523A35CE24@nokia.com> <20080806133734.7721D527252@kilo.rtfm.com> In-Reply-To: <20080806133734.7721D527252@kilo.rtfm.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Adam Langley , tcpm@ietf.org Subject: Re: [tcpm] tcp-auth-opt issue: replay protection X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Rescorla wrote: | At Wed, 6 Aug 2008 14:32:02 +0300, | Lars Eggert wrote: |> On 2008-8-1, at 21:44, ext Joe Touch wrote: |>> IMO: retransmitted packets would use the currently active keyID |>> (even if |>> different from what was previously transmitted). |> I agree. TCP retransmits previous data, not previous segments. | | I agree it should be permissible to use the new key-id, but | should it be required? I don't know a lot about | TCP stack implementations, but do any of them currently save | existing packets and just retransmit them? That's legal, right? | If so, this would break that. Does anyone know what happens to other options? I.e., aren't timestamps recomputed, SACK options recalculated, etc.? It seems like the options need to be revisited when a segment goes out the door anyway, and a stack that just replays segments is what might be considered "broken"... Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiZvUoACgkQE5f5cImnZrsYNgCfTbiRWhSyUB+94q7Vael7jvNR uwUAoJiVPk7mSlkaFhgrrJglhCowQ0B7 =y3nm -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Aug 6 08:06:02 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 752EE28C3A1; Wed, 6 Aug 2008 08:06:02 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DFD128C3A0 for ; Wed, 6 Aug 2008 08:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.684 X-Spam-Level: X-Spam-Status: No, score=-1.684 tagged_above=-999 required=5 tests=[AWL=0.915, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aylKFJKVSzHB for ; Wed, 6 Aug 2008 08:05:59 -0700 (PDT) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id ACADC28C392 for ; Wed, 6 Aug 2008 08:05:59 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 00C3B50846; Wed, 6 Aug 2008 08:15:33 -0700 (PDT) Date: Wed, 06 Aug 2008 08:15:33 -0700 From: Eric Rescorla To: Caitlin Bestler In-Reply-To: <4899AE0C.6080206@asomi.com> References: <0C53DCFB700D144284A584F54711EC58058C2FD4@xmb-sjc-21c.amer.cisco.com> <48939933.3030601@isi.edu> <4899AE0C.6080206@asomi.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080806151534.00C3B50846@romeo.rtfm.com> Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , ext Joe Touch Subject: Re: [tcpm] TCP-AO review comments. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At Wed, 06 Aug 2008 06:58:36 -0700, Caitlin Bestler wrote: > > Lars Eggert wrote: > > On 2008-8-2, at 2:16, ext Joe Touch wrote: > >> | I have problem with the term "obsoletes 2385" [ I did bring this up > >> | before] It is going to be a long time before deployments move over to > >> | the new TCP auth option. > >> > >> Practically, "obsoletes" doesn't obsolete anything. It does indicate > >> that the IETF wants a protocol to be replaced by something else. That > >> doesn't mean the older one can't be used for legacy support, e.g., > >> AFAICT - and that clearly should apply here. If the IESG thinks that > >> this is consistent with "Obsoltes", would that be OK? > > > > We need to distinguish between one RFC obsoleting another RFC, and > > moving an RFC to "historic". Unfortunately, neither is very clearly > > defined. > > > > Here's my current thinking: Obsoleting is typically used when one RFC is > > a drop-in replacement for another RFC. For example, bug-fix revisions of > > an RFC typically obsolete the previous RFC, as do minor > > backwards-compatible implementations. That isn't quite the case for AO > > and TCP-MD5. AO is a replacement for TCP-MD5, but it isn't a simple > > revision or extension of TCP-MD5, it's a new mechanism to provide > > similar functionality in a (slightly) different way. > > > > So, my current thinking is that AO should maybe move TCP-MD5 to > > "historic". That would indicate that new implementations shouldn't > > implement TCP-MD5 and existing ones are encouraged to move away from it. > > But this isn't a clear -cut case. Comments? > > > > I have always viewed a new TCP-Auth RFC as a drop-in replacement > for TCP-MD5. > > Basically, this is an application layer problem being foisted upon > the transport layer. It creates unneeded clutter at the transport > layer that is not of general utility. > > The fact that it is replacing an existing option is the only real > justification for doing it. Stare decisis is good for constitutional > law, it makes sense for standards as well. > > But we need to be clear that we are not creating an *additional* > transport layer encryption solution to solve poor application design, > we're just replacing an existing problem. Hmm... I'm not sure I agree with this assessment. What do you think the application layer problem in question is? -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Aug 6 08:11:48 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D7733A6BDE; Wed, 6 Aug 2008 08:11:48 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D51543A6BD5 for ; Wed, 6 Aug 2008 08:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.038 X-Spam-Level: X-Spam-Status: No, score=-6.038 tagged_above=-999 required=5 tests=[AWL=0.561, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SlYPh-RBvad for ; Wed, 6 Aug 2008 08:11:47 -0700 (PDT) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id F3BB73A68F7 for ; Wed, 6 Aug 2008 08:11:46 -0700 (PDT) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 0395232827C; Wed, 6 Aug 2008 10:12:07 -0500 (CDT) Received: from ndjsxgw04.ndc.nasa.gov (ndjsxgw04.ndc.nasa.gov [129.166.32.112]) by ndjsppt02.ndc.nasa.gov (8.14.1/8.14.1) with ESMTP id m76FC66E018916; Wed, 6 Aug 2008 10:12:06 -0500 Received: from NDJSEVS25A.ndc.nasa.gov ([129.166.32.124]) by ndjsxgw04.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Aug 2008 10:12:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 6 Aug 2008 10:12:05 -0500 Message-ID: In-Reply-To: <4899BD4A.9040509@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] tcp-auth-opt issue: replay protection Thread-Index: Acj31euGnaE4Gq8BR0aOJkhrzu5bigAAGPSw References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488DD77D.9070608@isi.edu> <20080728144721.AC9184B905A@kilo.rtfm.com> <488DE021.7070307@isi.edu> <20080728164013.422D14B9600@kilo.rtfm.com> <20080730213253.B347F4D52E1@kilo.rtfm.com> <4890E9AE.3000607@isi.edu> <20080731001609.6511C4D5E34@kilo.rtfm.com> <489175BD.6040201@isi.edu> <396556a20807311010k78c22981xa0eebd1b46e9f619@mail.gmail.com> <48935983.80701@isi.edu> <3FBA635A-0473-4B58-86E2-C7523A35CE24@nokia.com><20080806133734.7721D527252@kilo.rtfm.com> <4899BD4A.9040509@isi.edu> From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" To: "Joe Touch" , "Eric Rescorla" X-OriginalArrivalTime: 06 Aug 2008 15:12:06.0880 (UTC) FILETIME=[CA476E00:01C8F7D6] Cc: Adam Langley , tcpm@ietf.org Subject: Re: [tcpm] tcp-auth-opt issue: replay protection X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org >-----Original Message----- >From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On >Behalf Of Joe Touch >Sent: Wednesday, August 06, 2008 11:04 AM >To: Eric Rescorla > >Eric Rescorla wrote: >| At Wed, 6 Aug 2008 14:32:02 +0300, >| Lars Eggert wrote: >|> On 2008-8-1, at 21:44, ext Joe Touch wrote: >|>> IMO: retransmitted packets would use the currently active keyID >|>> (even if >|>> different from what was previously transmitted). >|> I agree. TCP retransmits previous data, not previous segments. >| >| I agree it should be permissible to use the new key-id, but >| should it be required? I don't know a lot about >| TCP stack implementations, but do any of them currently save >| existing packets and just retransmit them? That's legal, right? >| If so, this would break that. > > >Does anyone know what happens to other options? I.e., aren't timestamps >recomputed, SACK options recalculated, etc.? It seems like the options >need to be revisited when a segment goes out the door anyway, and a >stack that just replays segments is what might be considered >"broken"... I think you're 100% correct in assuming the options are recreated for retransmissions. The only stacks I've seen that store segments in order to do a retransmission are oddball ones for teeny-tiny systems, and they don't do any TCP options in those stacks anyways, so they definitely would not be concerned with the Auth Option. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Aug 6 08:47:30 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19CA23A6AA7; Wed, 6 Aug 2008 08:47:30 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 587D73A6AA7 for ; Wed, 6 Aug 2008 08:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.671 X-Spam-Level: X-Spam-Status: No, score=-1.671 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zo3E9l0NmTrK for ; Wed, 6 Aug 2008 08:47:27 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by core3.amsl.com (Postfix) with ESMTP id 7490F3A68BF for ; Wed, 6 Aug 2008 08:47:27 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so2718428rvf.49 for ; Wed, 06 Aug 2008 08:48:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=ljA2eJTTwsupcTm7sy8aiwPSKM92ErSg8RvwrLToqM4=; b=URqXKEhEiWe+WHbb+K7gH2xTAkgooew94rywzua48jqBdnJGo4XLGeDXMWbMjXa42/ 46hJ50yihfC8IdL6/qRxrKqlqwXV6JOIOj6OkkNNFcwNO+hGxFhUURLEReCroCWquJZT B3oZ1KiN4qitdO0YlELEjCYJ/caXh/74su0dQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=pow4Q1awDaA57MpRXWkxttwbR4KP53TCINIImtjQ0w0cAG3ZMk+ogjMgLwbWl+w12A vh35dGzMJ+waI38uDqSUFs8P9MFiqBRVQzGJxwUYWHqRoVibumkgFMh6YHub7Oe0eY8/ 4xHQS4JWBUJAy4U7u1iQzsPMbLRdoyaMQ7mXE= Received: by 10.141.206.13 with SMTP id i13mr96623rvq.211.1218037680443; Wed, 06 Aug 2008 08:48:00 -0700 (PDT) Received: by 10.141.37.3 with HTTP; Wed, 6 Aug 2008 08:48:00 -0700 (PDT) Message-ID: <396556a20808060848g40df6251hf02467697ec44925@mail.gmail.com> Date: Wed, 6 Aug 2008 08:48:00 -0700 From: "Adam Langley" To: "Joe Touch" In-Reply-To: <4899BD4A.9040509@isi.edu> MIME-Version: 1.0 Content-Disposition: inline References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <20080730213253.B347F4D52E1@kilo.rtfm.com> <4890E9AE.3000607@isi.edu> <20080731001609.6511C4D5E34@kilo.rtfm.com> <489175BD.6040201@isi.edu> <396556a20807311010k78c22981xa0eebd1b46e9f619@mail.gmail.com> <48935983.80701@isi.edu> <3FBA635A-0473-4B58-86E2-C7523A35CE24@nokia.com> <20080806133734.7721D527252@kilo.rtfm.com> <4899BD4A.9040509@isi.edu> X-Google-Sender-Auth: fa60b8d4cf286891 Cc: tcpm@ietf.org Subject: Re: [tcpm] tcp-auth-opt issue: replay protection X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Wed, Aug 6, 2008 at 8:03 AM, Joe Touch wrote: > Does anyone know what happens to other options? I.e., aren't timestamps > recomputed, SACK options recalculated, etc.? It seems like the options > need to be revisited when a segment goes out the door anyway, and a > stack that just replays segments is what might be considered "broken"... I can speak for the Linux stack: Buffers are kept around for retransmissions, but the buffers only maintain the segment data. TCP and IP headers are recreated without any reference to any previous transmissions. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Aug 6 09:55:10 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C71393A67D4; Wed, 6 Aug 2008 09:55:10 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88D4E3A67D4 for ; Wed, 6 Aug 2008 09:55:09 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrKPgmspWnh8 for ; Wed, 6 Aug 2008 09:55:08 -0700 (PDT) Received: from owa.neterion.com (mx.neterion.com [72.1.205.142]) by core3.amsl.com (Postfix) with ESMTP id A28BA3A63CB for ; Wed, 6 Aug 2008 09:55:08 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 6 Aug 2008 12:55:13 -0400 Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD7704042099@nekter> In-Reply-To: <396556a20808060848g40df6251hf02467697ec44925@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] tcp-auth-opt issue: replay protection Thread-Index: Acj329JZzoyPLViyRVqPCPWjBInMKwACIyCw References: <20080728042451.C7A174B7AD3@kilo.rtfm.com><20080730213253.B347F4D52E1@kilo.rtfm.com> <4890E9AE.3000607@isi.edu><20080731001609.6511C4D5E34@kilo.rtfm.com> <489175BD.6040201@isi.edu><396556a20807311010k78c22981xa0eebd1b46e9f619@mail.gmail.com><48935983.80701@isi.edu><3FBA635A-0473-4B58-86E2-C7523A35CE24@nokia.com><20080806133734.7721D527252@kilo.rtfm.com> <4899BD4A.9040509@isi.edu> <396556a20808060848g40df6251hf02467697ec44925@mail.gmail.com> From: "Caitlin Bestler" To: "Adam Langley" , "Joe Touch" Cc: tcpm@ietf.org Subject: Re: [tcpm] tcp-auth-opt issue: replay protection X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Adam Langley wrote: > > On Wed, Aug 6, 2008 at 8:03 AM, Joe Touch wrote: > > Does anyone know what happens to other options? I.e., aren't > timestamps > > recomputed, SACK options recalculated, etc.? It seems like the > options > > need to be revisited when a segment goes out the door anyway, and a > > stack that just replays segments is what might be considered > "broken"... > > I can speak for the Linux stack: > > Buffers are kept around for retransmissions, but the buffers only > maintain the segment data. TCP and IP headers are recreated without > any reference to any previous transmissions. > > That's also true of most TCP offload solutions I've seen. Fundamentally, it is easier for almost all implementations to keep a descriptor of a transmitted segment around (and not allow the client to re-use its buffer) than it is to keep a full copy of the formed TCP segment around. After all, even in networks with atrocious drop rates the typical TCP segment will NOT be retransmitted. Since retransmission is the exception MOST implementations would rather redo the TCP header construction than use memory to remember exactly what they did last time. It's easier to just remember enough so that you will generate the same output. Specialized designs and/or prototypes are more likely to do things like follow strict layering where they might actually store the entire frame to simplify interfaces. But those designs, in my experience, will be the exception. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Aug 6 17:41:46 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEB093A6AAC; Wed, 6 Aug 2008 17:41:46 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2559D3A6AAC for ; Wed, 6 Aug 2008 17:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.383 X-Spam-Level: X-Spam-Status: No, score=-1.383 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_16=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rbemjHhyhw5 for ; Wed, 6 Aug 2008 17:41:45 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by core3.amsl.com (Postfix) with ESMTP id 6033C3A677D for ; Wed, 6 Aug 2008 17:41:45 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so154079rvf.49 for ; Wed, 06 Aug 2008 17:42:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=JAUhrBmIlVKeEcOIPR2r4MkRYo8r3E//3dvl+FlOhh4=; b=BIuFC3xRzq50UqoG2/2MsJ2SuzOhk8IhIFKCkD5QldFRSqGCA6LL5Kb1UMxrO1wnQ8 GfS6t3wEsvd3QA07hGXzBm2hjbnEne23WV70oBvgln9vyFLCai0AzcLVanFR6AMQ4wG5 V1WMDu+wHOhdUJlEIIpFhWywOwcYhcWbR1Uo8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=pPTEuYwdBt65aoOfi6N4Jio2tIm2I4GRI0hlK8fdB6dOK8A2CbCOWgpeq++5eHaItS 5yE5FmmRspyjjWgs9MFcsqxElaMhR1C5AqPgaWzMnHoZhfk3/u5+7AkdIi/i7hxNaynm HymuCW+8sKcXC8XePc0TXgv1C504jDOyFPw5Q= Received: by 10.141.164.13 with SMTP id r13mr20797rvo.53.1218069739538; Wed, 06 Aug 2008 17:42:19 -0700 (PDT) Received: by 10.141.37.3 with HTTP; Wed, 6 Aug 2008 17:42:19 -0700 (PDT) Message-ID: <396556a20808061742y19f8f5fh78fe66bfe4d415be@mail.gmail.com> Date: Wed, 6 Aug 2008 17:42:19 -0700 From: "Adam Langley" To: "Eric Rescorla" In-Reply-To: <20080806020257.D1C69525D8F@kilo.rtfm.com> MIME-Version: 1.0 Content-Disposition: inline References: <4890F4BE.6060302@isi.edu> <396556a20807301622l4cb33deuff73cd13d7a75ba1@mail.gmail.com> <4890FBE8.1020203@isi.edu> <396556a20807311700w1eda50b0o5da7ae52e6c1691a@mail.gmail.com> <48935FFD.4090805@isi.edu> <396556a20808051826w1a839577q956f379f56db1165@mail.gmail.com> <20080806020257.D1C69525D8F@kilo.rtfm.com> X-Google-Sender-Auth: 0cb8383f3b9d9340 Cc: tcpm@ietf.org, Joe Touch Subject: Re: [tcpm] tcp-auth-opt issue: support for NATs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Tue, Aug 5, 2008 at 7:02 PM, Eric Rescorla wrote: > Isn't the whole point of the key-ids to avoid requiring this? Well, keyids would be required too. Here's how I see it working. Define a synchronisation range, R, say 1 minute. We require that the maximum skew between two clocks is R. Define a key rotation timespan, T, say 1 minute. Let N be the maximum number of keys that exist in a timespan of 2R. In our example, this is two. Define a function K(master, t) that maps a timestamp to a key derived from a master key and a keyid in [0, N). For example, F(master, t) = SHA1(master + uint32be (t/T)) with keyid (t/T) `mod` N. At any time, a client transmits with key and keyid from F(master, currentTime). At any time, the server accepts SYN signed with any keyid and key in a span of 2R centered around the current time. So one can only connect if one's clock skew is acceptable and one knows the master key. The keys for the resulting connection would be connection specific, probably hashing in the SEQ/ACK numbers, other stuff etc. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Aug 6 18:08:11 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24C6F3A6922; Wed, 6 Aug 2008 18:08:11 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC54C3A6966 for ; Wed, 6 Aug 2008 18:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.422 X-Spam-Level: X-Spam-Status: No, score=-1.422 tagged_above=-999 required=5 tests=[AWL=0.577, BAYES_00=-2.599, J_CHICKENPOX_16=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JLdBrYzizAg for ; Wed, 6 Aug 2008 18:08:09 -0700 (PDT) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 44B413A67A2 for ; Wed, 6 Aug 2008 18:08:09 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id DDC8050846; Wed, 6 Aug 2008 18:18:12 -0700 (PDT) Date: Wed, 06 Aug 2008 18:18:12 -0700 From: Eric Rescorla To: "Adam Langley" In-Reply-To: <396556a20808061742y19f8f5fh78fe66bfe4d415be@mail.gmail.com> References: <4890F4BE.6060302@isi.edu> <396556a20807301622l4cb33deuff73cd13d7a75ba1@mail.gmail.com> <4890FBE8.1020203@isi.edu> <396556a20807311700w1eda50b0o5da7ae52e6c1691a@mail.gmail.com> <48935FFD.4090805@isi.edu> <396556a20808051826w1a839577q956f379f56db1165@mail.gmail.com> <20080806020257.D1C69525D8F@kilo.rtfm.com> <396556a20808061742y19f8f5fh78fe66bfe4d415be@mail.gmail.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080807011812.DDC8050846@romeo.rtfm.com> Cc: tcpm@ietf.org, Joe Touch Subject: Re: [tcpm] tcp-auth-opt issue: support for NATs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At Wed, 6 Aug 2008 17:42:19 -0700, Adam Langley wrote: > > On Tue, Aug 5, 2008 at 7:02 PM, Eric Rescorla wrote: > > Isn't the whole point of the key-ids to avoid requiring this? > > Well, keyids would be required too. Here's how I see it working. > > Define a synchronisation range, R, say 1 minute. We require that the > maximum skew between two clocks is R. > > Define a key rotation timespan, T, say 1 minute. Let N be the maximum > number of keys that exist in a timespan of 2R. In our example, this is > two. > > Define a function K(master, t) that maps a timestamp to a key derived > from a master key and a keyid in [0, N). For example, F(master, t) = > SHA1(master + uint32be (t/T)) with keyid (t/T) `mod` N. > > At any time, a client transmits with key and keyid from F(master, > currentTime). At any time, the server accepts SYN signed with any > keyid and key in a span of 2R centered around the current time. > > So one can only connect if one's clock skew is acceptable and one > knows the master key. > > The keys for the resulting connection would be connection specific, > probably hashing in the SEQ/ACK numbers, other stuff etc. I'm sorry, I must be missing something. what problem are you trying to solve? -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 7 10:46:56 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1995D3A68CF; Thu, 7 Aug 2008 10:46:56 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88BF53A67F2 for ; Thu, 7 Aug 2008 10:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.683 X-Spam-Level: X-Spam-Status: No, score=-1.683 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gD-wHOF-aeZS for ; Thu, 7 Aug 2008 10:46:53 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id C04E33A67ED for ; Thu, 7 Aug 2008 10:46:53 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so481107wfd.31 for ; Thu, 07 Aug 2008 10:47:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=EUy6FnXHrmg43zaBNFssb08G7KnAem/K94k2eJEyh78=; b=Qh3aT2hcgepE04z4Z+ZilUUMMKuSOalOjilrf5iN2y5BpSiNz/XYZdwdWnLmVst2ns qs/jQ55bPVw1HiuA+obx281NVZ7VCunbSg7GfCOHFPs6R/j1hzWxJWOd3Fr2sDcJv/D/ 8LOIvL6pSe3G6wRxik2KTgIM9tW6IZ4rfoLgk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=Mb18ZxxChXWqwNU933pFNESMY1wR8DYGgOq4XHAgjI0tzVP05L4FDIkB7MGpv5LZQK 5/vSJ/9ZIV8oaNQoXymOTlZBt0gqMxkIpNpARgMuHLBanz6VQViTxWF8oJbRJFKkBq0+ biB5slBqqVXd7Tci7KrwT+VDtDrGOjuA5sOkY= Received: by 10.142.139.19 with SMTP id m19mr565885wfd.154.1218131250199; Thu, 07 Aug 2008 10:47:30 -0700 (PDT) Received: by 10.142.213.20 with HTTP; Thu, 7 Aug 2008 10:47:30 -0700 (PDT) Message-ID: <396556a20808071047q5bda8acbje7a8fc9f9bf2e597@mail.gmail.com> Date: Thu, 7 Aug 2008 10:47:30 -0700 From: "Adam Langley" To: "Eric Rescorla" In-Reply-To: <20080807011812.DDC8050846@romeo.rtfm.com> MIME-Version: 1.0 Content-Disposition: inline References: <4890F4BE.6060302@isi.edu> <396556a20807301622l4cb33deuff73cd13d7a75ba1@mail.gmail.com> <4890FBE8.1020203@isi.edu> <396556a20807311700w1eda50b0o5da7ae52e6c1691a@mail.gmail.com> <48935FFD.4090805@isi.edu> <396556a20808051826w1a839577q956f379f56db1165@mail.gmail.com> <20080806020257.D1C69525D8F@kilo.rtfm.com> <396556a20808061742y19f8f5fh78fe66bfe4d415be@mail.gmail.com> <20080807011812.DDC8050846@romeo.rtfm.com> X-Google-Sender-Auth: c48d81eeeeae52b7 Cc: tcpm@ietf.org, Joe Touch Subject: Re: [tcpm] tcp-auth-opt issue: support for NATs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Wed, Aug 6, 2008 at 6:18 PM, Eric Rescorla wrote: > I'm sorry, I must be missing something. what problem are you trying to > solve? The above was an sketch of how a passive open socket would work with TCP AO such that only clients that knew a master key could connect. If we wish to support a setup, then wildcard key matching would probably be needed. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 7 11:04:43 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F59B3A6C4B; Thu, 7 Aug 2008 11:04:43 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBA513A6C4B for ; Thu, 7 Aug 2008 11:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.674 X-Spam-Level: X-Spam-Status: No, score=-0.674 tagged_above=-999 required=5 tests=[AWL=-0.179, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFM-j9oGQVkA for ; Thu, 7 Aug 2008 11:04:41 -0700 (PDT) Received: from kilo.rtfm.com (unknown [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 2758C3A6ABC for ; Thu, 7 Aug 2008 11:04:41 -0700 (PDT) Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 77604529E4D; Thu, 7 Aug 2008 11:05:12 -0700 (PDT) Date: Thu, 07 Aug 2008 11:05:11 -0700 From: Eric Rescorla To: "Adam Langley" In-Reply-To: <396556a20808071047q5bda8acbje7a8fc9f9bf2e597@mail.gmail.com> References: <4890F4BE.6060302@isi.edu> <396556a20807301622l4cb33deuff73cd13d7a75ba1@mail.gmail.com> <4890FBE8.1020203@isi.edu> <396556a20807311700w1eda50b0o5da7ae52e6c1691a@mail.gmail.com> <48935FFD.4090805@isi.edu> <396556a20808051826w1a839577q956f379f56db1165@mail.gmail.com> <20080806020257.D1C69525D8F@kilo.rtfm.com> <396556a20808061742y19f8f5fh78fe66bfe4d415be@mail.gmail.com> <20080807011812.DDC8050846@romeo.rtfm.com> <396556a20808071047q5bda8acbje7a8fc9f9bf2e597@mail.gmail.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080807180512.77604529E4D@kilo.rtfm.com> Cc: tcpm@ietf.org, Joe Touch Subject: Re: [tcpm] tcp-auth-opt issue: support for NATs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At Thu, 7 Aug 2008 10:47:30 -0700, Adam Langley wrote: > > On Wed, Aug 6, 2008 at 6:18 PM, Eric Rescorla wrote: > > I'm sorry, I must be missing something. what problem are you trying to > > solve? > > The above was an sketch of how a passive open socket would work with > TCP AO such that only clients that knew a master key could connect. If > we wish to support a setup, then wildcard key matching would probably > be needed. Because the side doing the passive open doesn't know which client is connecting and it may have multiple instances of the same key-id? I don't understand the purpose of the time. Just do trial verifications with each key. -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 7 11:10:04 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30D493A6914; Thu, 7 Aug 2008 11:10:04 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E19773A6819 for ; Thu, 7 Aug 2008 11:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wf2O4xVMiZcH for ; Thu, 7 Aug 2008 11:10:03 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by core3.amsl.com (Postfix) with ESMTP id C6FF83A6914 for ; Thu, 7 Aug 2008 11:10:02 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 3so294156ywj.49 for ; Thu, 07 Aug 2008 11:10:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=dNMnyZxFF/sxrSEMJSBLyquxSlx49WIH+DLK4NujQk8=; b=nibsCwdViKU2CY8u66JNXdJDN7dynHQjF1Zf8D3LluZxrm4VYGmwCVZUiHL/ubhmMC fLbNXq4ps5Znd0a8VMjgg0dUox9uF/JlhmBts1ICG8CSnP4c1nkOBfibjMgCeqxGz3Ni WfqApo9wZug6lsxS5qI1dMHISR1jHW9wSYvzE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=hvsDzXHyl9T+0W1RwVkF4b2vW7SjPgDVWmnJp7a2DRr3mgJNT81HiUSavQo/MSNj7M bkJoocwDB7GPdYAeWp6u7wLjl/y9Y0UsiYqEzPGpLJTNdMxl+S6j0ziDhP9g+1/fnlXz N6sRD9sJkwpDF7PfmdnJIspQKe2Hoqa6T7lCc= Received: by 10.142.180.19 with SMTP id c19mr356383wff.263.1218132638520; Thu, 07 Aug 2008 11:10:38 -0700 (PDT) Received: by 10.142.213.20 with HTTP; Thu, 7 Aug 2008 11:10:38 -0700 (PDT) Message-ID: <396556a20808071110o5d45221fq4bea1ed4247f70ff@mail.gmail.com> Date: Thu, 7 Aug 2008 11:10:38 -0700 From: "Adam Langley" To: "Eric Rescorla" In-Reply-To: <20080807180512.77604529E4D@kilo.rtfm.com> MIME-Version: 1.0 Content-Disposition: inline References: <4890F4BE.6060302@isi.edu> <4890FBE8.1020203@isi.edu> <396556a20807311700w1eda50b0o5da7ae52e6c1691a@mail.gmail.com> <48935FFD.4090805@isi.edu> <396556a20808051826w1a839577q956f379f56db1165@mail.gmail.com> <20080806020257.D1C69525D8F@kilo.rtfm.com> <396556a20808061742y19f8f5fh78fe66bfe4d415be@mail.gmail.com> <20080807011812.DDC8050846@romeo.rtfm.com> <396556a20808071047q5bda8acbje7a8fc9f9bf2e597@mail.gmail.com> <20080807180512.77604529E4D@kilo.rtfm.com> X-Google-Sender-Auth: 0a47a6b02cd09ed3 Cc: tcpm@ietf.org, Joe Touch Subject: Re: [tcpm] tcp-auth-opt issue: support for NATs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Thu, Aug 7, 2008 at 11:05 AM, Eric Rescorla wrote: > Because the side doing the passive open doesn't know which client > is connecting and it may have multiple instances of the same key-id? > I don't understand the purpose of the time. Just do trial verifications > with each key. I don't believe that there should be multiple instances of the same keyid. This is for the situation where there is a shared key between the server and all valid clients. If we wished, we could fine that to be keyid 0, sign the packets and be done with it. But since the SEQ/ACK space isn't that large, and a replayed SYN could still be used to SYN flood a system, I sketched that system to rotate the keys based on time to limit the scope of replays. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 7 11:15:02 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCAAC3A69D4; Thu, 7 Aug 2008 11:15:02 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C16573A683E for ; Thu, 7 Aug 2008 11:15:01 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHt+H9MWNb1n for ; Thu, 7 Aug 2008 11:15:01 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 12C1A3A6899 for ; Thu, 7 Aug 2008 11:15:01 -0700 (PDT) Received: from [192.168.10.101] (auto-66.185.38.62.wirelessworld.vi [66.185.38.62]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m77IEoVC013999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Aug 2008 11:14:53 -0700 (PDT) Message-ID: <489B3B72.8030604@isi.edu> Date: Thu, 07 Aug 2008 11:14:10 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Eric Rescorla References: <4890F4BE.6060302@isi.edu> <396556a20807301622l4cb33deuff73cd13d7a75ba1@mail.gmail.com> <4890FBE8.1020203@isi.edu> <396556a20807311700w1eda50b0o5da7ae52e6c1691a@mail.gmail.com> <48935FFD.4090805@isi.edu> <396556a20808051826w1a839577q956f379f56db1165@mail.gmail.com> <20080806020257.D1C69525D8F@kilo.rtfm.com> <396556a20808061742y19f8f5fh78fe66bfe4d415be@mail.gmail.com> <20080807011812.DDC8050846@romeo.rtfm.com> <396556a20808071047q5bda8acbje7a8fc9f9bf2e597@mail.gmail.com> <20080807180512.77604529E4D@kilo.rtfm.com> In-Reply-To: <20080807180512.77604529E4D@kilo.rtfm.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Adam Langley , tcpm@ietf.org Subject: Re: [tcpm] tcp-auth-opt issue: support for NATs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Rescorla wrote: | At Thu, 7 Aug 2008 10:47:30 -0700, | Adam Langley wrote: |> On Wed, Aug 6, 2008 at 6:18 PM, Eric Rescorla wrote: |>> I'm sorry, I must be missing something. what problem are you trying to |>> solve? |> The above was an sketch of how a passive open socket would work with |> TCP AO such that only clients that knew a master key could connect. If |> we wish to support a setup, then wildcard key matching would probably |> be needed. | | Because the side doing the passive open doesn't know which client | is connecting and it may have multiple instances of the same key-id? | I don't understand the purpose of the time. Just do trial verifications | with each key. That's a reason we have a keyID, which, together with the socket pair, should exactly specify what key to use and avoids this sort of trial. If we can live with trials, we can remove the keyID and things align much better. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkibO3IACgkQE5f5cImnZrtOjgCdGj4dGeIrM9wBc6ydd6R0SV/h cLoAoN9+8nq6sKpwM0mYcWp6RVYb3YTp =2aDQ -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 7 11:19:48 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5036D3A6BF6; Thu, 7 Aug 2008 11:19:48 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E79C3A6C4B for ; Thu, 7 Aug 2008 11:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.671 X-Spam-Level: X-Spam-Status: No, score=-0.671 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJUv9A23813n for ; Thu, 7 Aug 2008 11:19:46 -0700 (PDT) Received: from kilo.rtfm.com (unknown [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 66DDB3A69D4 for ; Thu, 7 Aug 2008 11:19:28 -0700 (PDT) Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 04B5B52A03A; Thu, 7 Aug 2008 11:20:04 -0700 (PDT) Date: Thu, 07 Aug 2008 11:20:04 -0700 From: Eric Rescorla To: Joe Touch In-Reply-To: <489B3B72.8030604@isi.edu> References: <4890F4BE.6060302@isi.edu> <396556a20807301622l4cb33deuff73cd13d7a75ba1@mail.gmail.com> <4890FBE8.1020203@isi.edu> <396556a20807311700w1eda50b0o5da7ae52e6c1691a@mail.gmail.com> <48935FFD.4090805@isi.edu> <396556a20808051826w1a839577q956f379f56db1165@mail.gmail.com> <20080806020257.D1C69525D8F@kilo.rtfm.com> <396556a20808061742y19f8f5fh78fe66bfe4d415be@mail.gmail.com> <20080807011812.DDC8050846@romeo.rtfm.com> <396556a20808071047q5bda8acbje7a8fc9f9bf2e597@mail.gmail.com> <20080807180512.77604529E4D@kilo.rtfm.com> <489B3B72.8030604@isi.edu> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080807182005.04B5B52A03A@kilo.rtfm.com> Cc: Adam Langley , tcpm@ietf.org Subject: Re: [tcpm] tcp-auth-opt issue: support for NATs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At Thu, 07 Aug 2008 11:14:10 -0700, Joe Touch wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Eric Rescorla wrote: > | At Thu, 7 Aug 2008 10:47:30 -0700, > | Adam Langley wrote: > |> On Wed, Aug 6, 2008 at 6:18 PM, Eric Rescorla > wrote: > |>> I'm sorry, I must be missing something. what problem are you trying to > |>> solve? > |> The above was an sketch of how a passive open socket would work with > |> TCP AO such that only clients that knew a master key could connect. If > |> we wish to support a setup, then wildcard key matching would probably > |> be needed. > | > | Because the side doing the passive open doesn't know which client > | is connecting and it may have multiple instances of the same key-id? > | I don't understand the purpose of the time. Just do trial verifications > | with each key. > > That's a reason we have a keyID, which, together with the socket pair, > should exactly specify what key to use and avoids this sort of trial. If > we can live with trials, we can remove the keyID and things align much > better. Yes, but this only works if you either (1) know the address of peers in advance or (2) never assign the same key-id to two different peers. -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 7 11:20:59 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6D6D3A68C2; Thu, 7 Aug 2008 11:20:59 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A99B23A6899 for ; Thu, 7 Aug 2008 11:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.668 X-Spam-Level: X-Spam-Status: No, score=-0.668 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 459Dp51Ldpw1 for ; Thu, 7 Aug 2008 11:20:58 -0700 (PDT) Received: from kilo.rtfm.com (unknown [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id EA1023A68C2 for ; Thu, 7 Aug 2008 11:20:57 -0700 (PDT) Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 88C8552A06A; Thu, 7 Aug 2008 11:21:34 -0700 (PDT) Date: Thu, 07 Aug 2008 11:21:34 -0700 From: Eric Rescorla To: "Adam Langley" In-Reply-To: <396556a20808071110o5d45221fq4bea1ed4247f70ff@mail.gmail.com> References: <4890F4BE.6060302@isi.edu> <4890FBE8.1020203@isi.edu> <396556a20807311700w1eda50b0o5da7ae52e6c1691a@mail.gmail.com> <48935FFD.4090805@isi.edu> <396556a20808051826w1a839577q956f379f56db1165@mail.gmail.com> <20080806020257.D1C69525D8F@kilo.rtfm.com> <396556a20808061742y19f8f5fh78fe66bfe4d415be@mail.gmail.com> <20080807011812.DDC8050846@romeo.rtfm.com> <396556a20808071047q5bda8acbje7a8fc9f9bf2e597@mail.gmail.com> <20080807180512.77604529E4D@kilo.rtfm.com> <396556a20808071110o5d45221fq4bea1ed4247f70ff@mail.gmail.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080807182134.88C8552A06A@kilo.rtfm.com> Cc: tcpm@ietf.org, Joe Touch Subject: Re: [tcpm] tcp-auth-opt issue: support for NATs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At Thu, 7 Aug 2008 11:10:38 -0700, Adam Langley wrote: > > On Thu, Aug 7, 2008 at 11:05 AM, Eric Rescorla wrote: > > Because the side doing the passive open doesn't know which client > > is connecting and it may have multiple instances of the same key-id? > > I don't understand the purpose of the time. Just do trial verifications > > with each key. > > I don't believe that there should be multiple instances of the same > keyid. This is for the situation where there is a shared key between > the server and all valid clients. If we wished, we could fine that to > be keyid 0, sign the packets and be done with it. > > But since the SEQ/ACK space isn't that large, and a replayed SYN could > still be used to SYN flood a system, I sketched that system to rotate > the keys based on time to limit the scope of replays. Huh? You're worried about being SYN flooded by people with whom you share a trust relationship with? That doesn't seem particularly likely. -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 7 11:27:32 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0E7C28C1B7; Thu, 7 Aug 2008 11:27:32 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D43343A6899 for ; Thu, 7 Aug 2008 11:27:31 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJUCZGLCnhcn for ; Thu, 7 Aug 2008 11:27:31 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 211D33A69D4 for ; Thu, 7 Aug 2008 11:27:31 -0700 (PDT) Received: from [192.168.10.101] (auto-66.185.38.62.wirelessworld.vi [66.185.38.62]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m77IRghM018398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Aug 2008 11:27:45 -0700 (PDT) Message-ID: <489B3E76.7090808@isi.edu> Date: Thu, 07 Aug 2008 11:27:02 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Chandrashekhar Appanna References: <48971214.6070303@isi.edu> <20080804184552.GG29466@cisco.com> In-Reply-To: <20080804184552.GG29466@cisco.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] TCP-AO review comments. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chandrashekhar Appanna wrote: Just to clear up a potential point of confusion ... |> I think that "obsoletes" is correct. | | Not sure if this will obselete that.. this is a new option with different | goals AFAICT, this option has the same fundamental goal - transport layer protection of the transport protocol. TCP-AO has additional requirements that exceed TCP MD5, primarily (and arguably solely) to address inadequacies in TCP MD5. | and we are not even sure if at this point how much consensus there | is about moving AO forward.. there is much discussion on the keying aspects, | the design team seems to be just one person speaking up mostly; and | given the comments from other design team members at the mike at the ietf | I would not be in favour of making AO obselete the other method.. like you | say the status of the document has no power and therefore it is better | to not think it has some if it does not line up ;).. forcing a document | through without the implied working code and rough consensus may end up | doing more harm to the doc itself.. TCP MD5 uses a faulty hash and does not protect against replay attacks. IMO it is sufficiently faulty that it ought to be deprecated regardless of the state of a replacement. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkibPnYACgkQE5f5cImnZruHZQCg+RfoVQoJAiSmBOf475NN+dyA xgYAnjYGIIy1hXbwQM4k5hmKMPkDKV7B =GD9m -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 7 11:36:02 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D1C73A69AB; Thu, 7 Aug 2008 11:36:02 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 236E83A69AB for ; Thu, 7 Aug 2008 11:36:02 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1irX5fxY9f2 for ; Thu, 7 Aug 2008 11:36:01 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 4EFA73A6935 for ; Thu, 7 Aug 2008 11:36:01 -0700 (PDT) Received: from [192.168.10.101] (auto-66.185.38.62.wirelessworld.vi [66.185.38.62]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m77IaJws021503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Aug 2008 11:36:21 -0700 (PDT) Message-ID: <489B407A.6030001@isi.edu> Date: Thu, 07 Aug 2008 11:35:38 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Eric Rescorla References: <4890F4BE.6060302@isi.edu> <396556a20807301622l4cb33deuff73cd13d7a75ba1@mail.gmail.com> <4890FBE8.1020203@isi.edu> <396556a20807311700w1eda50b0o5da7ae52e6c1691a@mail.gmail.com> <48935FFD.4090805@isi.edu> <396556a20808051826w1a839577q956f379f56db1165@mail.gmail.com> <20080806020257.D1C69525D8F@kilo.rtfm.com> <396556a20808061742y19f8f5fh78fe66bfe4d415be@mail.gmail.com> <20080807011812.DDC8050846@romeo.rtfm.com> <396556a20808071047q5bda8acbje7a8fc9f9bf2e597@mail.gmail.com> <20080807180512.77604529E4D@kilo.rtfm.com> <489B3B72.8030604@isi.edu> <20080807182005.04B5B52A03A@kilo.rtfm.com> In-Reply-To: <20080807182005.04B5B52A03A@kilo.rtfm.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Adam Langley , tcpm@ietf.org Subject: Re: [tcpm] tcp-auth-opt issue: support for NATs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Rescorla wrote: ... |> | Because the side doing the passive open doesn't know which client |> | is connecting and it may have multiple instances of the same key-id? |> | I don't understand the purpose of the time. Just do trial verifications |> | with each key. |> |> That's a reason we have a keyID, which, together with the socket pair, |> should exactly specify what key to use and avoids this sort of trial. If |> we can live with trials, we can remove the keyID and things align much |> better. | | Yes, but this only works if you either (1) know the address of | peers in advance or (2) never assign the same key-id to two | different peers. If we require the socket pair, then the keyID need be unique only within a connection, and we should never need to test different keys -- even with key rollover, the key used should be deterministic. Supporting NATs can be done in two different ways: 1. require the KMS to determine the socket pair as received, and calculate the hash based on the as-received values this does not require testing different keys, but puts additional burden on the KMS 2. require a mode where the socket pair is not included in the MAC this will require testing different keys, it also requires the KMS install keys in certain ways (i.e., wildcarded on source port and dest IP addr, at least) I have not yet seen a reason to support secure transport connections for NAT'd devices made on this list. If there isn't, perhaps it'd be preferable to leave the protocol simpler and just not support NAT mode. Alternately, perhaps we could note that there could be modes where certain header fields are excluded, but that this would be described in a separeate extension - i.e., not in this doc. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkibQHoACgkQE5f5cImnZrsetwCeNaexL5o20oxq5ay5wT+oi1i2 D80AoKRr37bq5NPnsz+iKEBuD6OzFow6 =9ACi -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 7 11:38:29 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E148B28C0E0; Thu, 7 Aug 2008 11:38:29 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E6BB3A6A20 for ; Thu, 7 Aug 2008 11:38:29 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vo5A3o1BbzwQ for ; Thu, 7 Aug 2008 11:38:28 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id F25D73A6C09 for ; Thu, 7 Aug 2008 11:38:25 -0700 (PDT) Received: from [192.168.10.101] (auto-66.185.38.62.wirelessworld.vi [66.185.38.62]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m77IcT6u022353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Aug 2008 11:38:31 -0700 (PDT) Message-ID: <489B40FD.8070107@isi.edu> Date: Thu, 07 Aug 2008 11:37:49 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Caitlin Bestler References: <20080728042451.C7A174B7AD3@kilo.rtfm.com><20080730213253.B347F4D52E1@kilo.rtfm.com> <4890E9AE.3000607@isi.edu><20080731001609.6511C4D5E34@kilo.rtfm.com> <489175BD.6040201@isi.edu><396556a20807311010k78c22981xa0eebd1b46e9f619@mail.gmail.com><48935983.80701@isi.edu><3FBA635A-0473-4B58-86E2-C7523A35CE24@nokia.com><20080806133734.7721D527252@kilo.rtfm.com> <4899BD4A.9040509@isi.edu> <396556a20808060848g40df6251hf02467697ec44925@mail.gmail.com> <78C9135A3D2ECE4B8162EBDCE82CAD7704042099@nekter> In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD7704042099@nekter> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Adam Langley , tcpm@ietf.org Subject: Re: [tcpm] tcp-auth-opt issue: replay protection X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am hoping a TCP-AO implementation could be made in one of two localized places: a) localized to where existing TCP options are handled b) localized to a bump in the stack between TCP and IP Solutions that require modifying code throughout the TCP stack would be less useful than something that supports the above, AFAICT. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkibQP0ACgkQE5f5cImnZruvEgCg+8AA05TCxTkX2Ot31iNIkXrU 1hEAoMdKqQHWkcrv0WnGn0Pq3L9mFznY =lQco -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 7 11:42:20 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEE0D3A695D; Thu, 7 Aug 2008 11:42:20 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 437823A6922 for ; Thu, 7 Aug 2008 11:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.716 X-Spam-Level: X-Spam-Status: No, score=-1.716 tagged_above=-999 required=5 tests=[AWL=0.883, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAkn3TX3SSBi for ; Thu, 7 Aug 2008 11:42:18 -0700 (PDT) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 5A6723A695D for ; Thu, 7 Aug 2008 11:42:18 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 3A46750846; Thu, 7 Aug 2008 11:52:24 -0700 (PDT) Date: Thu, 07 Aug 2008 11:52:24 -0700 From: Eric Rescorla To: Joe Touch In-Reply-To: <489B407A.6030001@isi.edu> References: <4890F4BE.6060302@isi.edu> <396556a20807301622l4cb33deuff73cd13d7a75ba1@mail.gmail.com> <4890FBE8.1020203@isi.edu> <396556a20807311700w1eda50b0o5da7ae52e6c1691a@mail.gmail.com> <48935FFD.4090805@isi.edu> <396556a20808051826w1a839577q956f379f56db1165@mail.gmail.com> <20080806020257.D1C69525D8F@kilo.rtfm.com> <396556a20808061742y19f8f5fh78fe66bfe4d415be@mail.gmail.com> <20080807011812.DDC8050846@romeo.rtfm.com> <396556a20808071047q5bda8acbje7a8fc9f9bf2e597@mail.gmail.com> <20080807180512.77604529E4D@kilo.rtfm.com> <489B3B72.8030604@isi.edu> <20080807182005.04B5B52A03A@kilo.rtfm.com> <489B407A.6030001@isi.edu> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080807185224.3A46750846@romeo.rtfm.com> Cc: Adam Langley , tcpm@ietf.org Subject: Re: [tcpm] tcp-auth-opt issue: support for NATs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At Thu, 07 Aug 2008 11:35:38 -0700, Joe Touch wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Eric Rescorla wrote: > ... > |> | Because the side doing the passive open doesn't know which client > |> | is connecting and it may have multiple instances of the same key-id? > |> | I don't understand the purpose of the time. Just do trial verifications > |> | with each key. > |> > |> That's a reason we have a keyID, which, together with the socket pair, > |> should exactly specify what key to use and avoids this sort of trial. If > |> we can live with trials, we can remove the keyID and things align much > |> better. > | > | Yes, but this only works if you either (1) know the address of > | peers in advance or (2) never assign the same key-id to two > | different peers. > > > > If we require the socket pair, then the keyID need be unique only within > a connection, and we should never need to test different keys -- even > with key rollover, the key used should be deterministic. > > Supporting NATs can be done in two different ways: I think this is at least potentially an issue even aside from NAT. When I install keys on my host, you're proposing that I need to configure both the peer IP address and the key-id. This isn't necessarily bad, but it does mean that if (for instance) the other side decides to renumber, nothing will work absent manual reconfiguration. Is that something people want? -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 7 11:52:32 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB1B83A6803; Thu, 7 Aug 2008 11:52:32 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C59A73A6803 for ; Thu, 7 Aug 2008 11:52:31 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gmk8H5JtIe4R for ; Thu, 7 Aug 2008 11:52:30 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id CDAB43A67F2 for ; Thu, 7 Aug 2008 11:52:30 -0700 (PDT) Received: from [192.168.10.101] (auto-66.185.38.62.wirelessworld.vi [66.185.38.62]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m77IqEJO026633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Aug 2008 11:52:17 -0700 (PDT) Message-ID: <489B4436.1000807@isi.edu> Date: Thu, 07 Aug 2008 11:51:34 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Eric Rescorla References: <4890F4BE.6060302@isi.edu> <396556a20807301622l4cb33deuff73cd13d7a75ba1@mail.gmail.com> <4890FBE8.1020203@isi.edu> <396556a20807311700w1eda50b0o5da7ae52e6c1691a@mail.gmail.com> <48935FFD.4090805@isi.edu> <396556a20808051826w1a839577q956f379f56db1165@mail.gmail.com> <20080806020257.D1C69525D8F@kilo.rtfm.com> <396556a20808061742y19f8f5fh78fe66bfe4d415be@mail.gmail.com> <20080807011812.DDC8050846@romeo.rtfm.com> <396556a20808071047q5bda8acbje7a8fc9f9bf2e597@mail.gmail.com> <20080807180512.77604529E4D@kilo.rtfm.com> <489B3B72.8030604@isi.edu> <20080807182005.04B5B52A03A@kilo.rtfm.com> <489B407A.6030001@isi.edu> <20080807185224.3A46750846@romeo.rtfm.com> In-Reply-To: <20080807185224.3A46750846@romeo.rtfm.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Adam Langley , tcpm@ietf.org Subject: Re: [tcpm] tcp-auth-opt issue: support for NATs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Rescorla wrote: ... |> Supporting NATs can be done in two different ways: | | I think this is at least potentially an issue even aside from NAT. When | I install keys on my host, you're proposing that I need to configure | both the peer IP address and the key-id. This isn't necessarily | bad, but it does mean that if (for instance) the other side decides | to renumber, nothing will work absent manual reconfiguration. Is | that something people want? If we ignore source IP addresses, we probably end up needing to go through a set of possible keys when a SYN arrives. This seems like it amplifies the impact of a SYN attack - the more keys we have, the more each falsly-encrypted SYN costs. Alternately, a good KMS could figure out when these IP addresses changed, and update the TSAD accordingly. I would prefer this latter solution... Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkibRDYACgkQE5f5cImnZrv3owCdHWgFR98s/2T9Hkcp+kr9p/Sp mPQAnRjJWh2mK6g5xZGQ8IXct1VxD2FI =uDIB -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 7 12:08:16 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61D8A3A6847; Thu, 7 Aug 2008 12:08:16 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C64353A67EB for ; Thu, 7 Aug 2008 12:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5IaO7udxTxoG for ; Thu, 7 Aug 2008 12:08:15 -0700 (PDT) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 11E633A6358 for ; Thu, 7 Aug 2008 12:08:15 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id E539F50846; Thu, 7 Aug 2008 12:09:41 -0700 (PDT) Date: Thu, 07 Aug 2008 12:09:41 -0700 From: Eric Rescorla To: Joe Touch In-Reply-To: <489B4436.1000807@isi.edu> References: <4890F4BE.6060302@isi.edu> <396556a20807301622l4cb33deuff73cd13d7a75ba1@mail.gmail.com> <4890FBE8.1020203@isi.edu> <396556a20807311700w1eda50b0o5da7ae52e6c1691a@mail.gmail.com> <48935FFD.4090805@isi.edu> <396556a20808051826w1a839577q956f379f56db1165@mail.gmail.com> <20080806020257.D1C69525D8F@kilo.rtfm.com> <396556a20808061742y19f8f5fh78fe66bfe4d415be@mail.gmail.com> <20080807011812.DDC8050846@romeo.rtfm.com> <396556a20808071047q5bda8acbje7a8fc9f9bf2e597@mail.gmail.com> <20080807180512.77604529E4D@kilo.rtfm.com> <489B3B72.8030604@isi.edu> <20080807182005.04B5B52A03A@kilo.rtfm.com> <489B407A.6030001@isi.edu> <20080807185224.3A46750846@romeo.rtfm.com> <489B4436.1000807@isi.edu> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080807190941.E539F50846@romeo.rtfm.com> Cc: Adam Langley , tcpm@ietf.org Subject: Re: [tcpm] tcp-auth-opt issue: support for NATs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At Thu, 07 Aug 2008 11:51:34 -0700, Joe Touch wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Eric Rescorla wrote: > ... > |> Supporting NATs can be done in two different ways: > | > | I think this is at least potentially an issue even aside from NAT. When > | I install keys on my host, you're proposing that I need to configure > | both the peer IP address and the key-id. This isn't necessarily > | bad, but it does mean that if (for instance) the other side decides > | to renumber, nothing will work absent manual reconfiguration. Is > | that something people want? > > > If we ignore source IP addresses, we probably end up needing to go > through a set of possible keys when a SYN arrives. Well, not if you use unique key-ids. > This seems like it > amplifies the impact of a SYN attack - the more keys we have, the more > each falsly-encrypted SYN costs. Well, that's certainly true at some level, but if you use any randomness at all in key-id assignment, you would expect to have about N/256 key-ids where N is the number of keys. Unless N is very large, the number of duplicate key-ids is likely to be high enough that this doesn't seem like a very impressive attack, especially since the attacker can force you to compute a MAC with *every* packet he sends, not just SYNs. > Alternately, a good KMS could figure out when these IP addresses > changed, and update the TSAD accordingly. I would prefer this latter > solution... Yeah, but what does that say about manual key management, which is what we're going to have for the foreseeable future. -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 7 12:11:10 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 911FE3A6903; Thu, 7 Aug 2008 12:11:10 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 362F63A6908 for ; Thu, 7 Aug 2008 12:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XlTp1j0elC9t for ; Thu, 7 Aug 2008 12:11:08 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 6E3F33A6903 for ; Thu, 7 Aug 2008 12:11:05 -0700 (PDT) Received: from [192.168.10.101] (auto-66.185.38.62.wirelessworld.vi [66.185.38.62]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m77JAUv9002869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Aug 2008 12:10:32 -0700 (PDT) Message-ID: <489B487D.2060809@isi.edu> Date: Thu, 07 Aug 2008 12:09:49 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Eric Rescorla References: <4890F4BE.6060302@isi.edu> <396556a20807301622l4cb33deuff73cd13d7a75ba1@mail.gmail.com> <4890FBE8.1020203@isi.edu> <396556a20807311700w1eda50b0o5da7ae52e6c1691a@mail.gmail.com> <48935FFD.4090805@isi.edu> <396556a20808051826w1a839577q956f379f56db1165@mail.gmail.com> <20080806020257.D1C69525D8F@kilo.rtfm.com> <396556a20808061742y19f8f5fh78fe66bfe4d415be@mail.gmail.com> <20080807011812.DDC8050846@romeo.rtfm.com> <396556a20808071047q5bda8acbje7a8fc9f9bf2e597@mail.gmail.com> <20080807180512.77604529E4D@kilo.rtfm.com> <489B3B72.8030604@isi.edu> <20080807182005.04B5B52A03A@kilo.rtfm.com> <489B407A.6030001@isi.edu> <20080807185224.3A46750846@romeo.rtfm.com> <489B4436.1000807@isi.edu> <20080807190941.E539F50846@romeo.rtfm.com> In-Reply-To: <20080807190941.E539F50846@romeo.rtfm.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Adam Langley , tcpm@ietf.org Subject: Re: [tcpm] tcp-auth-opt issue: support for NATs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Eric, Eric Rescorla wrote: |> |> If we ignore source IP addresses, we probably end up needing to go |> through a set of possible keys when a SYN arrives. | | Well, not if you use unique key-ids. I've noted before that I don't think it's a good idea to assume cryptographic properties of fields in the header or option except for the MAC. Also, the size of the keyID space is fairly small as it is, and others have suggested it be even smaller (the few bits actually needed to rotate keys during a connection). |> This seems like it |> amplifies the impact of a SYN attack - the more keys we have, the more |> each falsly-encrypted SYN costs. | | Well, that's certainly true at some level, but if you use any | randomness at all in key-id assignment, you would expect to have | about N/256 key-ids where N is the number of keys. Unless N is | very large, the number of duplicate key-ids is likely to be high | enough that this doesn't seem like a very impressive attack, | especially since the attacker can force you to compute a MAC with | *every* packet he sends, not just SYNs. N could easily be fairly large, e.g., in peer-to-peer hubs. Note that this should be an issue only for SYNs; once a connection is made, the socket pair is already static (by TCP rules), so the appropriate key for that socket pair (thus determined during the SYN handling) can be installed - e.g., by a link. |> Alternately, a good KMS could figure out when these IP addresses |> changed, and update the TSAD accordingly. I would prefer this latter |> solution... | | Yeah, but what does that say about manual key management, which is what | we're going to have for the foreseeable future. It says that renumbering has consequences. Either you need to increase the burden on your key manager, or weaken your security (by increasing DOS impact, e.g.). If I have to pick one, I'd pick increasing the burden on the key manager in that case for *this* protocol. (where key manager could be a person). Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkibSH0ACgkQE5f5cImnZrs6wgCgxP+U0CK3E7vA9HAZDRjlQ5Oj rOQAoLqK5jf4FgmtP4a1ogla28JAMLNW =jjVL -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 7 12:18:44 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 859393A6819; Thu, 7 Aug 2008 12:18:44 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BC343A6359 for ; Thu, 7 Aug 2008 12:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.622 X-Spam-Level: X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFc801cJOME7 for ; Thu, 7 Aug 2008 12:18:42 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by core3.amsl.com (Postfix) with ESMTP id 50BBC3A6819 for ; Thu, 7 Aug 2008 12:18:42 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so536576rvf.49 for ; Thu, 07 Aug 2008 12:18:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=dAAVIQCbXbnnpw+b4yulM8NtcsMJK4fB/hFH2C71NGc=; b=RLt2G8TmyJhR9vO0iaPhwtSli9nTgec2KvTV2E2HP7LIuO9u6tQFJve1Il7voCWEMt kQNvEV7nzgjHf8UAAeu1UhuWTZw0s8fCIN+vFr/pCo7HWHZSrjem0SH/W9xHW/GIzsfk THUkfJ7/AjyD2boY/bdQVK4BXWhSEEIW9a4SA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=DQVvqwTls4GqY4/+XgFmvY4H9cSb/akaOrbV2yPFDKNy2Y6PpgVkPrEZ10EsFq6fCr 8WmcTeAclPK33Boy4BmNVXoNdUsOVxVw06+i1FCHuE51MZ1bgIP9+nuOmalSXEmRxni/ 21ahdh/Ji9lvals9j1G5F5ZsGlPiHXDTfjwkw= Received: by 10.140.166.21 with SMTP id o21mr875605rve.254.1218136720964; Thu, 07 Aug 2008 12:18:40 -0700 (PDT) Received: by 10.141.37.3 with HTTP; Thu, 7 Aug 2008 12:18:40 -0700 (PDT) Message-ID: <396556a20808071218t24c4375fma99d4f68f51f4757@mail.gmail.com> Date: Thu, 7 Aug 2008 12:18:40 -0700 From: "Adam Langley" To: "Eric Rescorla" In-Reply-To: <20080807182134.88C8552A06A@kilo.rtfm.com> MIME-Version: 1.0 Content-Disposition: inline References: <4890F4BE.6060302@isi.edu> <48935FFD.4090805@isi.edu> <396556a20808051826w1a839577q956f379f56db1165@mail.gmail.com> <20080806020257.D1C69525D8F@kilo.rtfm.com> <396556a20808061742y19f8f5fh78fe66bfe4d415be@mail.gmail.com> <20080807011812.DDC8050846@romeo.rtfm.com> <396556a20808071047q5bda8acbje7a8fc9f9bf2e597@mail.gmail.com> <20080807180512.77604529E4D@kilo.rtfm.com> <396556a20808071110o5d45221fq4bea1ed4247f70ff@mail.gmail.com> <20080807182134.88C8552A06A@kilo.rtfm.com> X-Google-Sender-Auth: b1a7f8af848406f6 Cc: tcpm@ietf.org, Joe Touch Subject: Re: [tcpm] tcp-auth-opt issue: support for NATs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Thu, Aug 7, 2008 at 11:21 AM, Eric Rescorla wrote: > Huh? You're worried about being SYN flooded by people with whom > you share a trust relationship with? That doesn't seem particularly > likely. I was assuming the attacking party would be replaying valid messages that they captured on the wire. While I'm thinking about the topic, I don't know where people are located, but yourself, Joe and anyone else interested is welcome to come to Google (SF or Mountain View) for a discussion on this. The IETF meetings would be the usual forum for such discussions, but I think that Joe wanted to get this moving faster than that. So, if it would be helpful, the offer stands. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 7 12:36:17 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 464893A6962; Thu, 7 Aug 2008 12:36:17 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A54633A6962 for ; Thu, 7 Aug 2008 12:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYs7ANK+LU0b for ; Thu, 7 Aug 2008 12:36:15 -0700 (PDT) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id EA01B3A688F for ; Thu, 7 Aug 2008 12:36:15 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 4921150846; Thu, 7 Aug 2008 12:45:45 -0700 (PDT) Date: Thu, 07 Aug 2008 12:45:45 -0700 From: Eric Rescorla To: Joe Touch In-Reply-To: <489B487D.2060809@isi.edu> References: <4890F4BE.6060302@isi.edu> <396556a20807301622l4cb33deuff73cd13d7a75ba1@mail.gmail.com> <4890FBE8.1020203@isi.edu> <396556a20807311700w1eda50b0o5da7ae52e6c1691a@mail.gmail.com> <48935FFD.4090805@isi.edu> <396556a20808051826w1a839577q956f379f56db1165@mail.gmail.com> <20080806020257.D1C69525D8F@kilo.rtfm.com> <396556a20808061742y19f8f5fh78fe66bfe4d415be@mail.gmail.com> <20080807011812.DDC8050846@romeo.rtfm.com> <396556a20808071047q5bda8acbje7a8fc9f9bf2e597@mail.gmail.com> <20080807180512.77604529E4D@kilo.rtfm.com> <489B3B72.8030604@isi.edu> <20080807182005.04B5B52A03A@kilo.rtfm.com> <489B407A.6030001@isi.edu> <20080807185224.3A46750846@romeo.rtfm.com> <489B4436.1000807@isi.edu> <20080807190941.E539F50846@romeo.rtfm.com> <489B487D.2060809@isi.edu> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080807194545.4921150846@romeo.rtfm.com> Cc: Adam Langley , tcpm@ietf.org Subject: Re: [tcpm] tcp-auth-opt issue: support for NATs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At Thu, 07 Aug 2008 12:09:49 -0700, Joe Touch wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, Eric, > > > > Eric Rescorla wrote: > |> > |> If we ignore source IP addresses, we probably end up needing to go > |> through a set of possible keys when a SYN arrives. > | > | Well, not if you use unique key-ids. > > I've noted before that I don't think it's a good idea to assume > cryptographic properties of fields in the header or option except for > the MAC. Well, I don't think of this as a cryptographic property. All that's required is a relatively even distribution of key-ids. They need not be secret. > | Well, that's certainly true at some level, but if you use any > | randomness at all in key-id assignment, you would expect to have > | about N/256 key-ids where N is the number of keys. Unless N is > | very large, the number of duplicate key-ids is likely to be high > | enough that this doesn't seem like a very impressive attack, > | especially since the attacker can force you to compute a MAC with > | *every* packet he sends, not just SYNs. > > N could easily be fairly large, e.g., in peer-to-peer hubs. Note that > this should be an issue only for SYNs; once a connection is made, the > socket pair is already static (by TCP rules), so the appropriate key for > that socket pair (thus determined during the SYN handling) can be > installed - e.g., by a link. That just removes the amplification angle. The attacker can still force the victim to do one MAC computation per transmitted packet. -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 7 12:39:06 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80B563A6996; Thu, 7 Aug 2008 12:39:06 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91F7A3A688F for ; Thu, 7 Aug 2008 12:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFN1bJEZR9NJ for ; Thu, 7 Aug 2008 12:39:05 -0700 (PDT) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 3969B3A6765 for ; Thu, 7 Aug 2008 12:37:40 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 9266C50846; Thu, 7 Aug 2008 12:47:09 -0700 (PDT) Date: Thu, 07 Aug 2008 12:47:09 -0700 From: Eric Rescorla To: "Adam Langley" In-Reply-To: <396556a20808071218t24c4375fma99d4f68f51f4757@mail.gmail.com> References: <4890F4BE.6060302@isi.edu> <48935FFD.4090805@isi.edu> <396556a20808051826w1a839577q956f379f56db1165@mail.gmail.com> <20080806020257.D1C69525D8F@kilo.rtfm.com> <396556a20808061742y19f8f5fh78fe66bfe4d415be@mail.gmail.com> <20080807011812.DDC8050846@romeo.rtfm.com> <396556a20808071047q5bda8acbje7a8fc9f9bf2e597@mail.gmail.com> <20080807180512.77604529E4D@kilo.rtfm.com> <396556a20808071110o5d45221fq4bea1ed4247f70ff@mail.gmail.com> <20080807182134.88C8552A06A@kilo.rtfm.com> <396556a20808071218t24c4375fma99d4f68f51f4757@mail.gmail.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080807194709.9266C50846@romeo.rtfm.com> Cc: tcpm@ietf.org, Joe Touch Subject: Re: [tcpm] tcp-auth-opt issue: support for NATs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At Thu, 7 Aug 2008 12:18:40 -0700, Adam Langley wrote: > > On Thu, Aug 7, 2008 at 11:21 AM, Eric Rescorla wrote: > > Huh? You're worried about being SYN flooded by people with whom > > you share a trust relationship with? That doesn't seem particularly > > likely. > > I was assuming the attacking party would be replaying valid messages > that they captured on the wire. Well, this isn't much of an attack, since the attacker can only create one SYN state for every individual connection initiation that it observes. How useful is that? -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 7 14:47:59 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E12663A6AA4; Thu, 7 Aug 2008 14:47:59 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 724883A67EB for ; Thu, 7 Aug 2008 14:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfyDet12eZef for ; Thu, 7 Aug 2008 14:47:57 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 624BA3A68C0 for ; Thu, 7 Aug 2008 14:47:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,322,1215388800"; d="scan'208";a="137187545" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 07 Aug 2008 21:47:57 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m77LlvY6002081; Thu, 7 Aug 2008 14:47:57 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m77LlvKF005905; Thu, 7 Aug 2008 21:47:57 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Aug 2008 14:47:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 7 Aug 2008 14:46:19 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5805984F7B@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <20080807185224.3A46750846@romeo.rtfm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] tcp-auth-opt issue: support for NATs Thread-Index: Acj4vXBFEKM/zXCAT3ePXvJtIbx7DwAGO5yg References: <4890F4BE.6060302@isi.edu><396556a20807301622l4cb33deuff73cd13d7a75ba1@mail.gmail.com><4890FBE8.1020203@isi.edu><396556a20807311700w1eda50b0o5da7ae52e6c1691a@mail.gmail.com><48935FFD.4090805@isi.edu><396556a20808051826w1a839577q956f379f56db1165@mail.gmail.com><20080806020257.D1C69525D8F@kilo.rtfm.com><396556a20808061742y19f8f5fh78fe66bfe4d415be@mail.gmail.com><20080807011812.DDC8050846@romeo.rtfm.com><396556a20808071047q5bda8acbje7a8fc9f9bf2e597@mail.gmail.com><20080807180512.77604529E4D@kilo.rtfm.com><489B3B72.8030604@isi.edu><20080807182005.04B5B52A03A@kilo.rtfm.com><489B407A.6030001@isi.edu> <20080807185224.3A46750846@romeo.rtfm.com> From: "Anantha Ramaiah (ananth)" To: "Eric Rescorla" , "Joe Touch" X-OriginalArrivalTime: 07 Aug 2008 21:47:57.0293 (UTC) FILETIME=[410A99D0:01C8F8D7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2659; t=1218145677; x=1219009677; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20 |Subject:=20RE=3A=20[tcpm]=20tcp-auth-opt=20issue=3A=20supp ort=20for=20NATs |Sender:=20; bh=F/9rPvDrXms3XiIWFMxlu2UowgqHymNJx8k4tgqKTno=; b=D419a4xqX4bigc0IQv3cTUJBz88+rPHnHVGUEgMC1wYaYtjfVqYpzwwF9X EkF1kVDYbt9mVUqIo2yr+izre7Efk21EVFJEXTItD+cPYeNxEiBWvNRysRmb 6ZYRR2IhNWkWcd/DrWlK9PJHlZeyWDiGbJZnUrswDvynNHA5wACCE=; Authentication-Results: sj-dkim-1; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Adam Langley , tcpm@ietf.org Subject: Re: [tcpm] tcp-auth-opt issue: support for NATs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org While we are at this subject ("supporting NAT's") did we answer the basic questions :- - Is this a mandatory? Since BGP, LDP and MSDP who are going to be major users of this option, NAT is not going to be in picture. - Ok, assume you are deciding to support NAT, where do you draw the line? Are you also talking about embedded IP addr in the payload (ALG)? Or we don't care? I haven't heard concrete responses (if any) to these above questions. Not meant to derail the crypto focus that is currently prevailing in this thread. -Anantha > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > Behalf Of Eric Rescorla > Sent: Thursday, August 07, 2008 11:52 AM > To: Joe Touch > Cc: Adam Langley; tcpm@ietf.org > Subject: Re: [tcpm] tcp-auth-opt issue: support for NATs > > At Thu, 07 Aug 2008 11:35:38 -0700, > Joe Touch wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > > > > > Eric Rescorla wrote: > > ... > > |> | Because the side doing the passive open doesn't know > which client > > |> | is connecting and it may have multiple instances of > the same key-id? > > |> | I don't understand the purpose of the time. Just do trial > > |> | verifications with each key. > > |> > > |> That's a reason we have a keyID, which, together with the socket > > |> pair, should exactly specify what key to use and avoids > this sort > > |> of trial. If we can live with trials, we can remove the > keyID and > > |> things align much better. > > | > > | Yes, but this only works if you either (1) know the > address of peers > > | in advance or (2) never assign the same key-id to two different > > | peers. > > > > > > > > If we require the socket pair, then the keyID need be unique only > > within a connection, and we should never need to test > different keys > > -- even with key rollover, the key used should be deterministic. > > > > Supporting NATs can be done in two different ways: > > I think this is at least potentially an issue even aside from > NAT. When I install keys on my host, you're proposing that I > need to configure both the peer IP address and the key-id. > This isn't necessarily bad, but it does mean that if (for > instance) the other side decides to renumber, nothing will > work absent manual reconfiguration. Is that something people want? > > -Ekr > _______________________________________________ > 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 From tcpm-bounces@ietf.org Thu Aug 7 18:46:27 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4DF53A6C5A; Thu, 7 Aug 2008 18:46:27 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4C833A68C0 for ; Thu, 7 Aug 2008 18:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OmfOe7p8Xk8 for ; Thu, 7 Aug 2008 18:46:25 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 1C8BC3A6C5A for ; Thu, 7 Aug 2008 18:46:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,323,1215388800"; d="scan'208";a="63053858" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 08 Aug 2008 01:46:25 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m781kPWD030387; Thu, 7 Aug 2008 18:46:25 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m781kOlx001626; Fri, 8 Aug 2008 01:46:24 GMT From: "Dan Wing" To: "'Eric Rescorla'" , "'Joe Touch'" References: <4890F4BE.6060302@isi.edu><396556a20807301622l4cb33deuff73cd13d7a75ba1@mail.gmail.com><4890FBE8.1020203@isi.edu><396556a20807311700w1eda50b0o5da7ae52e6c1691a@mail.gmail.com><48935FFD.4090805@isi.edu><396556a20808051826w1a839577q956f379f56db1165@mail.gmail.com><20080806020257.D1C69525D8F@kilo.rtfm.com><396556a20808061742y19f8f5fh78fe66bfe4d415be@mail.gmail.com><20080807011812.DDC8050846@romeo.rtfm.com><396556a20808071047q5bda8acbje7a8fc9f9bf2e597@mail.gmail.com><20080807180512.77604529E4D@kilo.rtfm.com><489B3B72.8030604@isi.edu><20080807182005.04B5B52A03A@kilo.rtfm.com><489B407A.6030001@isi.edu><20080807185224.3A46750846@romeo.rtfm.com><489B4436.1000807@isi.edu> <20080807190941.E539F50846@romeo.rtfm.com> Date: Thu, 7 Aug 2008 18:46:24 -0700 Message-ID: <21e501c8f8f8$91008f50$d35d150a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acj4wPZRNohPGFAHTeGyyW6YpNCsPwANsvZA In-Reply-To: <20080807190941.E539F50846@romeo.rtfm.com> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=819; t=1218159985; x=1219023985; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[tcpm]=20tcp-auth-opt=20issue=3A=20supp ort=20for=20NATs |Sender:=20; bh=rQwK5InbW30j0HqEO9Xws5Q7aVOb+mW9sk/Xu038Eec=; b=uAqC5RbXZczRjPuawTl9GKSke4/DlFlqsDco+L1oa2Xt3kS0VHimQtltEW N1/P+QwQLDAv20dSiGLQG8BCnZFgarivPwYEw6Cx+9u/b0PSqNwHRlLMHAUZ nxawVv91c8; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: 'Adam Langley' , tcpm@ietf.org Subject: Re: [tcpm] tcp-auth-opt issue: support for NATs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org > > Alternately, a good KMS could figure out when these IP addresses > > changed, and update the TSAD accordingly. I would prefer this latter > > solution... > > Yeah, but what does that say about manual key management, > which is what we're going to have for the foreseeable future. I agree with Eric. Using IP addresses as identifiers seems ill-advised now-a-days. Ignoring NATs, the same device can legitimately acquire different IP addresses throughout one day (roaming from wireless access point to wireless access point). It might be a reasonable optimization, or a useful additional security property, to require or to expect a key-id to come from the same IP address it came from last time -- but I don't think it should be necessary that the key-id come from the same IP address. -d _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 7 18:46:31 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA38228C1C3; Thu, 7 Aug 2008 18:46:31 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EDEF28C1C0 for ; Thu, 7 Aug 2008 18:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqipX6QvQyMM for ; Thu, 7 Aug 2008 18:46:29 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 416DC28C1C4 for ; Thu, 7 Aug 2008 18:46:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,323,1215388800"; d="scan'208";a="73383797" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 08 Aug 2008 01:46:29 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m781kTrt008128; Thu, 7 Aug 2008 18:46:29 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m781kSK5008397; Fri, 8 Aug 2008 01:46:28 GMT From: "Dan Wing" To: "'Anantha Ramaiah \(ananth\)'" , "'Eric Rescorla'" , "'Joe Touch'" References: <4890F4BE.6060302@isi.edu><396556a20807301622l4cb33deuff73cd13d7a75ba1@mail.gmail.com><4890FBE8.1020203@isi.edu><396556a20807311700w1eda50b0o5da7ae52e6c1691a@mail.gmail.com><48935FFD.4090805@isi.edu><396556a20808051826w1a839577q956f379f56db1165@mail.gmail.com><20080806020257.D1C69525D8F@kilo.rtfm.com><396556a20808061742y19f8f5fh78fe66bfe4d415be@mail.gmail.com><20080807011812.DDC8050846@romeo.rtfm.com><396556a20808071047q5bda8acbje7a8fc9f9bf2e597@mail.gmail.com><20080807180512.77604529E4D@kilo.rtfm.com><489B3B72.8030604@isi.edu><20080807182005.04B5B52A03A@kilo.rtfm.com><489B407A.6030001@isi.edu><20080807185224.3A46750846@romeo.rtfm.com> <0C53DCFB700D144284A584F54711EC5805984F7B@xmb-sjc-21c.amer.cisco.com> Date: Thu, 7 Aug 2008 18:46:28 -0700 Message-ID: <21e601c8f8f8$936ef740$d35d150a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acj4vXBFEKM/zXCAT3ePXvJtIbx7DwAGO5ygAAhHswA= In-Reply-To: <0C53DCFB700D144284A584F54711EC5805984F7B@xmb-sjc-21c.amer.cisco.com> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3602; t=1218159989; x=1219023989; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[tcpm]=20tcp-auth-opt=20issue=3A=20supp ort=20for=20NATs |Sender:=20; bh=Nkz2D7Xwy3YwV9uwGKbevHXdw5FsIFvtBcj2fPyRHKU=; b=Nn6V5TqTrFrghGIjRGmk4Y4h5RHSNTydp1oDSsXfUjK4gngLT/revpDiXH KbOWzSuVGwXFLn710Fc0wVCaKEqLw0LuhM/QCW7uQCQwyRyDmt0muqydkKB8 13C9m+uXey; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: 'Adam Langley' , tcpm@ietf.org Subject: Re: [tcpm] tcp-auth-opt issue: support for NATs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > Behalf Of Anantha Ramaiah (ananth) > Sent: Thursday, August 07, 2008 2:46 PM > To: Eric Rescorla; Joe Touch > Cc: Adam Langley; tcpm@ietf.org > Subject: Re: [tcpm] tcp-auth-opt issue: support for NATs > > > While we are at this subject ("supporting NAT's") did we answer the > basic questions :- > > - Is this a mandatory? Since BGP, LDP and MSDP who are going > to be major users of this option, NAT is not going to be in picture. Those are going to be the major consumers now, but if we aren't able to keep ahead of various out-of-window TCP attacks, it would be reasonable for other applications to want to use TCP AO. I believe a TLS-over-TCP connection can be destroyed with a bogus in-window packet; preventing such an attack with TCP AO would be valuable if such attacks become easier in the future. > - Ok, assume you are deciding to support NAT, where do you draw the > line? Are you also talking about embedded IP addr in the > payload (ALG)? Or we don't care? No ALGs. -d > I haven't heard concrete responses (if any) to these above questions. > Not meant to derail the crypto focus that is currently prevailing in > this thread. > > -Anantha > > > -----Original Message----- > > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > > Behalf Of Eric Rescorla > > Sent: Thursday, August 07, 2008 11:52 AM > > To: Joe Touch > > Cc: Adam Langley; tcpm@ietf.org > > Subject: Re: [tcpm] tcp-auth-opt issue: support for NATs > > > > At Thu, 07 Aug 2008 11:35:38 -0700, > > Joe Touch wrote: > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > > > > > > > Eric Rescorla wrote: > > > ... > > > |> | Because the side doing the passive open doesn't know > > which client > > > |> | is connecting and it may have multiple instances of > > the same key-id? > > > |> | I don't understand the purpose of the time. Just do trial > > > |> | verifications with each key. > > > |> > > > |> That's a reason we have a keyID, which, together with > the socket > > > |> pair, should exactly specify what key to use and avoids > > this sort > > > |> of trial. If we can live with trials, we can remove the > > keyID and > > > |> things align much better. > > > | > > > | Yes, but this only works if you either (1) know the > > address of peers > > > | in advance or (2) never assign the same key-id to two different > > > | peers. > > > > > > > > > > > > If we require the socket pair, then the keyID need be unique only > > > within a connection, and we should never need to test > > different keys > > > -- even with key rollover, the key used should be deterministic. > > > > > > Supporting NATs can be done in two different ways: > > > > I think this is at least potentially an issue even aside from > > NAT. When I install keys on my host, you're proposing that I > > need to configure both the peer IP address and the key-id. > > This isn't necessarily bad, but it does mean that if (for > > instance) the other side decides to renumber, nothing will > > work absent manual reconfiguration. Is that something people want? > > > > -Ekr > > _______________________________________________ > > 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 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Aug 8 10:32:42 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEA8B3A6D59; Fri, 8 Aug 2008 10:32:42 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C86453A6D52 for ; Fri, 8 Aug 2008 10:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSiENxqdJw50 for ; Fri, 8 Aug 2008 10:32:41 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 554123A6D58 for ; Fri, 8 Aug 2008 10:32:35 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP; Fri, 08 Aug 2008 10:32:31 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 10:32:24 -0700 Received: from antipi.jnpr.net ([10.10.2.34]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 10:32:24 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by antipi.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 13:32:23 -0400 Received: from [172.28.13.57] ([172.28.13.57] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 13:32:22 -0400 Message-ID: <489C8323.70605@juniper.net> Date: Fri, 08 Aug 2008 13:32:19 -0400 From: Ron Bonica User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Eric Rescorla References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488DD77D.9070608@isi.edu> <20080728144721.AC9184B905A@kilo.rtfm.com> <488DE021.7070307@isi.edu> <20080728164013.422D14B9600@kilo.rtfm.com> <20080730213253.B347F4D52E1@kilo.rtfm.com> <4890E9AE.3000607@isi.edu> <20080731001609.6511C4D5E34@kilo.rtfm.com> <489175BD.6040201@isi.edu> <396556a20807311010k78c22981xa0eebd1b46e9f619@mail.gmail.com> <48935983.80701@isi.edu> <3FBA635A-0473-4B58-86E2-C7523A35CE24@nokia.com> <20080806133734.7721D527252@kilo.rtfm.com> In-Reply-To: <20080806133734.7721D527252@kilo.rtfm.com> X-Enigmail-Version: 0.95.6 X-OriginalArrivalTime: 08 Aug 2008 17:32:22.0894 (UTC) FILETIME=[B770C0E0:01C8F97C] Cc: Adam Langley , tcpm@ietf.org, ext Joe Touch Subject: Re: [tcpm] tcp-auth-opt issue: replay protection X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Eric Rescorla wrote: > At Wed, 6 Aug 2008 14:32:02 +0300, > Lars Eggert wrote: >> On 2008-8-1, at 21:44, ext Joe Touch wrote: >>> IMO: retransmitted packets would use the currently active keyID >>> (even if >>> different from what was previously transmitted). >> I agree. TCP retransmits previous data, not previous segments. > > I agree it should be permissible to use the new key-id, but > should it be required? I think that implementations SHOULD use the new key, but MAY use the old one, too. Either should work, so long as the receiving system doesn't delete the old key too quickly after having obsoleted it. Ron _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Aug 8 10:39:20 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0DF23A6CF7; Fri, 8 Aug 2008 10:39:19 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA13E3A6CF7 for ; Fri, 8 Aug 2008 10:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGqIwuNfafqq for ; Fri, 8 Aug 2008 10:39:18 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id 8BD673A6CA2 for ; Fri, 8 Aug 2008 10:38:24 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP; Fri, 08 Aug 2008 10:38:22 PDT Received: from pi-smtp.jnpr.net ([10.10.2.36]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 10:37:37 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 8 Aug 2008 13:37:36 -0400 Received: from [172.28.13.57] ([172.28.13.57] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 13:37:36 -0400 Message-ID: <489C845D.90500@juniper.net> Date: Fri, 08 Aug 2008 13:37:33 -0400 From: Ron Bonica User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Caitlin Bestler References: <0C53DCFB700D144284A584F54711EC58058C2FD4@xmb-sjc-21c.amer.cisco.com> <48939933.3030601@isi.edu> <4899AE0C.6080206@asomi.com> In-Reply-To: <4899AE0C.6080206@asomi.com> X-Enigmail-Version: 0.95.6 X-OriginalArrivalTime: 08 Aug 2008 17:37:36.0536 (UTC) FILETIME=[7262B980:01C8F97D] Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , ext Joe Touch Subject: Re: [tcpm] TCP-AO review comments. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org > > Basically, this is an application layer problem being foisted upon > the transport layer. It creates unneeded clutter at the transport > layer that is not of general utility. > Caitlin, I disagree. TCP-AO protects against some classes of attack against the TCP control plane. These attacks cannot be addressed at the application layer. For example, there is nothing that can be done at the application layer to protect against the insertion of an empty TCP segment with the reset bit set. TCP-AO protects against this. Ron _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Aug 10 02:38:04 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8F9C3A6982; Sun, 10 Aug 2008 02:38:04 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DA6C3A68AF for ; Sun, 10 Aug 2008 02:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PeLHznnSqHMw for ; Sun, 10 Aug 2008 02:38:02 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.104]) by core3.amsl.com (Postfix) with ESMTP id 3ED563A6982 for ; Sun, 10 Aug 2008 02:38:01 -0700 (PDT) Received: from mx-av-03.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-05.forthnet.gr (8.14.3/8.14.3) with ESMTP id m7A9bo8w011385; Sun, 10 Aug 2008 12:37:50 +0300 Received: from MX-IN-05.forthnet.gr (mx-in-05.forthnet.gr [193.92.150.32]) by mx-av-03.forthnet.gr (8.14.3/8.14.3) with ESMTP id m7A9bogQ030838; Sun, 10 Aug 2008 12:37:50 +0300 Received: from hell.hell.gr (adsl69-188.lsf.forthnet.gr [79.103.196.188]) by MX-IN-05.forthnet.gr (8.14.3/8.14.3) with ESMTP id m7A9blsD002269; Sun, 10 Aug 2008 12:37:48 +0300 Authentication-Results: MX-IN-05.forthnet.gr smtp.mail=v13@v13.gr; spf=neutral Authentication-Results: MX-IN-05.forthnet.gr header.from=v13@v13.gr; sender-id=neutral From: Stefanos Harhalakis To: tcpm@ietf.org Date: Sun, 10 Aug 2008 12:37:46 +0300 User-Agent: KMail/1.9.9 References: <0C53DCFB700D144284A584F54711EC58058C2FD4@xmb-sjc-21c.amer.cisco.com> <48939933.3030601@isi.edu> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808101237.46574.v13@v13.gr> Cc: "Anantha Ramaiah \(ananth\)" , ext Joe Touch Subject: Re: [tcpm] TCP-AO review comments. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: base64 Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org T24gV2VkbmVzZGF5IDA2IEF1Z3VzdCAyMDA4LCBMYXJzIEVnZ2VydCB3cm90ZToKPiBTbywgbXkg Y3VycmVudCB0aGlua2luZyBpcyB0aGF0IEFPIHNob3VsZCBtYXliZSBtb3ZlIFRDUC1NRDUgdG8K PiAiaGlzdG9yaWMiLiBUaGF0IHdvdWxkIGluZGljYXRlIHRoYXQgbmV3IGltcGxlbWVudGF0aW9u cyBzaG91bGRuJ3QKPiBpbXBsZW1lbnQgVENQLU1ENSBhbmQgZXhpc3Rpbmcgb25lcyBhcmUgZW5j b3VyYWdlZCB0byBtb3ZlIGF3YXkgZnJvbQo+IGl0LiBCdXQgdGhpcyBpc24ndCBhIGNsZWFyIC1j dXQgY2FzZS4gQ29tbWVudHM/CgpJTUhPLCAic2hvdWxkbid0IGltcGxlbWVudCIgaW4gdGhlIGFi b3ZlIHBocmFzZSBzaG91bGQgYmUgY2hhbmdlZCAKdG8gInNob3VsZG4ndCB1c2UiLiBGb3IgYmFj a3dhcmRzIGNvbXBhdGliaWxpdHkgcmVhc29ucyBpbXBsZW1lbnRhdGlvbnMgbWF5IAoob3Igc2hv dWxkKSAoYW5kIG1vc3QgcHJvYmFibHkgd2lsbCkgaW1wbGVtZW50IFRDUC1NRDUgdG9vLgoKPiBh bmQgVENQLU1ENS4gQU8gaXMgYSByZXBsYWNlbWVudCBmb3IgVENQLU1ENSwgYnV0IGl0IGlzbid0 IGEgc2ltcGxlIKAKPiByZXZpc2lvbiBvciBleHRlbnNpb24gb2YgVENQLU1ENSwgaXQncyBhIG5l dyBtZWNoYW5pc20gdG8gcHJvdmlkZSCgCj4gc2ltaWxhciBmdW5jdGlvbmFsaXR5IGluIGEgKHNs aWdodGx5KSBkaWZmZXJlbnQgd2F5LgoKRm9sbG93aW5nIHlvdXIgdGhvdWdodHM6IFNpbmNlIFRD UC1BTyBpcyBtdXR1YWxseSBleGNsdXNpdmUgd2l0aCBUQ1AtTUQ1LCBvbmUgCmNhbm5vdCB2aWV3 IHRoZW0gYXMgdHdvIGRpc3RpbmN0IG9wdGlvbnMuIFRoaXMgbWVhbnMgdGhhdCBUQ1AtQU8gaXMg YWN0dWFsbHkgCmEgcmVwbGFjZW1lbnQgb2YgVENQLU1ENSBhbmQgd2UgY2FuIGFsc28gZGVzY3Jp YmUgaXQgYXMgYSAnbmV3ZXIsIApiYWNrd2FyZHMtaW5jb21wYXRpYmxlIHZlcnNpb24nIG9mIHRo ZSBleGlzdGluZyBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20gb2YgClRDUC4gSGF2aW5nIHRoaXMg aW4gbWluZCwgcGVyaGFwcyAnb2Jzb2xldGVzJyBpcyBjb3JyZWN0LgoKQWxzbywgaXMgdGhlcmUg YW55IGdvb2QgaW4gaW5jbHVkaW5nIGEgKDEtYnl0ZSAtIG9yIHNtYWxsZXIgd2l0aCBzb21lIHVu dXNlZCAKYml0cykgdmVyc2lvbiBmaWVsZCBpbiBUQ1AtQU8/IFRoaXMgd2lsbCBoZWxwIHNpbWls YXIgZnV0dXJlIApleHRlbnNpb25zL3JlcGxhY2VtZW50cyBhbmQgd2lsbCBhbHNvIGFsbG93IGZv ciBlYXNpZXIgYXV0aGVudGljYXRpb24gb3B0aW9uIApoYW5kc2hha2luZyBieSBmYWxsaW5nIGJh Y2sgdG8gdGhlIGhpZ2hlc3QgY29tbW9ubHkgc3VwcG9ydGVkIG1ldGhvZC4KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KdGNwbSBtYWlsaW5nIGxpc3QKdGNw bUBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG0K From tcpm-bounces@ietf.org Sun Aug 10 04:12:33 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 424083A68F2; Sun, 10 Aug 2008 04:12:33 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E33973A6DD1 for ; Sun, 10 Aug 2008 04:12:31 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3NgCQMHNh0o for ; Sun, 10 Aug 2008 04:12:31 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 1F7233A68F2 for ; Sun, 10 Aug 2008 04:12:31 -0700 (PDT) Received: from [75.193.28.133] (133.sub-75-193-28.myvzw.com [75.193.28.133]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m7ABBuul024553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 10 Aug 2008 04:12:03 -0700 (PDT) Message-ID: <489ECCD2.9010608@isi.edu> Date: Sun, 10 Aug 2008 04:11:14 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Stefanos Harhalakis References: <0C53DCFB700D144284A584F54711EC58058C2FD4@xmb-sjc-21c.amer.cisco.com> <48939933.3030601@isi.edu> <200808101237.46574.v13@v13.gr> In-Reply-To: <200808101237.46574.v13@v13.gr> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] TCP-AO review comments. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stefanos Harhalakis wrote: ... | Also, is there any good in including a (1-byte - or smaller with some unused | bits) version field in TCP-AO? This will help similar future | extensions/replacements and will also allow for easier authentication option | handshaking by falling back to the highest commonly supported method. Options don't typically have version numbers; they're implicit in the option KIND itself. IMO, that's why TCP-AO is requesting a new KIND value. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiezNIACgkQE5f5cImnZruxEgCfTexydjMG154rrCc7BiuG5NsM 06EAni11kV39sqN/ni9c7spixnFKGN2a =xCV2 -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Aug 10 04:21:20 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06C3F3A6B49; Sun, 10 Aug 2008 04:21:20 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADDCD3A6B49 for ; Sun, 10 Aug 2008 04:21:19 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0R2AMAcLuG0 for ; Sun, 10 Aug 2008 04:21:18 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id E1FE23A68F2 for ; Sun, 10 Aug 2008 04:21:18 -0700 (PDT) Received: from [75.193.28.133] (133.sub-75-193-28.myvzw.com [75.193.28.133]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m7ABKSls026873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 10 Aug 2008 04:20:36 -0700 (PDT) Message-ID: <489ECED3.8020108@isi.edu> Date: Sun, 10 Aug 2008 04:19:47 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Ron Bonica References: <0C53DCFB700D144284A584F54711EC58058C2FD4@xmb-sjc-21c.amer.cisco.com> <48939933.3030601@isi.edu> <4899AE0C.6080206@asomi.com> <489C845D.90500@juniper.net> In-Reply-To: <489C845D.90500@juniper.net> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] TCP-AO review comments. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ron (et al.) Ron Bonica wrote: | |> |> Basically, this is an application layer problem being foisted upon |> the transport layer. It creates unneeded clutter at the transport |> layer that is not of general utility. |> | | Caitlin, | | I disagree. TCP-AO protects against some classes of attack against the | TCP control plane. These attacks cannot be addressed at the application | layer. FWIW, I think Caitlin is referring to BGPs assumption that TCP connectivity implies network connectivity, i.e., when a BGP TCP connection is dropped, the routes should be removed immediately. I agree with her that this is an application layer problem (IMO, an application layer making invalid assumptions). That doesn't prevent the need for a transport layer protection for transport connections (as you note below). There's utility in protecting invested TCP state - e.g., large window sizes, or pending transfers - from attackers, even when applications use TCP appropriately. Joe | For example, there is nothing that can be done at the application layer | to protect against the insertion of an empty TCP segment with the reset | bit set. TCP-AO protects against this. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkieztMACgkQE5f5cImnZrvunQCgwjoDJepuINA6y1wReDmFlGDq EBAAoMMeSbP+lPKhlyp1VG9+8tdfFaI/ =vnB5 -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Aug 10 05:07:48 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05BD83A6DBB; Sun, 10 Aug 2008 05:07:48 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3E233A68D7 for ; Sun, 10 Aug 2008 05:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWPePxG2T2Zn for ; Sun, 10 Aug 2008 05:07:46 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.104]) by core3.amsl.com (Postfix) with ESMTP id AE9873A6B13 for ; Sun, 10 Aug 2008 05:07:45 -0700 (PDT) Received: from mx-av-05.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-01.forthnet.gr (8.14.3/8.14.3) with ESMTP id m7AC7jK8006537; Sun, 10 Aug 2008 15:07:45 +0300 Received: from MX-IN-01.forthnet.gr (mx-in-01.forthnet.gr [193.92.150.23]) by mx-av-05.forthnet.gr (8.14.3/8.14.3) with ESMTP id m7AC7j35027974; Sun, 10 Aug 2008 15:07:45 +0300 Received: from hell.hell.gr (adsl69-188.lsf.forthnet.gr [79.103.196.188]) by MX-IN-01.forthnet.gr (8.14.3/8.14.3) with ESMTP id m7AC7aJx032430; Sun, 10 Aug 2008 15:07:37 +0300 Authentication-Results: MX-IN-01.forthnet.gr smtp.mail=v13@v13.gr; spf=neutral Authentication-Results: MX-IN-01.forthnet.gr header.from=v13@v13.gr; sender-id=neutral From: Stefanos Harhalakis To: Joe Touch Date: Sun, 10 Aug 2008 15:07:35 +0300 User-Agent: KMail/1.9.9 References: <0C53DCFB700D144284A584F54711EC58058C2FD4@xmb-sjc-21c.amer.cisco.com> <200808101237.46574.v13@v13.gr> <489ECCD2.9010608@isi.edu> In-Reply-To: <489ECCD2.9010608@isi.edu> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808101507.35830.v13@v13.gr> Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] TCP-AO review comments. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Sunday 10 August 2008, Joe Touch wrote: > Stefanos Harhalakis wrote: > | Also, is there any good in including a (1-byte - or smaller with some > | unused > | bits) version field in TCP-AO? This will help similar future > | extensions/replacements and will also allow for easier authentication > | option > | handshaking by falling back to the highest commonly supported method. > > > Options don't typically have version numbers; they're implicit in the > option KIND itself. IMO, that's why TCP-AO is requesting a new KIND value. Agreed, but since this is a 'group of options' that exclude each other, a kind of initial handshake is inevitable. As far as I see it, even with just TCP-MD5 and TCP-AO there is an initial handshake problem for deciding which one of them both ends support (no?). Practically this makes the transition from MD5 to AO a hard issue. Considering this, in the future (lets say in 5 years) another such option 'upgrade' won't be feasible. Of course a new KIND is required for TCP-AO but I believe that this should be the last one for the "series" of TCP authentication options. In fact, this may not be considered as a different 'KIND' of options, unless the SYN-senter negotiations all authentication options and the SYN-receiver selects the best that it supports. Since this isn't possible with limited TCP options space and SYN-cookies issues, something different is required (versioning). Do you see another (better) long-term solution? _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Aug 10 18:50:19 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 492C83A6B28; Sun, 10 Aug 2008 18:50:19 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E51A73A6B22 for ; Sun, 10 Aug 2008 18:50:17 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utv7PIcaapbi for ; Sun, 10 Aug 2008 18:50:16 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id D542A3A6B16 for ; Sun, 10 Aug 2008 18:50:16 -0700 (PDT) Received: from [75.211.31.157] (157.sub-75-211-31.myvzw.com [75.211.31.157]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m7B1nn4S019516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 10 Aug 2008 18:49:56 -0700 (PDT) Message-ID: <489F9A94.9080205@isi.edu> Date: Sun, 10 Aug 2008 18:49:08 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Stefanos Harhalakis References: <0C53DCFB700D144284A584F54711EC58058C2FD4@xmb-sjc-21c.amer.cisco.com> <200808101237.46574.v13@v13.gr> <489ECCD2.9010608@isi.edu> <200808101507.35830.v13@v13.gr> In-Reply-To: <200808101507.35830.v13@v13.gr> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] TCP-AO review comments. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stefanos Harhalakis wrote: | On Sunday 10 August 2008, Joe Touch wrote: |> Stefanos Harhalakis wrote: |> | Also, is there any good in including a (1-byte - or smaller with some |> | unused |> | bits) version field in TCP-AO? This will help similar future |> | extensions/replacements and will also allow for easier authentication |> | option |> | handshaking by falling back to the highest commonly supported method. |> |> |> Options don't typically have version numbers; they're implicit in the |> option KIND itself. IMO, that's why TCP-AO is requesting a new KIND value. | | Agreed, but since this is a 'group of options' that exclude each other, a kind | of initial handshake is inevitable. Handshakes in this case aren't meaningful. | As far as I see it, even with just | TCP-MD5 and TCP-AO there is an initial handshake problem for deciding which | one of them both ends support (no?). Once a packet contains a TCP MD5 header, it MUST be authenticated using that option, regardless of other options - thus it is irrelevant to have alternative options present. That rule basically prevents negotiation of the TCP MD5 option, or 'escalating' it into TCP-AO. | Practically this makes the transition | from MD5 to AO a hard issue. TCP MD5 made this impossible. TCP-AO permits 'optional' use, i.e., that the option can be present or ignored on an individual connection, which may enable future negotiation among a variety of authentication alternatives. ... | Of course a new KIND is required for TCP-AO but I believe that this should be | the last one for the "series" of TCP authentication options. TCP-AO is intended to be sufficiently general - e.g., by the use of a MAC field which is defined on a per connection basis - that future updates should not be needed for a long time. That said, there are plenty of KIND values left if we consume one every 10 years for this purpose... | In fact, this | may not be considered as a different 'KIND' of options, unless the SYN-senter | negotiations all authentication options and the SYN-receiver selects the best | that it supports. Since this isn't possible with limited TCP options space | and SYN-cookies issues, something different is required (versioning). | | Do you see another (better) long-term solution? Overall, since they keys and parameters need to be configured on a per-endpoint-pair basis anyway, IMO this sort of handshake ought to occur in the KMS, not in TCP. TCP's SYN option space is insufficient to contain multiple authentication fields, AFAICT, in addition to the other fields currently commonly in use. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkifmoIACgkQE5f5cImnZrsH2gCg0tmFJkBO7pkeFJsjvXctAwrD eAYAniIRWYRX8S30PghaBIn40GGV2K5z =Z5Ky -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Aug 11 10:24:17 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 149693A6AFD; Mon, 11 Aug 2008 10:24:17 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F4013A6C12 for ; Mon, 11 Aug 2008 10:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.74 X-Spam-Level: X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jglR9y4x-f+9 for ; Mon, 11 Aug 2008 10:24:15 -0700 (PDT) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id B1F133A6AFD for ; Mon, 11 Aug 2008 10:24:15 -0700 (PDT) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id E7C68328195 for ; Mon, 11 Aug 2008 12:24:13 -0500 (CDT) Received: from ndjsxgw04.ndc.nasa.gov (ndjsxgw04.ndc.nasa.gov [129.166.32.112]) by ndjsppt02.ndc.nasa.gov (8.14.1/8.14.1) with ESMTP id m7BHODH3000324 for ; Mon, 11 Aug 2008 12:24:13 -0500 Received: from NDJSEVS25A.ndc.nasa.gov ([129.166.32.124]) by ndjsxgw04.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Aug 2008 12:24:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 11 Aug 2008 12:24:13 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: working group last call for 4138bis F-RTO draft Thread-Index: Acjo5h3Mv8FI5arLQFu7JG25qsK6igS8H+JQ From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" To: "Eddy, Wesley M. (GRC-RCN0)[VZ]" , X-OriginalArrivalTime: 11 Aug 2008 17:24:14.0007 (UTC) FILETIME=[1347C470:01C8FBD7] Subject: Re: [tcpm] working group last call for 4138bis F-RTO draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org >-----Original Message----- >From: Eddy, Wesley M. (GRC-RCN0)[VZ] >Sent: Friday, July 18, 2008 10:54 AM > >At a prior meeting, it was determined that the F-RTO >draft was ready for working group last call. We >would like to start the WGLC on the recent update: > >http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc4138bis-02.txt > >This will last until August 8, because of the Dublin >meeting falling in the middle of the WGLC. The last call for 4138bis has ended, and I didn't see any negative blocking comments. Markku presented on the draft in Dublin, and there were also no objections there. I'll plan to write a shepherd PROTO for it and send to the IESG. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Aug 11 10:35:42 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B72FC3A6C62; Mon, 11 Aug 2008 10:35:42 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F5AA3A6C62 for ; Mon, 11 Aug 2008 10:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXmrdXRBpQlJ for ; Mon, 11 Aug 2008 10:35:40 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by core3.amsl.com (Postfix) with ESMTP id 85ED13A6D0B for ; Mon, 11 Aug 2008 10:35:40 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so1945306rvf.49 for ; Mon, 11 Aug 2008 10:35:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:mime-version:content-type:content-transfer-encoding :content-disposition:x-google-sender-auth; bh=eacL9mf8bf3jfLZtWvybowp2cn98Q4XTmEndmSLcsnQ=; b=pT/1eljFHQHgai619tJNm69+u5mOy9fHPNn1eqAuRo8QK2Fp3+NG+lTtWv6Pim4yyu fYNpld4lbccmKLV35bRqMQC0VzaVqqgIHycEIOwdtGLdqZqNm+kdjk5a7427JPocZqBx gOoJ2JE2WsYAi+qpuRRzGSuMbrgZ12hf2nLrM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=t4QjpTnKm2rliIVZZU29SANK+DCg6MFYTtiaqzH2lJnoUVSQ0IOsZiMoM9qtfEjYIB 9w2veTs7DhTYAub3HreLpkSlqXhQT0K2+GIK5S6GDQFRtYQDfYA7tKThKxImid/Ddu/V yO92isf0y2C77Gq+NmOuCWeBJKpqFT4v9yrbo= Received: by 10.141.23.7 with SMTP id a7mr3676975rvj.58.1218476120878; Mon, 11 Aug 2008 10:35:20 -0700 (PDT) Received: by 10.141.37.3 with HTTP; Mon, 11 Aug 2008 10:35:20 -0700 (PDT) Message-ID: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> Date: Mon, 11 Aug 2008 10:35:20 -0700 From: "Adam Langley" To: tcpm@ietf.org MIME-Version: 1.0 Content-Disposition: inline X-Google-Sender-Auth: 170cee7f43e382f8 Subject: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org The comments on SYNACK Payloads[1] seem to have died down, so I'd like to see how people are feeling about it. Just to be clear; I'm seeking to publish this as experimental in order to get an option number assigned to conduct more widespread tests. I thought that I would dig out a couple of the points that I believe Joe Touch was still unsure about after the last thread. I don't wish to misrepresent anyone, but it is a long thread to dig through: thanks to Joe for being so generous with his time in giving feedback. > I appreciate the > idea of optimizing TCP, but there are so many other places where RTTs > are not under your control, and so many RTTs in a connection, that > removing (or adding) a single one anywhere seems in the noise." Many Google users are now using search bars to submit queries. Thus they type into a text field in the browser, hit enter and the browser makes a connection, sends the query encoded in a GET and displays the result. This is one example of a situation where the connection latency isn't amortised. There are many others, but obviously, this is the example that usually dominates my thinking. And, in this situation, it turns out that every 10ms makes a difference. I might be wrong here. This might be an overcomplex solution. But I think only time will tell, which is why I wish to have it published as an experimental spec. If, in a couple of years, it doesn't work the option number can be released, ready for the next guy. > Using a transport signal to change the application protocol seems > very strange to me. Other's can comment on that. It is strange, I agree. My usual test about such things is if I get an "ick" reaction and, in this case, I don't. Although, that might just be me. Two reasonable questions arise: "Where will this stop?" - obviously, the TCP option space shouldn't be a repository for application data. In this case, at least, the option is advertising a certain minimum capability of the TCP stack, as defined in the draft. Also, I'll claim that this is the last such need in this area: The SYNACK payload sizes is a decision for the server (within the advertised window). No more client options could be needed to advertise support for larger ones. Since the SYNACK payload is (nearly) constant, and TCP stacks are not going to differ sufficiently to change this in the next 20 years, applications don't gain anything else by stuffing anything more in the SYN option space. So I don't think this sets an unreasonable precedent. Thanks all, [1] http://www.ietf.org/internet-drafts/draft-agl-tcpm-sadata-01.txt AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Aug 11 11:19:25 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CE5E3A6D81; Mon, 11 Aug 2008 11:19:25 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AAF53A6D78 for ; Mon, 11 Aug 2008 11:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9uaJ2qSqd6H for ; Mon, 11 Aug 2008 11:19:23 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 5CB6C3A6D23 for ; Mon, 11 Aug 2008 11:19:15 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP; Mon, 11 Aug 2008 11:19:09 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Aug 2008 11:19:06 -0700 Received: from pi-smtp.jnpr.net ([10.10.2.36]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Aug 2008 11:19:05 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 11 Aug 2008 14:19:04 -0400 Received: from [172.28.13.44] ([172.28.13.44] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Aug 2008 14:19:04 -0400 Message-ID: <48A08295.8090903@juniper.net> Date: Mon, 11 Aug 2008 14:19:01 -0400 From: Ron Bonica User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Joe Touch References: <4890F4BE.6060302@isi.edu> <396556a20807301622l4cb33deuff73cd13d7a75ba1@mail.gmail.com> <4890FBE8.1020203@isi.edu> <396556a20807311700w1eda50b0o5da7ae52e6c1691a@mail.gmail.com> <48935FFD.4090805@isi.edu> <396556a20808051826w1a839577q956f379f56db1165@mail.gmail.com> <20080806020257.D1C69525D8F@kilo.rtfm.com> <396556a20808061742y19f8f5fh78fe66bfe4d415be@mail.gmail.com> <20080807011812.DDC8050846@romeo.rtfm.com> <396556a20808071047q5bda8acbje7a8fc9f9bf2e597@mail.gmail.com> <20080807180512.77604529E4D@kilo.rtfm.com> <489B3B72.8030604@isi.edu> In-Reply-To: <489B3B72.8030604@isi.edu> X-Enigmail-Version: 0.95.6 X-OriginalArrivalTime: 11 Aug 2008 18:19:04.0173 (UTC) FILETIME=[BC5F41D0:01C8FBDE] Cc: Adam Langley , tcpm@ietf.org Subject: Re: [tcpm] tcp-auth-opt issue: support for NATs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org > That's a reason we have a keyID, which, together with the socket pair, > should exactly specify what key to use and avoids this sort of trial. Amen! If > we can live with trials, we can remove the keyID and things align much > better. > But we can't! Ron _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Aug 11 11:32:05 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54FCE3A69EE; Mon, 11 Aug 2008 11:32:05 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C62B73A6801 for ; Mon, 11 Aug 2008 11:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YY+7i7MyA072 for ; Mon, 11 Aug 2008 11:32:03 -0700 (PDT) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 481CB3A69CA for ; Mon, 11 Aug 2008 11:31:42 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id B300B50846; Mon, 11 Aug 2008 11:42:14 -0700 (PDT) Date: Mon, 11 Aug 2008 11:42:14 -0700 From: Eric Rescorla To: Ron Bonica In-Reply-To: <48A08295.8090903@juniper.net> References: <4890F4BE.6060302@isi.edu> <396556a20807301622l4cb33deuff73cd13d7a75ba1@mail.gmail.com> <4890FBE8.1020203@isi.edu> <396556a20807311700w1eda50b0o5da7ae52e6c1691a@mail.gmail.com> <48935FFD.4090805@isi.edu> <396556a20808051826w1a839577q956f379f56db1165@mail.gmail.com> <20080806020257.D1C69525D8F@kilo.rtfm.com> <396556a20808061742y19f8f5fh78fe66bfe4d415be@mail.gmail.com> <20080807011812.DDC8050846@romeo.rtfm.com> <396556a20808071047q5bda8acbje7a8fc9f9bf2e597@mail.gmail.com> <20080807180512.77604529E4D@kilo.rtfm.com> <489B3B72.8030604@isi.edu> <48A08295.8090903@juniper.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080811184214.B300B50846@romeo.rtfm.com> Cc: Adam Langley , tcpm@ietf.org, Joe Touch Subject: Re: [tcpm] tcp-auth-opt issue: support for NATs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At Mon, 11 Aug 2008 14:19:01 -0400, Ron Bonica wrote: > > > > That's a reason we have a keyID, which, together with the socket pair, > > should exactly specify what key to use and avoids this sort of trial. > > Amen! > > If > > we can live with trials, we can remove the keyID and things align much > > better. > > > > But we can't! If we can't ever have trial authentication than there must be a unique key for each (key-id, remote addr) pair. As a practical matter, this implies either that: - Key-ids must be globally unique. - You need to know the other side's IP address, even if you're doing a passive open. -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Aug 11 12:32:56 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6F0D3A6D11; Mon, 11 Aug 2008 12:32:56 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 279E63A6C33 for ; Mon, 11 Aug 2008 12:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GleQrTsvUuZ6 for ; Mon, 11 Aug 2008 12:32:54 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 283C93A6D23 for ; Mon, 11 Aug 2008 12:32:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,190,1217808000"; d="scan'208";a="64130053" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 11 Aug 2008 19:32:41 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m7BJWfdg029840; Mon, 11 Aug 2008 12:32:41 -0700 Received: from dwingwxp01 (dhcp-171-70-217-35.cisco.com [171.70.217.35]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m7BJWf1F016196; Mon, 11 Aug 2008 19:32:41 GMT From: "Dan Wing" To: "'Eric Rescorla'" , "'Ron Bonica'" References: <4890F4BE.6060302@isi.edu><396556a20807301622l4cb33deuff73cd13d7a75ba1@mail.gmail.com><4890FBE8.1020203@isi.edu><396556a20807311700w1eda50b0o5da7ae52e6c1691a@mail.gmail.com><48935FFD.4090805@isi.edu><396556a20808051826w1a839577q956f379f56db1165@mail.gmail.com><20080806020257.D1C69525D8F@kilo.rtfm.com><396556a20808061742y19f8f5fh78fe66bfe4d415be@mail.gmail.com><20080807011812.DDC8050846@romeo.rtfm.com><396556a20808071047q5bda8acbje7a8fc9f9bf2e597@mail.gmail.com><20080807180512.77604529E4D@kilo.rtfm.com><489B3B72.8030604@isi.edu> <48A08295.8090903@juniper.net> <20080811184214.B300B50846@romeo.rtfm.com> Date: Mon, 11 Aug 2008 12:32:41 -0700 Message-ID: <03d901c8fbe9$05673220$23d946ab@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20080811184214.B300B50846@romeo.rtfm.com> X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acj74KY41cicHo6WSamkTFjpBn6uRgAB/y4A DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1095; t=1218483161; x=1219347161; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[tcpm]=20tcp-auth-opt=20issue=3A=20supp ort=20for=20NATs |Sender:=20; bh=PEKt4+xr2G/+caAToFhHGxMIIW1X9PaLz7bFdnrjaGg=; b=mfqpjYn3kIUaJjrcIdIVmNf0bWDxFu4/HMg8+YhR7XHtLdfT7GAPEI/h5t 2N9JHgaUi3SFY1XrxKsQdyletBPAum3jhB33qqEBf1vhFGLwREVS3FozSSSE LQ8wIDdZQY; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: 'Adam Langley' , tcpm@ietf.org, 'Joe Touch' Subject: Re: [tcpm] tcp-auth-opt issue: support for NATs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org > At Mon, 11 Aug 2008 14:19:01 -0400, > Ron Bonica wrote: > > > > > > > That's a reason we have a keyID, which, together with the > socket pair, > > > should exactly specify what key to use and avoids this > sort of trial. > > > > Amen! > > > > If > > > we can live with trials, we can remove the keyID and > things align much > > > better. > > > > > > > But we can't! > > If we can't ever have trial authentication than there must be a unique > key for each (key-id, remote addr) pair. As a practical matter, > this implies either that: > > - Key-ids must be globally unique. > - You need to know the other side's IP address, even if you're doing > a passive open. Adding 32 bits to the key-id would create the same global uniqueness that using the source IPv4 addresses accomplishes. But it's only necessary to have a globally unique key-id when a new connection arrives: after that, you can use the source IP address and TCP port. A reasonable optimization could involve using a shorter key-id after the TCP session is established. -d _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Aug 11 15:03:22 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2588B3A68E1; Mon, 11 Aug 2008 15:03:22 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 145B73A6A86 for ; Mon, 11 Aug 2008 15:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-bUR62ymkai for ; Mon, 11 Aug 2008 15:03:19 -0700 (PDT) Received: from cgpmail.ua.pt (frontend-2.servers.ua.pt [193.136.173.3]) by core3.amsl.com (Postfix) with ESMTP id 3DC943A67B6 for ; Mon, 11 Aug 2008 15:03:14 -0700 (PDT) Received: from [85.241.162.156] (account etfreire@ua.pt HELO portsfreire) by frontend-2.cgpmail.ua.pt (CommuniGate Pro SMTP 5.1.13) with ESMTPSA id 156997623; Mon, 11 Aug 2008 23:03:16 +0100 From: "Sergio Freire" To: "'Adam Langley'" , References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> In-Reply-To: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> Date: Mon, 11 Aug 2008 23:03:14 +0100 Message-ID: <000001c8fbfe$0dba0960$292e1c20$@pt> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acj72LsQrIgG/NbgReiGMVDojGq13AAInuOQ Content-Language: pt Cc: andre.zuquete@ua.pt Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Hi Adam et all, I have been on vacations but I have the thread of emails concerning this subject. We would like also to propose something about this as Joe Touch mentioned earlier. Me and Andre Z=FAquete have published a paper for proposing a TCP-layer name service. http://www.usenix.org/events/usenix08/tech/full_papers/freire/freire.pdf In this work we "propose" the use of data in the SYN/SYN+ACK segments. We intend to generalize this and also to go forward on this matter. I have to see carefully the thread of your earlier discussions and your draft as of the current version, so we can see if we're going in the same or in opposite/alternative directions. Meanwhile, if you can take a look at our work, it would be great for further discussion (regarding the way of extending tcp options and not the name service itself). Note: I think this is an important subject and I'm glad we're pushing this forward, even if we propose alternate ways for this. Please give me some days so I can synch. Regards, Sergio Freire -----Original Message----- From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Adam Langley Sent: segunda-feira, 11 de Agosto de 2008 18:35 To: tcpm@ietf.org Subject: [tcpm] SYN/ACK Payloads, draft 01 The comments on SYNACK Payloads[1] seem to have died down, so I'd like to see how people are feeling about it. Just to be clear; I'm seeking to publish this as experimental in order to get an option number assigned to conduct more widespread tests. I thought that I would dig out a couple of the points that I believe Joe Touch was still unsure about after the last thread. I don't wish to misrepresent anyone, but it is a long thread to dig through: thanks to Joe for being so generous with his time in giving feedback. > I appreciate the > idea of optimizing TCP, but there are so many other places where RTTs > are not under your control, and so many RTTs in a connection, that > removing (or adding) a single one anywhere seems in the noise." Many Google users are now using search bars to submit queries. Thus they type into a text field in the browser, hit enter and the browser makes a connection, sends the query encoded in a GET and displays the result. This is one example of a situation where the connection latency isn't amortised. There are many others, but obviously, this is the example that usually dominates my thinking. And, in this situation, it turns out that every 10ms makes a difference. I might be wrong here. This might be an overcomplex solution. But I think only time will tell, which is why I wish to have it published as an experimental spec. If, in a couple of years, it doesn't work the option number can be released, ready for the next guy. > Using a transport signal to change the application protocol seems > very strange to me. Other's can comment on that. It is strange, I agree. My usual test about such things is if I get an "ick" reaction and, in this case, I don't. Although, that might just be me. Two reasonable questions arise: "Where will this stop?" - obviously, the TCP option space shouldn't be a repository for application data. In this case, at least, the option is advertising a certain minimum capability of the TCP stack, as defined in the draft. Also, I'll claim that this is the last such need in this area: The SYNACK payload sizes is a decision for the server (within the advertised window). No more client options could be needed to advertise support for larger ones. Since the SYNACK payload is (nearly) constant, and TCP stacks are not going to differ sufficiently to change this in the next 20 years, applications don't gain anything else by stuffing anything more in the SYN option space. So I don't think this sets an unreasonable precedent. Thanks all, [1] http://www.ietf.org/internet-drafts/draft-agl-tcpm-sadata-01.txt AGL -- = Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ 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 From tcpm-bounces@ietf.org Mon Aug 11 16:17:29 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87C593A6DA4; Mon, 11 Aug 2008 16:17:29 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CC0B3A68D6 for ; Mon, 11 Aug 2008 16:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHO5WD3KGLp0 for ; Mon, 11 Aug 2008 16:17:27 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by core3.amsl.com (Postfix) with ESMTP id 694213A6DA4 for ; Mon, 11 Aug 2008 16:17:27 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so2049899rvf.49 for ; Mon, 11 Aug 2008 16:17:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=q2ygw9GPKoQFCRtURP+RS9bddjG9I7QniAhFTURsOXU=; b=Vc2mN2ixn9Ifgu73En0+dU0xXXMdNKbfCc9DJZJ+DcZ3//V25GPKu8JEh0rqxMVjoH h23fUpzRMNDpMHadV3H1g+mHyTna8hhLgDBg+B3xobl2p4k6oJ0kUggkG6QHSmIK9Syr sKbsjdnpICNyAw/yCuJlejKV/8KzEHwI4ggBU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=NoAg9RVA/AcsnGGAghkD4eA2FkKpt2W5EAZVmcpH3GiHQDb6DZvoxXcwe7WNXTvPNo ZS5a7TEnJp1RPEd7uwgLSSL7Y+nH7sfHgBgpAe3806XppCDw4I+JIRKU4mVXzpEZOuXz j2xJQAMMmAYISYQ4WEgxteIBbu84BOQSIYd+Y= Received: by 10.140.247.11 with SMTP id u11mr3913059rvh.37.1218496628129; Mon, 11 Aug 2008 16:17:08 -0700 (PDT) Received: by 10.141.37.3 with HTTP; Mon, 11 Aug 2008 16:17:08 -0700 (PDT) Message-ID: <396556a20808111617n622aceabn62db0d55b25ae712@mail.gmail.com> Date: Mon, 11 Aug 2008 16:17:08 -0700 From: "Adam Langley" To: "Sergio Freire" In-Reply-To: <000001c8fbfe$0dba0960$292e1c20$@pt> MIME-Version: 1.0 Content-Disposition: inline References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <000001c8fbfe$0dba0960$292e1c20$@pt> X-Google-Sender-Auth: c8acd33672f28841 Cc: andre.zuquete@ua.pt, tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Mon, Aug 11, 2008 at 3:03 PM, Sergio Freire wrote: > Meanwhile, if you can take a look at our work, it would be great for further > discussion (regarding the way of extending tcp options and not the name > service itself). Somehow I've already read your paper, although don't have any idea where I got the pointer from! A few questions: There's no legacy mode for active opens because the port name mode is singled with a destination port number of 0, right? You're taking the option number 0x45 for your length indicator. Lars pointed out to me a few months ago that 254 and 255 are assigned for this if you're using it over real networks. Assuming that a SYN frame is sent to port 0, requesting a named TCP service which the destination knows about: what's the source port number of the resulting SYN/ACK? I think I'm reading that it's chosen randomly. >From the table in 3.3 it doesn't appear that there's any SYNACK payload, is that correct? It's unfortunate that there's no way for clients to gradually start using such a scheme, but you can't extend the option space in SYNs and, if you used non-0 destination ports, some hosts may enqueue the payload. In short, if my understanding is correct, I don't believe these two schemes interfere, even on a single connection. Are you intending on trying to get an option number assigned for this? Cheers AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Aug 11 16:47:40 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FC983A6912; Mon, 11 Aug 2008 16:47:40 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40D3D3A6912 for ; Mon, 11 Aug 2008 16:47:39 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id saseVp0f7M36 for ; Mon, 11 Aug 2008 16:47:38 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 87FF93A6888 for ; Mon, 11 Aug 2008 16:47:38 -0700 (PDT) Received: from zod.isi.edu (zod.isi.edu [128.9.168.221]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m7BNkS4g002053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Aug 2008 16:46:29 -0700 (PDT) Received: (from faber@localhost) by zod.isi.edu (8.14.2/8.14.2/Submit) id m7BNkQVs016540; Mon, 11 Aug 2008 16:46:26 -0700 (PDT) (envelope-from faber) Date: Mon, 11 Aug 2008 16:46:26 -0700 From: Ted Faber To: Dan Wing Message-ID: <20080811234626.GB2194@zod.isi.edu> References: <48A08295.8090903@juniper.net> <20080811184214.B300B50846@romeo.rtfm.com> <03d901c8fbe9$05673220$23d946ab@cisco.com> Mime-Version: 1.0 In-Reply-To: <03d901c8fbe9$05673220$23d946ab@cisco.com> User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@zod.isi.edu Cc: 'Adam Langley' , tcpm@ietf.org, 'Joe Touch' Subject: Re: [tcpm] tcp-auth-opt issue: support for NATs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0552474954==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0552474954== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gj572EiMnwbLXET9" Content-Disposition: inline --gj572EiMnwbLXET9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 11, 2008 at 12:32:41PM -0700, Dan Wing wrote: > > - Key-ids must be globally unique. > > - You need to know the other side's IP address, even if you're doing > > a passive open. >=20 > Adding 32 bits to the key-id would create the same global uniqueness > that using the source IPv4 addresses accomplishes. There's a little more to a establishing a global namespace than allocating the bits. Using the IP address is capitalizing on the IP address allocation authorities and routing systems to keep those addresses unique at any given time (and "unique" is somewhat approximate even with those mechanisms). One can establish a global namespace here if needed, but there's more to do than allocate the field space. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --gj572EiMnwbLXET9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkigz1IACgkQaUz3f+Zf+XtJSQCgxnpkNNKw46wkv9DDXrdlCfHN 6FAAnAvhb+jDUO8lkTztC13ciAiPqYoX =Hx8H -----END PGP SIGNATURE----- --gj572EiMnwbLXET9-- --===============0552474954== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============0552474954==-- From tcpm-bounces@ietf.org Mon Aug 11 18:54:18 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA3BA3A6A56; Mon, 11 Aug 2008 18:54:18 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B895D3A68FD for ; Mon, 11 Aug 2008 18:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZfCR3gz5ZUa for ; Mon, 11 Aug 2008 18:54:16 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id C067A3A6A56 for ; Mon, 11 Aug 2008 18:54:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,192,1217808000"; d="scan'208";a="40981202" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 12 Aug 2008 01:53:55 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m7C1rs9w001436; Mon, 11 Aug 2008 18:53:54 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m7C1rsRT004548; Tue, 12 Aug 2008 01:53:54 GMT From: "Dan Wing" To: "'Ted Faber'" References: <48A08295.8090903@juniper.net> <20080811184214.B300B50846@romeo.rtfm.com> <03d901c8fbe9$05673220$23d946ab@cisco.com> <20080811234626.GB2194@zod.isi.edu> Date: Mon, 11 Aug 2008 18:53:54 -0700 Message-ID: <017201c8fc1e$4700c3b0$23d946ab@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20080811234626.GB2194@zod.isi.edu> Thread-Index: Acj8DKUc3ggvx5PxRsalStwpTZct6AAEXOgA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1356; t=1218506035; x=1219370035; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[tcpm]=20tcp-auth-opt=20issue=3A=20supp ort=20for=20NATs |Sender:=20; bh=6/JWJCJA0LmSgBJtE6fpP3b89yL3BBH66uXKg5bKyrw=; b=ANebQDR7jfudhvy+thcpW/f90vH8hDzxGQ1UPl0rIHGZ40XAHdEeKXK9xJ XxtBGrZ+dCHb+gKwoICI2inGABZF/m3SkmVI6zcxj7Vl8KP1tXrIFR++crKq gHWz5qTLem; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: 'Adam Langley' , tcpm@ietf.org, 'Joe Touch' Subject: Re: [tcpm] tcp-auth-opt issue: support for NATs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org > -----Original Message----- > From: Ted Faber [mailto:faber@ISI.EDU] > Sent: Monday, August 11, 2008 4:46 PM > To: Dan Wing > Cc: 'Eric Rescorla'; 'Ron Bonica'; 'Adam Langley'; > tcpm@ietf.org; 'Joe Touch' > Subject: Re: [tcpm] tcp-auth-opt issue: support for NATs > > On Mon, Aug 11, 2008 at 12:32:41PM -0700, Dan Wing wrote: > > > - Key-ids must be globally unique. > > > - You need to know the other side's IP address, even if > you're doing > > > a passive open. > > > > Adding 32 bits to the key-id would create the same global uniqueness > > that using the source IPv4 addresses accomplishes. > > There's a little more to a establishing a global namespace than > allocating the bits. Using the IP address is capitalizing on the IP > address allocation authorities and routing systems to keep those > addresses unique at any given time (and "unique" is somewhat > approximate even with those mechanisms). > > One can establish a global namespace here if needed, but > there's more to > do than allocate the field space. So you want something exceeding "the same global uniqueness" of a v4 address. -d > -- > 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 > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Aug 12 06:45:02 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E436E3A6B0C; Tue, 12 Aug 2008 06:45:01 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D11063A6B0C for ; Tue, 12 Aug 2008 06:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.315 X-Spam-Level: X-Spam-Status: No, score=-0.315 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, FRT_BELOW2=2.154] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0LYxpb7-bkz for ; Tue, 12 Aug 2008 06:44:59 -0700 (PDT) Received: from cgpmail.ua.pt (frontend-2.servers.ua.pt [193.136.173.3]) by core3.amsl.com (Postfix) with ESMTP id 0EF933A6A65 for ; Tue, 12 Aug 2008 06:44:57 -0700 (PDT) Received: from [85.241.152.64] (account etfreire@ua.pt HELO portsfreire) by frontend-2.cgpmail.ua.pt (CommuniGate Pro SMTP 5.1.13) with ESMTPSA id 157086896; Tue, 12 Aug 2008 14:44:36 +0100 From: "Sergio Freire" To: "'Adam Langley'" References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <000001c8fbfe$0dba0960$292e1c20$@pt> <396556a20808111617n622aceabn62db0d55b25ae712@mail.gmail.com> In-Reply-To: <396556a20808111617n622aceabn62db0d55b25ae712@mail.gmail.com> Date: Tue, 12 Aug 2008 14:44:33 +0100 Message-ID: <000301c8fc81$8e02d470$aa087d50$@pt> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acj8CGOK21B8WkI8QwezEPBerq6ESAAc9PVg Content-Language: pt Cc: andre.zuquete@ua.pt, tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org SGkgQWRhbSwKRmlyc3QgbGV0IG1lIHNheSB0aGF0IHRoZSBwYXBlciBJIG1lbnRpb25lZCBwcmVz ZW50cyBhIHBvc3NpYmxlIHNvbHV0aW9uIGZvciBlbWJlZGRpbmcgZGF0YSBpbiB0aGUgc3luY2hy b25pemF0aW9uIHBhY2tldHMuCk91ciB3b3JrIG1peGVzIHR3byBjb25jZXB0czoKIGEpIHVzZSBk YXRhIGluIHRoZSBzZWdtZW50cyBkdXJpbmcgdGhlIHRocmVlLXdheSBoYW5kc2hha2UsIHRoYXQg aW4gdGhpcyBjYXNlIGlzIHNvbWVob3cgcGFydCBvZiBhIFRDUCBvcHRpb24gd2hpY2gganVzdCBz aWduYWxzIGl0cyBsZW5ndGgKIGIpIGEgVENQLWxheWVyIG5hbWUgc2VydmljZQoKV2hhdCB3ZSBp bnRlbmQgdG8gZG8gaXMgdG8gc3BsaXQgdGhpcyB0d28gY29uY2VwdHMgYW5kIHByb3Bvc2U6CiBh KSBhIHdheSB0byBleHRlbmQgdGhlIHNwYWNlIGF2YWlsYWJsZSBmb3IgVENQIG9wdGlvbnMsIGJ5 IHJldXNpbmcgdGhlIHBheWxvYWQgb2YgVENQIHNlZ21lbnRzCiBiKSBhIGdlbmVyYWxpemF0aW9u IG9mIHRoZSBUQ1AtbGF5ZXIgbmFtZSBzZXJ2aWNlIHVzaW5nIHRoZSBmdW5jdGlvbmFsaXR5IHBy b3ZpZGVkIGJ5IGEpCgpTZWUgZGV0YWlsZWQgYW5zd2VycyB0byB5b3VyIHF1ZXN0aW9ucyBpbmxp bmUsIGJlbGxvdy4KClJlZ2FyZHMsClNlcmdpbwoKCgoKCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tCkZyb206IGFsYW5nbGV5QGdtYWlsLmNvbSBbbWFpbHRvOmFsYW5nbGV5QGdtYWlsLmNvbV0g T24gQmVoYWxmIE9mIEFkYW0gTGFuZ2xleQpTZW50OiB0ZXLDp2EtZmVpcmEsIDEyIGRlIEFnb3N0 byBkZSAyMDA4IDA6MTcKVG86IFNlcmdpbyBGcmVpcmUKQ2M6IHRjcG1AaWV0Zi5vcmc7IGFuZHJl Lnp1cXVldGVAdWEucHQKU3ViamVjdDogUmU6IFt0Y3BtXSBTWU4vQUNLIFBheWxvYWRzLCBkcmFm dCAwMQoKT24gTW9uLCBBdWcgMTEsIDIwMDggYXQgMzowMyBQTSwgU2VyZ2lvIEZyZWlyZSA8ZXRm cmVpcmVAdWEucHQ+IHdyb3RlOgo+IE1lYW53aGlsZSwgaWYgeW91IGNhbiB0YWtlIGEgbG9vayBh dCBvdXIgd29yaywgaXQgd291bGQgYmUgZ3JlYXQgZm9yIGZ1cnRoZXIKPiBkaXNjdXNzaW9uIChy ZWdhcmRpbmcgdGhlIHdheSBvZiBleHRlbmRpbmcgdGNwIG9wdGlvbnMgYW5kIG5vdCB0aGUgbmFt ZQo+IHNlcnZpY2UgaXRzZWxmKS4KClNvbWVob3cgSSd2ZSBhbHJlYWR5IHJlYWQgeW91ciBwYXBl ciwgYWx0aG91Z2ggZG9uJ3QgaGF2ZSBhbnkgaWRlYQp3aGVyZSBJIGdvdCB0aGUgcG9pbnRlciBm cm9tIQoKQSBmZXcgcXVlc3Rpb25zOgoKVGhlcmUncyBubyBsZWdhY3kgbW9kZSBmb3IgYWN0aXZl IG9wZW5zIGJlY2F1c2UgdGhlIHBvcnQgbmFtZSBtb2RlIGlzCnNpbmdsZWQgd2l0aCBhIGRlc3Rp bmF0aW9uIHBvcnQgbnVtYmVyIG9mIDAsIHJpZ2h0PwoKU2VyZ2lvOiBJJ20gbm90IHN1cmUgaWYg SSd2ZSB1bmRlcnN0b29kIGNvcnJlY3RseSBidXQgSSB0aGluayBzby4gSW4gb3VyIG1vZGVsIHlv dSBjYW4gZXN0YWJsaXNoIGEgY29ubmVjdGlvbiB0byBhIG5hbWVkIHNlcnZpY2UuIFRoZSBjb25u ZWN0aW9uIGNhbiBiZSBlaXRoZXIgZXN0YWJsaXNoZWQgZnJvbSBhIGxlZ2FjeSBjbGllbnQgb3Ig ZnJvbSBhbiAiZW5oYW5jZWQiIHBvcnRuYW1lIGF3YXJlIGNsaWVudC4gSWYgdGhlIGNvbm5lY3Rp b24gaXMgZXN0YWJsaXNoZWQgZnJvbSBhIGxlZ2FjeSBjbGllbnQsIHRoZW4gaXQgbXVzdCBiZSBl c3RhYmxpc2hlZCB0byB0aGUgZml4ZWQgcG9ydCBudW1iZXIgd2hlcmUgdGhlIHNlcnZpY2Ugd2Fz IGJvdW5kIChhbmQgbm90IDApLiBJZiB0aGUgY2xpZW50IGlzIHBvcnRuYW1lIGF3YXJlLCB0aGVu IGl0IGNhbiBlaXRoZXIgZXN0YWJsaXNoIGEgY29ubmVjdGlvbiB0byBkZXN0aW5hdGlvbiBwb3J0 IG51bWJlciAwIChhbmQgdGhlIGdpdmVuIHBvcnRuYW1lKSBvciB0byB0aGUgc3BlY2lmaWMgZGVz dGluYXRpb24gcG9ydCBudW1iZXIgKGlmIHRoZSBzZXJ2aWNlIHdhcyBib3VuZCB0byBhIHNwZWNp ZmljIHBvcnQgbnVtYmVyKS4KSSdtIGZvcmdldHRpbmcgb24gcHVycG9zZSB0aGUgcG9ydCBhY2Nl c3MgcmVzdHJpY3Rpb25zIHRoYXQgd2Ugc3BlYWsgYWJvdXQgaW4gdGhlIHBhcGVyLCB0aGVzZSBj YW4gbGltaXQgbGVnYWN5IGNvbm5lY3Rpb24uClNvIHVsdGltYXRlbHksIHlvdSBjYW4gaGF2ZSBs ZWdhY3kgYW5kIG5hbWVkIGNvbm5lY3Rpb25zLgoKCllvdSdyZSB0YWtpbmcgdGhlIG9wdGlvbiBu dW1iZXIgMHg0NSBmb3IgeW91ciBsZW5ndGggaW5kaWNhdG9yLiBMYXJzCnBvaW50ZWQgb3V0IHRv IG1lIGEgZmV3IG1vbnRocyBhZ28gdGhhdCAyNTQgYW5kIDI1NSBhcmUgYXNzaWduZWQgZm9yCnRo aXMgaWYgeW91J3JlIHVzaW5nIGl0IG92ZXIgcmVhbCBuZXR3b3Jrcy4KClNlcmdpbzogV2VsbCBJ IGRvbid0IHRoaW5rIHRoYXQgaXMgZXhhY3RseSBjb3JyZWN0LiBMb29raW5nIGF0IGh0dHA6Ly93 d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvdGNwLXBhcmFtZXRlcnMvIGFuZCBSRkMzNjkyIGFuZCBS RkM0NzI3LCB3ZSBjYW4gc2VlIHRoYXQgdGhlIHJlc2VydmVkIGtpbmQgdmFsdWVzIGFyZSAyNTMg YW5kIDI1NC4gVGhlc2UgdHdvIGFyZSB1c2VkIGZvciB0ZXN0aW5nIHB1cnBvc2VzIGFzIFJGQzM2 OTIgKEkgdGhpbmsgZm9yIGdlbmVyYWwgdGVzdGluZyBwdXJwb3Nlcywgbm90IGZvciBhIHNwZWNp ZmljIHB1cnBvc2UpLiBTbywgYSBuZXcgb3B0aW9uIHdvdWxkIGhhdmUgdG8gYmUgYXNzaWduZWQg dG8gc3BlY2lmeSBhIHdheSBvZiBleHRlbmRpbmcgdGhlIGF2YWlsYWJsZSBzcGFjZSBmb3IgVENQ IG9wdGlvbnMuIEluIGEgZmlyc3QgcGhhc2UgSSBndWVzcyAyNTMgb3IgMjU0IGNvdWxkIGJlIHVz ZWQgZm9yIHRoYXQgc2luY2UgdGhleSBhcmUgImdlbmVyaWMiLCBpZiB3aGF0IEkndmUgc2FpZCBl YXJsaWVyIGlzIGNvcnJlY3QuCgoKCkFzc3VtaW5nIHRoYXQgYSBTWU4gZnJhbWUgaXMgc2VudCB0 byBwb3J0IDAsIHJlcXVlc3RpbmcgYSBuYW1lZCBUQ1AKc2VydmljZSB3aGljaCB0aGUgZGVzdGlu YXRpb24ga25vd3MgYWJvdXQ6IHdoYXQncyB0aGUgc291cmNlIHBvcnQKbnVtYmVyIG9mIHRoZSBy ZXN1bHRpbmcgU1lOL0FDSz8gSSB0aGluayBJJ20gcmVhZGluZyB0aGF0IGl0J3MgY2hvc2VuCnJh bmRvbWx5LgoKU2VyZ2lvOiBJdCdzIGluIHRoZSBwYXBlciBidXQgbGV0IG1lIGNsYXJpZnk6IGF0 IHRoZSBzZXJ2ZXIgc2lkZSB5b3UgY2FuIGJpbmQgYSBzZXJ2aWNlIHRvIGEgY2VydGFpbiBuYW1l IGFuZCB0byBhIHNwZWNpZmljIHBvcnQgb3IgZWxzZSB5b3UgbWF5IG5vdCBzcGVjaWZ5IHRoZSBw b3J0IG51bWJlci4gSW4gdGhlIGxhc3QgY2FzZSB0aGUgb3BlcmF0aW5nIHN5c3RlbSBhc3NpZ25z IGl0IGEgcmFuZG9tIHBvcnQuIFNvIHRoZSBTWU5BQ0sgc291cmNlIHBvcnQgY29ycmVzcG9uZHMg ZWl0aGVyIHRvIHRoZSBzcGVjaWZpYyBwb3J0IHVzaW5nIGR1cmluZyBiaW5kIG9yIHRvIGEgcmFu ZG9tIHBvcnQgY2hvc2VuIGJ5IHRoZSBPUyBhdCBiaW5kIHRpbWUuIApBY3R1YWxseSBjaGFuZ2lu ZyBwb3J0cyBkdXJpbmcgYSBjb25uZWN0aW9uIHJhaXNlcyBzb21lIHByb2JsZW1zIGxpa2UgaW4g ZmlyZXdhbGxzLCBOQVQgYm94ZXMuIFdlIGhhdmUgdG8gY2hvc2UgYW5vdGhlciBhcHByb2FjaCBs aWtlIEpvZSBUb3VjaCdzIHN1Z2dlc3Rpb24gb2YgYSByYW5kb21seSBjaG9zZW4gZGVzdGluYXRp b24gcG9ydCBudW1iZXIgYXQgY2xpZW50IHNpZGUgKHNlZSBwb3J0bmFtZXMgZHJhZnQgZnJvbSBK LlRvdWNoKS4KCgoKCgpGcm9tIHRoZSB0YWJsZSBpbiAzLjMgaXQgZG9lc24ndCBhcHBlYXIgdGhh dCB0aGVyZSdzIGFueSBTWU5BQ0sKcGF5bG9hZCwgaXMgdGhhdCBjb3JyZWN0PwoKClNlcmdpbzog Tm8uIFRoZXJlIGlzIHBheWxvYWQgaW4gdGhlIFNZTkFDSywgd2hpY2ggY29ycmVzcG9uZHMgdG8g dGhlIHNhbWUgcGF5bG9hZCB3ZSB1c2VkIGluIHRoZSBTWU4uIFdlIHVzZSBpdCB0byBjb3JyZWxh dGUgYm90aCBwYWNrZXRzLiBUaGVyZSB3YXMgYSB0eXBvIGJ1ZyBpbiB0aGUgaW5pdGlhbCBwYXBl ciBpbiB0aGF0IHRhYmxlIHRob3VnaC4gSSB0aGluayBpdCdzIGNvcnJlY3QgYXMgaXQgaXMgbm93 LgoKCgoKCgpJdCdzIHVuZm9ydHVuYXRlIHRoYXQgdGhlcmUncyBubyB3YXkgZm9yIGNsaWVudHMg dG8gZ3JhZHVhbGx5IHN0YXJ0CnVzaW5nIHN1Y2ggYSBzY2hlbWUsIGJ1dCB5b3UgY2FuJ3QgZXh0 ZW5kIHRoZSBvcHRpb24gc3BhY2UgaW4gU1lOcwphbmQsIGlmIHlvdSB1c2VkIG5vbi0wIGRlc3Rp bmF0aW9uIHBvcnRzLCBzb21lIGhvc3RzIG1heSBlbnF1ZXVlIHRoZQpwYXlsb2FkLgoKU2VyZ2lv OiBXZWxsLCB0aGF0IGlzIHRoZSBrZXkgcG9pbnQuIFdlIG11c3QgZmlndXJlIG91dCBhIG91dCBm b3IgdGhhdCB0byBub3QgaGFwcGVuLiBNb3N0IE9TZXMgYW5kIFRDUCBpbXBsZW1lbnRhdGlvbnMg aWdub3JlIHBheWxvYWQgaW4gdGhlIFNZTiBvciBTWU5BQ0sgc2VnbWVudHMuIFBheWxvYWQgaW4g dGhlIEFDSyBzZWdtZW50IG9mIHRoZSB0aHJlZS13YXkgaGFuZHNoYWtlIGlzIGdlbmVyYWxseSB1 bmRlcnN0b29kLiBXZSB1c2VkIGRlc3RpbmF0aW9uIHBvcnQgMCB0byBmb3JjZSBhIFJTVCBvbiBs ZWdhY3kgc2VydmVyIHNpZGUgVENQIGltcGxlbWVudGF0aW9ucy4gVGhlcmUgYXJlIHNldmVyYWwg b3B0aW9ucyBmb3Igbm90IGdvaW5nIHRocm91Z2ggd2l0aCBhIHdyb25nIGNvbm5lY3Rpb24gd2l0 aCBsZWdhY3kgc3lzdGVtcy4uLiBvbmUgaXMgdG8gYXNzaWduIGEgZml4ZWQgZGVzdGluYXRpb24g cG9ydCB3aGVuIHVzaW5nIHRoaXMgIlRDUCBvcHRpb24gZXh0ZW5zaW9uIG1lY2hhbmlzbSIuIElm IHlvdSBjaGFuZ2UgdGhlIHNlcXVlbmNpbmcgbnVtYmVycyBmcm9tIHRoZSBzdGFuZGFyZCBiZWhh dmlvciwgbWFueSBzdGFja3Mgd2lsbCBkcm9wIHRoZSBjb25uZWN0aW9uLiBCdXQgdGhpcyBpcyBu b3QgMTAwJSBzYWZlLiBUaGUgZ3JlYXQgaWRlYSBpcyB0byBoYXZlIHNvbWUgd2F5IHRoYXQgdHJh ZGl0aW9uYWwgc3RhY2tzIGRyb3AgdGhlIGNvbm5lY3Rpb24gd2hpbGUgbmV3IG9uZXMgYWNjZXB0 IGl0LgpXZSBjYW4gZGlzY3VzcyB0aGlzIGxhdHRlciBpbiBtb3JlIGRldGFpbCwgSSB3YXMganVz dCBnaXZpbmcgYSBnZW5lcmFsIG92ZXJ2aWV3IG9mIHRoZSBwcm9ibGVtYXRpYyBoZXJlLgogCgoK CkluIHNob3J0LCBpZiBteSB1bmRlcnN0YW5kaW5nIGlzIGNvcnJlY3QsIEkgZG9uJ3QgYmVsaWV2 ZSB0aGVzZSB0d28Kc2NoZW1lcyBpbnRlcmZlcmUsIGV2ZW4gb24gYSBzaW5nbGUgY29ubmVjdGlv bi4KCkFyZSB5b3UgaW50ZW5kaW5nIG9uIHRyeWluZyB0byBnZXQgYW4gb3B0aW9uIG51bWJlciBh c3NpZ25lZCBmb3IgdGhpcz8KCgpTZXJnaW86IFdlbGwsIHdlIHdvdWxkIGxpa2UgdG8gd3JpdGUg dHdvIGRyYWZ0czogb25lIGZvciBhIGdlbmVyaWMgd2F5IHRvIGV4dGVuZCB0aGUgc3BhY2UgYXZh aWxhYmxlIGZvciBUQ1Agb3B0aW9ucyBhbmQgYW5vdGhlciBvbmUgdG8gc3BlY2lmeSBhICJuYW1l IiB0aGF0IHdvdWxkIGJlIHVzZWQgdG8gcmVzb2x2ZSB0byBhIGNlcnRhaW4gc2VydmljZSB3aXRo IHRoYXQgZ2l2ZW4gbmFtZS4gSSBndWVzcyB0aGlzIGNvcnJlc3BvbmRzIHRvIHR3byBUQ1Agb3B0 aW9ucy4gQXMgSSd2ZSBtZW50aW9uZWQgYWJvdmUsIHRoZSBsYXN0IG9uZSByZXVzZXMgdGhlIHBv c3NpYmlsaXR5IGNyZWF0ZWQgYnkgb3VyIHdvcmsgb3Igc29tZSBvdGhlciB3b3JrIGxpa2UgeW91 cnMgdGhhdCBjYW4gcmV1c2UgdGhlIFRDUCBwYXlsb2FkLgoKCgoKCgpDaGVlcnMKCkFHTAoKLS0g CkFkYW0gTGFuZ2xleSBhZ2xAaW1wZXJpYWx2aW9sZXQub3JnIGh0dHA6Ly93d3cuaW1wZXJpYWx2 aW9sZXQub3JnCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xwp0Y3BtIG1haWxpbmcgbGlzdAp0Y3BtQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdGNwbQo= From tcpm-bounces@ietf.org Tue Aug 12 07:13:14 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76FDA3A6B4A; Tue, 12 Aug 2008 07:13:14 -0700 (PDT) X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id F22353A68F8; Tue, 12 Aug 2008 07:13:11 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20080812141311.F22353A68F8@core3.amsl.com> Date: Tue, 12 Aug 2008 07:13:11 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] Last Call: draft-ietf-tcpm-tcp-soft-errors (TCP's Reaction to Soft Errors) to Informational RFC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'TCP's Reaction to Soft Errors ' as an Informational RFC This is the second IETF last call for this document, to give the IPv6 community sufficient time to review how this document interacts with dual-stack hosts. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-08-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-soft-errors-08.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14290&rfc_flag=0 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Aug 12 07:39:03 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3FCE3A6B1D; Tue, 12 Aug 2008 07:39:03 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88FDD3A6A5F for ; Tue, 12 Aug 2008 07:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.566 X-Spam-Level: X-Spam-Status: No, score=-4.566 tagged_above=-999 required=5 tests=[AWL=-1.967, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7aNOSIHMrDnY for ; Tue, 12 Aug 2008 07:39:01 -0700 (PDT) Received: from mgw-fb01.nokia.com (mgw-fb01.nokia.com [192.100.122.235]) by core3.amsl.com (Postfix) with ESMTP id 66EA63A6AF9 for ; Tue, 12 Aug 2008 07:39:01 -0700 (PDT) Received: from mgw-mx06.nokia.com (mgw-mx06.nokia.com [192.100.122.233]) by mgw-fb01.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m7CEd19a030112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 12 Aug 2008 17:39:01 +0300 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m7CEcR3K009295 for ; Tue, 12 Aug 2008 17:38:59 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Aug 2008 17:38:51 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Aug 2008 17:38:50 +0300 Received: from net-204.nrpn.net ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Aug 2008 17:38:50 +0300 Message-Id: <5884AD49-B76C-42A9-AE2E-301444E79B5B@nokia.com> From: Lars Eggert To: tcpm Extensions WG In-Reply-To: <20080812141311.F22353A68F8@core3.amsl.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 12 Aug 2008 17:38:45 +0300 References: <20080812141311.F22353A68F8@core3.amsl.com> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 12 Aug 2008 14:38:50.0977 (UTC) FILETIME=[231B4D10:01C8FC89] X-Nokia-AV: Clean Subject: Re: [tcpm] Last Call: draft-ietf-tcpm-tcp-soft-errors (TCP's Reaction to Soft Errors) to Informational RFC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org FYI, the INT and OPS ADs have requested more time for their directorates and WGs to review this draft. Apparently the original announcement was missed in the flurry of pre-IETF email. I'm thus doing a second IETF last call for this. Lars On 2008-8-12, at 17:13, ext The IESG wrote: > The IESG has received a request from the TCP Maintenance and Minor > Extensions WG (tcpm) to consider the following document: > > - 'TCP's Reaction to Soft Errors ' > as an Informational RFC > > This is the second IETF last call for this document, to give the IPv6 > community > sufficient time to review how this document interacts with dual-stack > hosts. > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to > the > ietf@ietf.org mailing lists by 2008-08-26. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-soft-errors-08.txt > > > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14290&rfc_flag=0 > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Aug 12 07:48:21 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5E973A6B50; Tue, 12 Aug 2008 07:48:21 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91EDE3A6B50 for ; Tue, 12 Aug 2008 07:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.463 X-Spam-Level: X-Spam-Status: No, score=-6.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhmTLDh6YouO for ; Tue, 12 Aug 2008 07:48:16 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 22A333A69DD for ; Tue, 12 Aug 2008 07:48:15 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m7CEluoO024063; Tue, 12 Aug 2008 17:48:03 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Aug 2008 17:47:58 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Aug 2008 17:47:46 +0300 Received: from net-204.nrpn.net ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Aug 2008 17:47:45 +0300 Message-Id: From: Lars Eggert To: ext Sergio Freire In-Reply-To: <000301c8fc81$8e02d470$aa087d50$@pt> Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 12 Aug 2008 17:47:39 +0300 References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <000001c8fbfe$0dba0960$292e1c20$@pt> <396556a20808111617n622aceabn62db0d55b25ae712@mail.gmail.com> <000301c8fc81$8e02d470$aa087d50$@pt> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 12 Aug 2008 14:47:46.0017 (UTC) FILETIME=[6203ED10:01C8FC8A] X-Nokia-AV: Clean Cc: 'Adam Langley' , andre.zuquete@ua.pt, tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On 2008-8-12, at 16:44, ext Sergio Freire wrote: > Sergio: Well I don't think that is exactly correct. Looking athttp://www.iana.org/assignments/tcp-parameters/ > and RFC3692 and RFC4727, we can see that the reserved kind values > are 253 and 254. These two are used for testing purposes as RFC3692 > (I think for general testing purposes, not for a specific purpose). > So, a new option would have to be assigned to specify a way of > extending the available space for TCP options. In a first phase I > guess 253 or 254 could be used for that since they are "generic", if > what I've said earlier is correct. If you look at the URL you posted, you'll see this bit: "Registration Procedures: IESG Approval or Standards Action" That means that you MUST obtain a number through one of these two procedures (see RFC5226). You MUST NOT simply grab an unassigned one. Adam is correct that for limited experimentation, you should use 253 or 254, as per RFC4727. To go beyond that, you MUST register an option number, either via IESG Approval or a Standards Action. Lars _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Aug 12 08:52:51 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2A8F3A69E4; Tue, 12 Aug 2008 08:52:51 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 062553A69E4 for ; Tue, 12 Aug 2008 08:52:50 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G30s0CPYaNlN for ; Tue, 12 Aug 2008 08:52:48 -0700 (PDT) Received: from cgpmail.ua.pt (frontend-1.servers.ua.pt [193.136.173.2]) by core3.amsl.com (Postfix) with ESMTP id 0A69628C0FA for ; Tue, 12 Aug 2008 08:52:47 -0700 (PDT) Received: from [194.65.138.120] (account etfreire@ua.pt HELO portsfreire) by frontend1.cgpmail.ua.pt (CommuniGate Pro SMTP 5.1.13) with ESMTPSA id 118356316; Tue, 12 Aug 2008 16:52:48 +0100 From: "Sergio Freire" To: "'Lars Eggert'" References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <000001c8fbfe$0dba0960$292e1c20$@pt> <396556a20808111617n622aceabn62db0d55b25ae712@mail.gmail.com> <000301c8fc81$8e02d470$aa087d50$@pt> In-Reply-To: Date: Tue, 12 Aug 2008 16:52:46 +0100 Message-ID: <000401c8fc93$776578f0$66306ad0$@pt> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acj8inw7hI505TsMTauxRltXZD5/TQACBDlQ Content-Language: pt Cc: 'Adam Langley' , andre.zuquete@ua.pt, tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Hi Lars, Of course, I know that but thanks for clarifying :) We used a value just for experimentation purposes only. What Adam was saying is that TCP option kind values 254 and 255 were reserved to specify a length indicator, that's what I understood. But I think he meant 253 and 254. Anyway, these kind values seem to not be reserved for a specific purposed... instead, they are reserved for experimentation purposes. Also, just to clarify this. :) Regards, Sergio -----Original Message----- From: Lars Eggert [mailto:lars.eggert@nokia.com] = Sent: ter=E7a-feira, 12 de Agosto de 2008 15:48 To: ext Sergio Freire Cc: 'Adam Langley'; andre.zuquete@ua.pt; tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 On 2008-8-12, at 16:44, ext Sergio Freire wrote: > Sergio: Well I don't think that is exactly correct. Looking athttp://www.iana.org/assignments/tcp-parameters/ = > and RFC3692 and RFC4727, we can see that the reserved kind values = > are 253 and 254. These two are used for testing purposes as RFC3692 = > (I think for general testing purposes, not for a specific purpose). = > So, a new option would have to be assigned to specify a way of = > extending the available space for TCP options. In a first phase I = > guess 253 or 254 could be used for that since they are "generic", if = > what I've said earlier is correct. If you look at the URL you posted, you'll see this bit: "Registration = Procedures: IESG Approval or Standards Action" That means that you MUST obtain a number through one of these two = procedures (see RFC5226). You MUST NOT simply grab an unassigned one. Adam is correct that for limited experimentation, you should use 253 = or 254, as per RFC4727. To go beyond that, you MUST register an option = number, either via IESG Approval or a Standards Action. Lars _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Aug 12 09:15:02 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BAD828C0F5; Tue, 12 Aug 2008 09:15:02 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F6493A6A40 for ; Tue, 12 Aug 2008 09:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hz0A6D9nGBXG for ; Tue, 12 Aug 2008 09:15:00 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by core3.amsl.com (Postfix) with ESMTP id 41A213A6956 for ; Tue, 12 Aug 2008 09:15:00 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so2386215rvf.49 for ; Tue, 12 Aug 2008 09:14:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=NkEXp8g58UIlM7lPv0HRKJSkFNhgFL6xCxy65JUYA1c=; b=hlW5+7ELt5ALZXHFnOgHw3PqK7pQSIPLSAd9pOiGJ1jM/RepprzU6/2j8oPi2QJMAw iu+5KPsxh6Pgc0mqHMq3rg7GWGpJGkm5Mnrl1GBYhSDBnsy9xCSLFSZIQV56eNSLLlKK wgn84THCLY/kGcl1qW2pvkwdnHvcZIzBL11n8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=Gc511gG2vOoenJB6BdkOtxt/rx7e4Z515a/nnA5sz5g7Uh/4kT0iOnm0ttWJpnT1TC C90Ttxbv9ybXxMRHaFFwVz7zUWvv7+NdNFIEt1Oro0Jrj0XpPWIR6263S2fEdXtQbZFx cWc++2qwbiPVfteQ/ZyW3BFQslkfLaz8xFI2Q= Received: by 10.141.141.3 with SMTP id t3mr4519293rvn.124.1218557668319; Tue, 12 Aug 2008 09:14:28 -0700 (PDT) Received: by 10.141.37.3 with HTTP; Tue, 12 Aug 2008 09:14:28 -0700 (PDT) Message-ID: <396556a20808120914k6d087534o5c34dfd51dd7d1c5@mail.gmail.com> Date: Tue, 12 Aug 2008 09:14:28 -0700 From: "Adam Langley" To: "Sergio Freire" In-Reply-To: <000301c8fc81$8e02d470$aa087d50$@pt> MIME-Version: 1.0 Content-Disposition: inline References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <000001c8fbfe$0dba0960$292e1c20$@pt> <396556a20808111617n622aceabn62db0d55b25ae712@mail.gmail.com> <000301c8fc81$8e02d470$aa087d50$@pt> X-Google-Sender-Auth: ee9ce0214b130d61 Cc: andre.zuquete@ua.pt, tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Tue, Aug 12, 2008 at 6:44 AM, Sergio Freire wrote: > What we intend to do is to split this two concepts and propose: > a) a way to extend the space available for TCP options, by reusing the payload of TCP segments > b) a generalization of the TCP-layer name service using the functionality provided by a) For a) also see [1], although it doesn't do anything for including extra data in the SYN frame. > Sergio: I'm not sure if I've understood correctly but I think so. In our model you can establish a connection to a named service. The connection can be either established from a legacy client or from an "enhanced" portname aware client. If the connection is established from a legacy client, then it must be established to the fixed port number where the service was bound (and not 0). If the client is portname aware, then it can either establish a connection to destination port number 0 (and the given portname) or to the specific destination port number (if the service was bound to a specific port number). Right, it's just unfortunate that a client connecting to a portname cannot fallback to a default portnumber. (For example, connecting to "http", but also setting the destination port to 80 for server which don't understand that). However, I don't believe that there's any way to do that. > Actually changing ports during a connection raises some problems like in firewalls, NAT boxes. Indeed, NATs strike again. I believe most of them would fail in this situation. > We have to chose another approach like Joe Touch's suggestion of a randomly chosen destination port number at client side (see portnames draft from J.Touch). However, if you aren't setting dport to 0 to signal that the SYN is special, then hosts may interpret the payload of the SYN frame to be application level data. Joe's portname draft uses options to avoid this. > Sergio: No. There is payload in the SYNACK, which corresponds to the same payload we used in the SYN. We use it to correlate both packets. There was a typo bug in the initial paper in that table though. I think it's correct as it is now. In the bottom right cell of the table, the final ACK is only acking ISN_s + 1, should it not be ISN_s + 1 + L? (Unless the echoed data in the SYNACK isn't acked). Also, I don't understand why you need this to correlate the packet - you have the destination port in the SYNACK. [1] http://www.ietf.org/internet-drafts/draft-agl-tcpm-sadata-01.txt AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Aug 12 10:17:37 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B154A3A6A8F; Tue, 12 Aug 2008 10:17:37 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 796F93A67FE for ; Tue, 12 Aug 2008 10:17:36 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXF449whsikI for ; Tue, 12 Aug 2008 10:17:35 -0700 (PDT) Received: from cgpmail.ua.pt (frontend-1.servers.ua.pt [193.136.173.2]) by core3.amsl.com (Postfix) with ESMTP id DC47B3A69CC for ; Tue, 12 Aug 2008 10:17:34 -0700 (PDT) Received: from [194.65.138.120] (account etfreire@ua.pt HELO portsfreire) by frontend1.cgpmail.ua.pt (CommuniGate Pro SMTP 5.1.13) with ESMTPSA id 118366942; Tue, 12 Aug 2008 18:17:32 +0100 From: "Sergio Freire" To: "'Adam Langley'" References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <000001c8fbfe$0dba0960$292e1c20$@pt> <396556a20808111617n622aceabn62db0d55b25ae712@mail.gmail.com> <000301c8fc81$8e02d470$aa087d50$@pt> <396556a20808120914k6d087534o5c34dfd51dd7d1c5@mail.gmail.com> In-Reply-To: <396556a20808120914k6d087534o5c34dfd51dd7d1c5@mail.gmail.com> Date: Tue, 12 Aug 2008 18:17:30 +0100 Message-ID: <000b01c8fc9f$4d9f3c20$e8ddb460$@pt> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acj8loI3gjApX1xERLWK5sK+7qCOigABfjIg Content-Language: pt Cc: andre.zuquete@ua.pt, tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org SW5saW5lLi4KCgoKLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KRnJvbTogYWxhbmdsZXlAZ21h aWwuY29tIFttYWlsdG86YWxhbmdsZXlAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgQWRhbSBMYW5n bGV5ClNlbnQ6IHRlcsOnYS1mZWlyYSwgMTIgZGUgQWdvc3RvIGRlIDIwMDggMTc6MTQKVG86IFNl cmdpbyBGcmVpcmUKQ2M6IGFuZHJlLnp1cXVldGVAdWEucHQ7IHRjcG1AaWV0Zi5vcmcKU3ViamVj dDogUmU6IFt0Y3BtXSBTWU4vQUNLIFBheWxvYWRzLCBkcmFmdCAwMQoKT24gVHVlLCBBdWcgMTIs IDIwMDggYXQgNjo0NCBBTSwgU2VyZ2lvIEZyZWlyZSA8ZXRmcmVpcmVAdWEucHQ+IHdyb3RlOgo+ IFdoYXQgd2UgaW50ZW5kIHRvIGRvIGlzIHRvIHNwbGl0IHRoaXMgdHdvIGNvbmNlcHRzIGFuZCBw cm9wb3NlOgo+ICBhKSBhIHdheSB0byBleHRlbmQgdGhlIHNwYWNlIGF2YWlsYWJsZSBmb3IgVENQ IG9wdGlvbnMsIGJ5IHJldXNpbmcgdGhlIHBheWxvYWQgb2YgVENQIHNlZ21lbnRzCj4gIGIpIGEg Z2VuZXJhbGl6YXRpb24gb2YgdGhlIFRDUC1sYXllciBuYW1lIHNlcnZpY2UgdXNpbmcgdGhlIGZ1 bmN0aW9uYWxpdHkgcHJvdmlkZWQgYnkgYSkKCkZvciBhKSBhbHNvIHNlZSBbMV0sIGFsdGhvdWdo IGl0IGRvZXNuJ3QgZG8gYW55dGhpbmcgZm9yIGluY2x1ZGluZwpleHRyYSBkYXRhIGluIHRoZSBT WU4gZnJhbWUuCgpTZXJnaW86IEkgdGhpbmsgaXQgd291bGQgYmUgZ3JlYXQgdG8gaGFuZGxlIGFs c28gYWRkaXRpb25hbCBwYXlsb2FkLiBJZiB3ZSBhcmUgY2hhbmdpbmcgdGhpbmdzIGF0IHRoaXMg bGV2ZWwgSSB0aGluayBpdCB3b3VsZCBiZSBvZiBncmVhdCB2YWxvciB0byBoYW5kbGUgdGhlIHR3 byBjYXNlcyA6KSBJIHN0aWxsIGhhdmUgdG8gbG9vayBjYXJlZnVsbHkgYXQgeW91ciBkcmFmdC4K CgoKPiBTZXJnaW86IEknbSBub3Qgc3VyZSBpZiBJJ3ZlIHVuZGVyc3Rvb2QgY29ycmVjdGx5IGJ1 dCBJIHRoaW5rIHNvLiBJbiBvdXIgbW9kZWwgeW91IGNhbiBlc3RhYmxpc2ggYSBjb25uZWN0aW9u IHRvIGEgbmFtZWQgc2VydmljZS4gVGhlIGNvbm5lY3Rpb24gY2FuIGJlIGVpdGhlciBlc3RhYmxp c2hlZCBmcm9tIGEgbGVnYWN5IGNsaWVudCBvciBmcm9tIGFuICJlbmhhbmNlZCIgcG9ydG5hbWUg YXdhcmUgY2xpZW50LiBJZiB0aGUgY29ubmVjdGlvbiBpcyBlc3RhYmxpc2hlZCBmcm9tIGEgbGVn YWN5IGNsaWVudCwgdGhlbiBpdCBtdXN0IGJlIGVzdGFibGlzaGVkIHRvIHRoZSBmaXhlZCBwb3J0 IG51bWJlciB3aGVyZSB0aGUgc2VydmljZSB3YXMgYm91bmQgKGFuZCBub3QgMCkuIElmIHRoZSBj bGllbnQgaXMgcG9ydG5hbWUgYXdhcmUsIHRoZW4gaXQgY2FuIGVpdGhlciBlc3RhYmxpc2ggYSBj b25uZWN0aW9uIHRvIGRlc3RpbmF0aW9uIHBvcnQgbnVtYmVyIDAgKGFuZCB0aGUgZ2l2ZW4gcG9y dG5hbWUpIG9yIHRvIHRoZSBzcGVjaWZpYyBkZXN0aW5hdGlvbiBwb3J0IG51bWJlciAoaWYgdGhl IHNlcnZpY2Ugd2FzIGJvdW5kIHRvIGEgc3BlY2lmaWMgcG9ydCBudW1iZXIpLgoKUmlnaHQsIGl0 J3MganVzdCB1bmZvcnR1bmF0ZSB0aGF0IGEgY2xpZW50IGNvbm5lY3RpbmcgdG8gYSBwb3J0bmFt ZQpjYW5ub3QgZmFsbGJhY2sgdG8gYSBkZWZhdWx0IHBvcnRudW1iZXIuIChGb3IgZXhhbXBsZSwg Y29ubmVjdGluZyB0bwoiaHR0cCIsIGJ1dCBhbHNvIHNldHRpbmcgdGhlIGRlc3RpbmF0aW9uIHBv cnQgdG8gODAgZm9yIHNlcnZlciB3aGljaApkb24ndCB1bmRlcnN0YW5kIHRoYXQpLiBIb3dldmVy LCBJIGRvbid0IGJlbGlldmUgdGhhdCB0aGVyZSdzIGFueSB3YXkKdG8gZG8gdGhhdC4KCgpTZXJn aW86IHdlbGwsIHVzaW5nIEpvZSBUb3VjaCdzIHBvcnRuYW1lIGRyYWZ0LCB3aGljaCBpcyBhIGJp dCBkaWZmZXJlbnQgZnJvbSBvdXIgYXBwcm9hY2gsIHlvdSBjb3VsZC4gQW55d2F5LCB5b3UgY2Fu IGFsc28gdGhpbmsgb24gc3BlY2lmeWluZyB0aGUgZGVzdGluYXRpb24gcG9ydCBudW1iZXIgKHlv dXIgZGVmYXVsdCBwb3J0bnVtYmVyKSBpbnN0ZWFkIG9mIDAuIEluIHRoYXQgY2FzZSB3ZSB3b3Vs ZCBuZWVkIHRvIHNpZ25hbCB0aGUgcG9ydG5hbWUgYW5kIG1haW50YWluIHRoZSBsZWdhY3kgY29t cGF0aWJpbGl0eSB1c2luZyBhbm90aGVyIG1ldGhvZC4KCgoKPiBBY3R1YWxseSBjaGFuZ2luZyBw b3J0cyBkdXJpbmcgYSBjb25uZWN0aW9uIHJhaXNlcyBzb21lIHByb2JsZW1zIGxpa2UgaW4gZmly ZXdhbGxzLCBOQVQgYm94ZXMuCgpJbmRlZWQsIE5BVHMgc3RyaWtlIGFnYWluLiBJIGJlbGlldmUg bW9zdCBvZiB0aGVtIHdvdWxkIGZhaWwgaW4gdGhpcyBzaXR1YXRpb24uCgo+IFdlIGhhdmUgdG8g Y2hvc2UgYW5vdGhlciBhcHByb2FjaCBsaWtlIEpvZSBUb3VjaCdzIHN1Z2dlc3Rpb24gb2YgYSBy YW5kb21seSBjaG9zZW4gZGVzdGluYXRpb24gcG9ydCBudW1iZXIgYXQgY2xpZW50IHNpZGUgKHNl ZSBwb3J0bmFtZXMgZHJhZnQgZnJvbSBKLlRvdWNoKS4KCkhvd2V2ZXIsIGlmIHlvdSBhcmVuJ3Qg c2V0dGluZyBkcG9ydCB0byAwIHRvIHNpZ25hbCB0aGF0IHRoZSBTWU4gaXMKc3BlY2lhbCwgdGhl biBob3N0cyBtYXkgaW50ZXJwcmV0IHRoZSBwYXlsb2FkIG9mIHRoZSBTWU4gZnJhbWUgdG8gYmUK YXBwbGljYXRpb24gbGV2ZWwgZGF0YS4gSm9lJ3MgcG9ydG5hbWUgZHJhZnQgdXNlcyBvcHRpb25z IHRvIGF2b2lkCnRoaXMuCgpTZXJnaW86IEFjdHVhbGx5IHRoZXkgZG9uJ3QsIGJlY2F1c2UgaW4g dGhhdCBzcGVjaWZpYyBjYXNlIHRoZSBkZXN0aW5hdGlvbiBob3N0IHdvdWxkIGhhdmUgdG8gdW5k ZXJzdGFuZCBwb3J0IG5hbWVzLgoKCgoKCj4gU2VyZ2lvOiBOby4gVGhlcmUgaXMgcGF5bG9hZCBp biB0aGUgU1lOQUNLLCB3aGljaCBjb3JyZXNwb25kcyB0byB0aGUgc2FtZSBwYXlsb2FkIHdlIHVz ZWQgaW4gdGhlIFNZTi4gV2UgdXNlIGl0IHRvIGNvcnJlbGF0ZSBib3RoIHBhY2tldHMuIFRoZXJl IHdhcyBhIHR5cG8gYnVnIGluIHRoZSBpbml0aWFsIHBhcGVyIGluIHRoYXQgdGFibGUgdGhvdWdo LiBJIHRoaW5rIGl0J3MgY29ycmVjdCBhcyBpdCBpcyBub3cuCgpJbiB0aGUgYm90dG9tIHJpZ2h0 IGNlbGwgb2YgdGhlIHRhYmxlLCB0aGUgZmluYWwgQUNLIGlzIG9ubHkgYWNraW5nCklTTl9zICsg MSwgc2hvdWxkIGl0IG5vdCBiZSBJU05fcyArIDEgKyBMPyAoVW5sZXNzIHRoZSBlY2hvZWQgZGF0 YSBpbgp0aGUgU1lOQUNLIGlzbid0IGFja2VkKS4gQWxzbywgSSBkb24ndCB1bmRlcnN0YW5kIHdo eSB5b3UgbmVlZCB0aGlzIHRvCmNvcnJlbGF0ZSB0aGUgcGFja2V0IC0geW91IGhhdmUgdGhlIGRl c3RpbmF0aW9uIHBvcnQgaW4gdGhlIFNZTkFDSy4KClsxXSBodHRwOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1hZ2wtdGNwbS1zYWRhdGEtMDEudHh0CgoKU2VyZ2lvOiBSaWdo dCwgaW4gbXkgdGhlc2lzIHRoYXQgd2FzIGNvcnJlY3RlZC4gVGhhbmtzLiBMZXQgbWUgZXhwbGFp biBob3cgc2VnbWVudHMgYXJlIGNvcnJlbGF0ZWQ6IHNyY19JUCtzcmNfcG9ydCtkc3RfSVArZHN0 X3BvcnQuIFNpbmNlIHRoZSBkZXN0aW5hdGlvbiBwb3J0IGluIFNZTiBtYXkgYmUgMCBhbmQgdGhl IHNvdXJjZSBwb3J0IGluIFNZTkFDSyBpcyBhbHdheXMgdGhlIHJlc29sdmVkIHBvcnQuIFNvLCB0 aGVyZSBtdXN0IGJlIGFub3RoZXIgZmllbGQgdG8gY29ycmVsYXRlLCB3aGljaCBpbiB0aGlzIGNh c2Ugd2UgZGVjaWRlZCB0byB1c2UgdGhlIHBvcnRuYW1lLgoKCgpBR0wKCi0tIApBZGFtIExhbmds ZXkgYWdsQGltcGVyaWFsdmlvbGV0Lm9yZyBodHRwOi8vd3d3LmltcGVyaWFsdmlvbGV0Lm9yZwoK X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KdGNwbSBtYWls aW5nIGxpc3QKdGNwbUBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3RjcG0K From tcpm-bounces@ietf.org Tue Aug 12 11:55:20 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B511328C14B; Tue, 12 Aug 2008 11:55:20 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3298928C14B for ; Tue, 12 Aug 2008 11:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.327 X-Spam-Level: X-Spam-Status: No, score=-1.327 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ik5AGUAwsB6i for ; Tue, 12 Aug 2008 11:55:19 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by core3.amsl.com (Postfix) with ESMTP id 3AD7D28C111 for ; Tue, 12 Aug 2008 11:55:19 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so2440637rvf.49 for ; Tue, 12 Aug 2008 11:55:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=i0+qDJhQWpvPnkjvSj69BtBp0lZqBc41ts4e7waOI7w=; b=TA6htR4j2JmI1LuDwRc+ZqjEM+W3AS6NiOvkyPGBaKldgaN/M/5M/mUxRZkT/kPauX 6lf48MfrruCdkGDWd+oBjRPs/BZk9UkLDmiLK3PdDolUaKHl8ZJIy14lP3Uiyz3plLHR YDJSqUD/MceM6SPajhA3GeuqzfyRjfh0YpHUM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=apdWcfufApBuKJZVPBhge1t295tJ1Pwx2ruKI+HSQ6qU5RiLk7VjBkp4jSs50mjw1O KpTfIfYRf0dzjo6iwCMxmlFaLsph9tOPkjn+tzdgxagJEV2v4lz3WaeE3f1LBpSdwaBC GP/rr+twN36xKDenTnCTh7IhaGe/zxvX+pA44= Received: by 10.141.163.12 with SMTP id q12mr4620719rvo.260.1218567306328; Tue, 12 Aug 2008 11:55:06 -0700 (PDT) Received: by 10.141.37.3 with HTTP; Tue, 12 Aug 2008 11:55:06 -0700 (PDT) Message-ID: <396556a20808121155h4e3c551aqcf5260d551bcdd4a@mail.gmail.com> Date: Tue, 12 Aug 2008 11:55:06 -0700 From: "Adam Langley" To: "Sergio Freire" In-Reply-To: <000b01c8fc9f$4d9f3c20$e8ddb460$@pt> MIME-Version: 1.0 Content-Disposition: inline References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <000001c8fbfe$0dba0960$292e1c20$@pt> <396556a20808111617n622aceabn62db0d55b25ae712@mail.gmail.com> <000301c8fc81$8e02d470$aa087d50$@pt> <396556a20808120914k6d087534o5c34dfd51dd7d1c5@mail.gmail.com> <000b01c8fc9f$4d9f3c20$e8ddb460$@pt> X-Google-Sender-Auth: 811f6ac65ad78cad Cc: andre.zuquete@ua.pt, tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Tue, Aug 12, 2008 at 10:17 AM, Sergio Freire wrote: > Sergio: I think it would be great to handle also additional payload. If we are changing things at this level I think it would be of great valor to handle the two cases :) I still have to look carefully at your draft. Sadly, I don't believe that there is a good way to include extra options space in a SYN frame in a backwards compatible manner. You're trick of using port 0 is one such way, but obviously ties it to an alternative port resolution scheme. > However, if you aren't setting dport to 0 to signal that the SYN is > special, then hosts may interpret the payload of the SYN frame to be > application level data. Joe's portname draft uses options to avoid > this. > > Sergio: Actually they don't, because in that specific case the destination host would have to understand port names. I'm suggesting that if you sent a SYN with a payload and a random destination port to a host, that host, if the port was open, could interpret the payload to be application level data and reply with a SYNACK. Although you would notice that it wouldn't echo your option. > Sergio: Right, in my thesis that was corrected. Thanks. Let me explain how segments are > correlated: src_IP+src_port+dst_IP+dst_port. Since the destination port in SYN may be 0 > and the source port in SYNACK is always the resolved port. So, there must be another field > to correlate, which in this case we decided to use the portname. I understand that you've lost one of the elements of the 4-tuple that identify a connection, I was suggesting that you could just do without it if your source ports for conections were random. There might be a case in which this goes wrong that I'm not thinking of right now. I guess it is rather against the TCP spirit. Fundamentally, I don't believe that this conflicts with my SYNACK payloads draft. The option in the SYNACK can easilly denote the portname from the application level data. Also, SYN crossings are interesting with this scheme. I think they work, but it's complicated. The ACKs, in this case, would also have to include the portname. I think a SYN crossing where one of the sides isn't using the portname to resolve the other goes wrong though. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Aug 12 14:37:33 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DA463A6CAC; Tue, 12 Aug 2008 14:37:33 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8437E3A6CAC for ; Tue, 12 Aug 2008 14:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.956 X-Spam-Level: X-Spam-Status: No, score=-0.956 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKtGn5pJIoFz for ; Tue, 12 Aug 2008 14:37:31 -0700 (PDT) Received: from cgpmail.ua.pt (frontend-1.servers.ua.pt [193.136.173.2]) by core3.amsl.com (Postfix) with ESMTP id C8D743A6C62 for ; Tue, 12 Aug 2008 14:37:29 -0700 (PDT) Received: from [81.193.28.36] (account etfreire@ua.pt HELO portsfreire) by frontend1.cgpmail.ua.pt (CommuniGate Pro SMTP 5.1.13) with ESMTPSA id 118392266; Tue, 12 Aug 2008 22:37:12 +0100 From: "Sergio Freire" To: "'Adam Langley'" References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <000001c8fbfe$0dba0960$292e1c20$@pt> <396556a20808111617n622aceabn62db0d55b25ae712@mail.gmail.com> <000301c8fc81$8e02d470$aa087d50$@pt> <396556a20808120914k6d087534o5c34dfd51dd7d1c5@mail.gmail.com> <000b01c8fc9f$4d9f3c20$e8ddb460$@pt> <396556a20808121155h4e3c551aqcf5260d551bcdd4a@mail.gmail.com> In-Reply-To: <396556a20808121155h4e3c551aqcf5260d551bcdd4a@mail.gmail.com> Date: Tue, 12 Aug 2008 22:37:09 +0100 Message-ID: <000301c8fcc3$938a8450$ba9f8cf0$@pt> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acj8rPLpJTrw3FumQuC8aYNVBeG5nQAFCD+Q Content-Language: pt Cc: andre.zuquete@ua.pt, tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org SGkgQWRhbS4KQWdhaW4sIGlubGluZSA6KQpSZWdhcmRzLApTZXJnaW8gRnJlaXJlCgoKLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0KRnJvbTogYWxhbmdsZXlAZ21haWwuY29tIFttYWlsdG86YWxh bmdsZXlAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgQWRhbSBMYW5nbGV5ClNlbnQ6IHRlcsOnYS1m ZWlyYSwgMTIgZGUgQWdvc3RvIGRlIDIwMDggMTk6NTUKVG86IFNlcmdpbyBGcmVpcmUKQ2M6IGFu ZHJlLnp1cXVldGVAdWEucHQ7IHRjcG1AaWV0Zi5vcmcKU3ViamVjdDogUmU6IFt0Y3BtXSBTWU4v QUNLIFBheWxvYWRzLCBkcmFmdCAwMQoKT24gVHVlLCBBdWcgMTIsIDIwMDggYXQgMTA6MTcgQU0s IFNlcmdpbyBGcmVpcmUgPGV0ZnJlaXJlQHVhLnB0PiB3cm90ZToKPiBTZXJnaW86IEkgdGhpbmsg aXQgd291bGQgYmUgZ3JlYXQgdG8gaGFuZGxlIGFsc28gYWRkaXRpb25hbCBwYXlsb2FkLiBJZiB3 ZSBhcmUgY2hhbmdpbmcgdGhpbmdzIGF0IHRoaXMgbGV2ZWwgSSB0aGluayBpdCB3b3VsZCBiZSBv ZiBncmVhdCB2YWxvciB0byBoYW5kbGUgdGhlIHR3byBjYXNlcyA6KSBJIHN0aWxsIGhhdmUgdG8g bG9vayBjYXJlZnVsbHkgYXQgeW91ciBkcmFmdC4KClNhZGx5LCBJIGRvbid0IGJlbGlldmUgdGhh dCB0aGVyZSBpcyBhIGdvb2Qgd2F5IHRvIGluY2x1ZGUgZXh0cmEKb3B0aW9ucyBzcGFjZSBpbiBh IFNZTiBmcmFtZSBpbiBhIGJhY2t3YXJkcyBjb21wYXRpYmxlIG1hbm5lci4gWW91J3JlCnRyaWNr IG9mIHVzaW5nIHBvcnQgMCBpcyBvbmUgc3VjaCB3YXksIGJ1dCBvYnZpb3VzbHkgdGllcyBpdCB0 byBhbgphbHRlcm5hdGl2ZSBwb3J0IHJlc29sdXRpb24gc2NoZW1lLgoKU2VyZ2lvOiB3ZWxsLCB3 ZSBtdXN0IGZpZ3VyZSBvdXQgdGhlIGJlc3Qgd2F5IHRvIGFjaGlldmUgdGhpcy4gVXNpbmcgYSBk ZXN0aW5hdGlvbiBwb3J0IDAgd2FzIGEgc29sdXRpb24gd2UgZGV2aXNlZCBpbiBvdXIgc3BlY2lm aWMgY2FzZS4gQWdhaW4sIHdlIHdhbnQgdG8gZ2VuZXJhbGl6ZSB0aGlzIGFuZCBjb25zaWRlciBv dGhlciBwb3NzaWJpbGl0aWVzIGxpa2UgdGhlIG9uZSBkZXBpY3RlZCBvbiBteSBuZXh0IGNvbW1l bnQuCgoKCj4gSG93ZXZlciwgaWYgeW91IGFyZW4ndCBzZXR0aW5nIGRwb3J0IHRvIDAgdG8gc2ln bmFsIHRoYXQgdGhlIFNZTiBpcwo+IHNwZWNpYWwsIHRoZW4gaG9zdHMgbWF5IGludGVycHJldCB0 aGUgcGF5bG9hZCBvZiB0aGUgU1lOIGZyYW1lIHRvIGJlCj4gYXBwbGljYXRpb24gbGV2ZWwgZGF0 YS4gSm9lJ3MgcG9ydG5hbWUgZHJhZnQgdXNlcyBvcHRpb25zIHRvIGF2b2lkCj4gdGhpcy4KPgo+ IFNlcmdpbzogQWN0dWFsbHkgdGhleSBkb24ndCwgYmVjYXVzZSBpbiB0aGF0IHNwZWNpZmljIGNh c2UgdGhlIGRlc3RpbmF0aW9uIGhvc3Qgd291bGQgaGF2ZSB0byB1bmRlcnN0YW5kIHBvcnQgbmFt ZXMuCgpJJ20gc3VnZ2VzdGluZyB0aGF0IGlmIHlvdSBzZW50IGEgU1lOIHdpdGggYSBwYXlsb2Fk IGFuZCBhIHJhbmRvbQpkZXN0aW5hdGlvbiBwb3J0IHRvIGEgaG9zdCwgdGhhdCBob3N0LCBpZiB0 aGUgcG9ydCB3YXMgb3BlbiwgY291bGQKaW50ZXJwcmV0IHRoZSBwYXlsb2FkIHRvIGJlIGFwcGxp Y2F0aW9uIGxldmVsIGRhdGEgYW5kIHJlcGx5IHdpdGggYQpTWU5BQ0suIEFsdGhvdWdoIHlvdSB3 b3VsZCBub3RpY2UgdGhhdCBpdCB3b3VsZG4ndCBlY2hvIHlvdXIgb3B0aW9uLgoKU2VyZ2lvOiBZ ZWFwISBUaGF0IGlzIGFuIG9wdGlvbiB3ZSBhcmUgY29uc2lkZXJpbmc6IHJlc2V0dGluZyB0aGUg Y29ubmVjdGlvbiBpZiB0aGUgU1lOQUNLIGRvZXMgbm90IGNvbnRhaW4gdGhlIGdpdmVuIFRDUCBv cHRpb24uCgoKCgo+IFNlcmdpbzogUmlnaHQsIGluIG15IHRoZXNpcyB0aGF0IHdhcyBjb3JyZWN0 ZWQuIFRoYW5rcy4gTGV0IG1lIGV4cGxhaW4gaG93IHNlZ21lbnRzIGFyZQo+IGNvcnJlbGF0ZWQ6 IHNyY19JUCtzcmNfcG9ydCtkc3RfSVArZHN0X3BvcnQuIFNpbmNlIHRoZSBkZXN0aW5hdGlvbiBw b3J0IGluIFNZTiBtYXkgYmUgMAo+IGFuZCB0aGUgc291cmNlIHBvcnQgaW4gU1lOQUNLIGlzIGFs d2F5cyB0aGUgcmVzb2x2ZWQgcG9ydC4gU28sIHRoZXJlIG11c3QgYmUgYW5vdGhlciBmaWVsZAo+ IHRvIGNvcnJlbGF0ZSwgd2hpY2ggaW4gdGhpcyBjYXNlIHdlIGRlY2lkZWQgdG8gdXNlIHRoZSBw b3J0bmFtZS4KCkkgdW5kZXJzdGFuZCB0aGF0IHlvdSd2ZSBsb3N0IG9uZSBvZiB0aGUgZWxlbWVu dHMgb2YgdGhlIDQtdHVwbGUgdGhhdAppZGVudGlmeSBhIGNvbm5lY3Rpb24sIEkgd2FzIHN1Z2dl c3RpbmcgdGhhdCB5b3UgY291bGQganVzdCBkbyB3aXRob3V0Cml0IGlmIHlvdXIgc291cmNlIHBv cnRzIGZvciBjb25lY3Rpb25zIHdlcmUgcmFuZG9tLiBUaGVyZSBtaWdodCBiZSBhCmNhc2UgaW4g d2hpY2ggdGhpcyBnb2VzIHdyb25nIHRoYXQgSSdtIG5vdCB0aGlua2luZyBvZiByaWdodCBub3cu IEkKZ3Vlc3MgaXQgaXMgcmF0aGVyIGFnYWluc3QgdGhlIFRDUCBzcGlyaXQuIEZ1bmRhbWVudGFs bHksIEkgZG9uJ3QKYmVsaWV2ZSB0aGF0IHRoaXMgY29uZmxpY3RzIHdpdGggbXkgU1lOQUNLIHBh eWxvYWRzIGRyYWZ0LiBUaGUgb3B0aW9uCmluIHRoZSBTWU5BQ0sgY2FuIGVhc2lsbHkgZGVub3Rl IHRoZSBwb3J0bmFtZSBmcm9tIHRoZSBhcHBsaWNhdGlvbgpsZXZlbCBkYXRhLgoKU2VyZ2lvOiB5 ZXMsIGJ5IG1haW50YWluaW5nIHRoZSBjb25uZWN0aW9uIGVsZW1lbnRzICh0aGUgNC10dXBsZSkg ZHVyaW5nIGNvbm5lY3Rpb24gc29sdmVzIG1hbnkgcHJvYmxlbXMuIFlldCwgdGhlcmUncyBhIHBv c3NpYmlsaXR5IG9mIGNvbm5lY3RpbmcgdG8gd3Jvbmcgc2VydmljZXMgKGUuZy4gaW1hZ2luZSBh IHNlcnZlciB0aGF0IGlzIGJvdW5kIHRvIHNvbWUgWCBwb3J0Li4uIHRoZSBjbGllbnQgaXNzdWVz IGEgY29ubmVjdGlvbiBhbmQgdGhlIHJhbmRvbWx5IGNob3NlbiBkZXN0aW5hdGlvbiBwb3J0IGF0 IGNsaWVudCBzaWRlIGlzIFguLi4gdGhpcyB3aWxsIGNvbGxpZGUgd2l0aCBhbiBleGlzdGluZyBz ZXJ2aWNlKS4gQnV0IGFnYWluLCB0aGlzIGNhbiBiZSAic29sdmVkIiBsb29raW5nIGF0IHRoZSBT WU5BQ0sgcmVwbHksIGZvciBleGFtcGxlLgpBYm91dCB5b3VyIGRyYWZ0LCBsZXQgbWUgdGFrZSBh IGxvb2sgZmlyc3QuCgoKCkFsc28sIFNZTiBjcm9zc2luZ3MgYXJlIGludGVyZXN0aW5nIHdpdGgg dGhpcyBzY2hlbWUuIEkgdGhpbmsgdGhleQp3b3JrLCBidXQgaXQncyBjb21wbGljYXRlZC4gVGhl IEFDS3MsIGluIHRoaXMgY2FzZSwgd291bGQgYWxzbyBoYXZlIHRvCmluY2x1ZGUgdGhlIHBvcnRu YW1lLiBJIHRoaW5rIGEgU1lOIGNyb3NzaW5nIHdoZXJlIG9uZSBvZiB0aGUgc2lkZXMKaXNuJ3Qg dXNpbmcgdGhlIHBvcnRuYW1lIHRvIHJlc29sdmUgdGhlIG90aGVyIGdvZXMgd3JvbmcgdGhvdWdo LgoKU2VyZ2lvOiBOaWNlIHRoYXQgeW91IHRob3VnaHQgYWJvdXQgdGhpcy4gSW4gZmFjdCwgd2Ug ZGlkbid0IGNvbnNpZGVyZWQgc2ltdWx0YW5lb3VzIGNvbm5lY3Rpb25zIG1haW5seSBiZWNhdXNl IG5vYm9keSBzZWVtcyB0byBiZSB1c2luZyB0aGVtLiAKQmVzaWRlcyB0aGF0LCB0aGUgcGFyYWRp Z20gaXMgbGlrZSBhIGNsaWVudC9zZXJ2ZXIgbW9kZWw6IHRoZSBjbGllbnQgdHJpZXMgdG8gY29u bmVjdCB0byBhIHNlcnZlciB3aGljaCBpcyBib3VuZCB0byBhIG5hbWUuClRoZSBjbGllbnQgaXRz ZWxmIGRvZXMgbm90IGhhdmUgYSBuYW1lLiBTbywgaXQgZG9lcyBub3QgbWFrZSB0b28gbXVjaCBz ZW5zZSB0byB0aGluayBvbiB0aGlzIGNhc2UgdXNpbmcgdGhpcyBwYXJhZGlnbSwgdW5sZXNzIHRo ZSBjb25uZWN0aW9uIGNvbWVzIGZyb20gdGhlIHNvY2tldCBzZXJ2ZXIgYnV0IHRoYXQgZG9lcyBu b3QgbWFrZSBzZW5zZS4KSWYgdGhlIGNsaWVudCBhbmQgdGhlIHNlcnZlciBib3RoIGhhdmUgbmFt ZXMsIHRoZW4gU1lOIGNyb3NzaW5nIHdvdWxkIG1ha2Ugc2Vuc2UuCgoKCkFHTAoKLS0gCkFkYW0g TGFuZ2xleSBhZ2xAaW1wZXJpYWx2aW9sZXQub3JnIGh0dHA6Ly93d3cuaW1wZXJpYWx2aW9sZXQu b3JnCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwp0Y3Bt IG1haWxpbmcgbGlzdAp0Y3BtQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdGNwbQo= From tcpm-bounces@ietf.org Wed Aug 13 01:03:41 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66F863A69D2; Wed, 13 Aug 2008 01:03:41 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DD5E3A69D2; Wed, 13 Aug 2008 01:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuzRaS5BV2cJ; Wed, 13 Aug 2008 01:03:39 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 55EFA3A697D; Wed, 13 Aug 2008 01:03:39 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 2444D198711; Wed, 13 Aug 2008 11:03:42 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id D96311986D6; Wed, 13 Aug 2008 11:03:41 +0300 (EEST) Message-ID: <48A2958C.8020009@piuha.net> Date: Wed, 13 Aug 2008 11:04:28 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Fernando Gont References: <20080717102200.0757D3A69C6@core3.amsl.com> <200807181736.m6IHaWB3006186@venus.xmundo.net> In-Reply-To: <200807181736.m6IHaWB3006186@venus.xmundo.net> X-Virus-Scanned: ClamAV using ClamSMTP Cc: tcpm-chairs@tools.ietf.org, tcpm@ietf.org, david.borman@windriver.com, iesg@ietf.org, weddy@grc.nasa.gov, draft-ietf-tcpm-tcp-soft-errors@tools.ietf.org Subject: Re: [tcpm] DISCUSS: draft-ietf-tcpm-tcp-soft-errors X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Fernando, >> Section 2.1 says: >> >> When receiving an ICMP error message that indicates a hard error >> condition, TCP will simply abort the corresponding connection, >> regardless of the connection state. >> >> Question. I was under the impression that recent specifications have >> started to say to not blindly believe ICMP errors due to denial- >> of-service concerns? If this is not the case, then no problem. > > I'm the author of the TCPM WG's "ICMP attacks against TCP draft". > While that draft was initially meant for the informational track, it > is now aims at "Informational". So, even when virtually all current > implementations behave as you describe, the IETF specifications remain > unchanged. Ok. Perhaps it would be useful to state something about reality as well -- even if you do not recommend something else, I think you should acknowledge the fact that virtually all implementations behave differently. >> Section 3.2 says: >> >> In scenarios where a node has no default routers and Neighbor >> Unreachability Detection (NUD) [RFC4861] fails for destinations >> assumed to be on-link, or where firewalls or other systems that >> enforce scope boundaries send ICMPv6 errors, the sending node will be >> signaled of the unreachability problem. However, as discussed in >> Section 2.2, standard TCP implementations will not abort connections >> when receiving ICMP error messages that indicate soft errors. >> >> Clarity. This is somewhat misleading. When the node has no default >> routers it also has no prefixes, no global addresses and it will not >> even try to use IPv6 towards other global addresses. > > Why not? What if a Router Advertisement has a "Router Lifetime" of 0? > Am I missing something? Ah, I didn't think of this case. I'll leave it up to you if you want to edit the text to clarify what you mean. (I don't require you to and I'm not certain that it is needed.) Jari _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Aug 13 01:49:53 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 853A33A6AD0; Wed, 13 Aug 2008 01:49:53 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33E233A6A53; Wed, 13 Aug 2008 01:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=1.121, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RECV_SPEEDY_AR=0.808] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDdosFjE6q9q; Wed, 13 Aug 2008 01:49:51 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 23AAD3A6A73; Wed, 13 Aug 2008 01:49:49 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 179DB6B6805; Wed, 13 Aug 2008 05:49:48 -0300 (ART) Received: from notebook.gont.com.ar (201-254-43-199.speedy.com.ar [201.254.43.199] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.13.8) with ESMTP id m7D8ngss006153; Wed, 13 Aug 2008 05:49:43 -0300 Message-Id: <200808130849.m7D8ngss006153@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 13 Aug 2008 05:44:10 -0300 To: Jari Arkko From: Fernando Gont In-Reply-To: <48A2958C.8020009@piuha.net> References: <20080717102200.0757D3A69C6@core3.amsl.com> <200807181736.m6IHaWB3006186@venus.xmundo.net> <48A2958C.8020009@piuha.net> Mime-Version: 1.0 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Wed, 13 Aug 2008 05:49:47 -0300 (ART) Cc: tcpm-chairs@tools.ietf.org, tcpm@ietf.org, david.borman@windriver.com, iesg@ietf.org, weddy@grc.nasa.gov, draft-ietf-tcpm-tcp-soft-errors@tools.ietf.org Subject: Re: [tcpm] DISCUSS: draft-ietf-tcpm-tcp-soft-errors X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 05:04 a.m. 13/08/2008, Jari Arkko wrote: >>I'm the author of the TCPM WG's "ICMP attacks against TCP draft". >>While that draft was initially meant for the informational track, >>it is now aims at "Informational". So, even when virtually all >>current implementations behave as you describe, the IETF >>specifications remain unchanged. > >Ok. Perhaps it would be useful to state something about reality as >well -- even if you do not recommend something else, I think you >should acknowledge the fact that virtually all implementations >behave differently. I'd be more than pleased to do it. The only reason for which I didn't is that we had very heated debates on the ICMP attacks stuff on the TCPM WG mailing-list, and thus I didn't want to start the debate over again in the context of this draft. I will prepare some text, and ask for comments. Does it sound reasonable? >>>Section 3.2 says: >>> >>>In scenarios where a node has no default routers and Neighbor >>>Unreachability Detection (NUD) [RFC4861] fails for destinations >>>assumed to be on-link, or where firewalls or other systems that >>>enforce scope boundaries send ICMPv6 errors, the sending node will be >>>signaled of the unreachability problem. However, as discussed in >>>Section 2.2, standard TCP implementations will not abort connections >>>when receiving ICMP error messages that indicate soft errors. >>> >>>Clarity. This is somewhat misleading. When the node has no default >>>routers it also has no prefixes, no global addresses and it will not >>>even try to use IPv6 towards other global addresses. >> >>Why not? What if a Router Advertisement has a "Router Lifetime" of >>0? Am I missing something? > >Ah, I didn't think of this case. I'll leave it up to you if you want >to edit the text to clarify what you mean. (I don't require you to >and I'm not certain that it is needed.) Same here. Will come back to you asap with some proposed text. Thanks! -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Aug 13 10:17:32 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4881428C0E7; Wed, 13 Aug 2008 10:17:32 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 621493A68B9 for ; Wed, 13 Aug 2008 10:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.836 X-Spam-Level: X-Spam-Status: No, score=-1.836 tagged_above=-999 required=5 tests=[AWL=0.763, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwvZd7LtbedS for ; Wed, 13 Aug 2008 10:17:30 -0700 (PDT) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 6E2063A6A31 for ; Wed, 13 Aug 2008 10:17:30 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id AA7A650846; Wed, 13 Aug 2008 10:27:52 -0700 (PDT) Date: Wed, 13 Aug 2008 10:27:52 -0700 From: Eric Rescorla To: "Adam Langley" In-Reply-To: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080813172752.AA7A650846@romeo.rtfm.com> Cc: tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org $Id: draft-agl-tcpm-sadata-01-rev.txt,v 1.2 2008/08/13 16:15:00 ekr Exp $ I don't really have a strong opinion about whether this extension should be approved for use with TCP; that's for the TCP experts to decide. However, I don't find motivational use cases--particularly the cryptographic use cases listed in S 4 and S 4--particularly motivating. S 4. Opportunistic HTTP Encryption As the draft states, this is intended to provide opportunistic security without burning any round trips in the application layer. As I understand this mechanism, what's being proposed is this: Client Server ------ ------ SYN + PPExt -> <- SYN/ACK + PPExt + [Crypto stuff] [Crypto Stuff] -> [HTTP Req] Do I have that right? I see a number of issues here: 1. The PPExt payload is overloaded here. First, it's signalling a transport message "it's OK to put stuff in the SYN/ACK". Second, it's signalling an application layer message "It's OK to send me a crypto handshake as the first thing you send." Note that in an ordinary HTTP connection, this data would be invalid. This overloading seems fairly unwise, since it would preclude any other use of this SYN/ACK payload in the future. If the server is going to send non-HTTP compliant data in response to this option, then more information needs to be signalled than just "I would accept data". 2. It's not clear to me that opportunistic security for HTTP is that great. Unlike, for instance, SMTP, HTTP fetches are nearly always the result of some URI, so it's very easy to simply indicate in the URI that the server supports HTTPS. This is superior from a security perspective for the usual reasons (referential integrity, etc...) 3. There are a number of mechanisms for optimizing the performance of TLS vis-a-vis round trips that have not yet been explored (e.g., Fast-Track [BSR04]). It's not clear if we can shave things down to zero RTTs (though I've got some ideas), but it seems that if we're really concerned about crypto setup time it would be worth exploring this before we start with a new security layer, especially because of point (2) above. 4. Some of the latency benefit you're getting here is from not negotiating the crypto algorithms; this is why in TLS the client speaks first. This isn't an issue for the symmetric algorithm since the server could provide a list, but it's a real issue for the asymmetric algorithm, since it provides no agility in the case of upgrade or compromise. If, for instance, someone successfully attacks this curve but there are other, strong curves available, then we'd be hosed. S 5. Faster SSH Connections It's true that SSH latency is really bad, but it's really much worse than you suggest, since the authentication handshake takes several exchanges as well. [GutXX] It's not clear to me that removing 1 RTT helps here. I'm skeptical that there are really that many applications that involve bringing up and tearing down a lot of SSH connections. Moreover, since SSH involves a lot of connections between the same pair of nodes, it seems like a TLS style session caching mechanism would improve the situation a lot more, optimizing out nearly all round trips for subsequent connections, while also reducing public key load while again requiring no changes to the kernel. S 6. Compressed HTTP Headers I don't know how much value this adds, but note that the server's indication that it supports compressed headers lives in the same section of the datastream as the crypto stuff from S 5. So, we now need some sort of framing mechanism for this data to allow clients which know about opportunistic crypto but not compressed headers to ignore that advertisement. [BSR04] H. Shacham, D. Boneh, and E. Rescorla. "Client-Side Caching for TLS." ACM Trans. Info. & Sys. Security, 7(4):553-75, Nov. 2004. [GutXX] P. Gutmann, "Performance Characteristics of Application-Level Security Protocols," Work in Progress. -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Aug 13 10:48:05 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3BEB3A6852; Wed, 13 Aug 2008 10:48:05 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 043303A6852 for ; Wed, 13 Aug 2008 10:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.457 X-Spam-Level: X-Spam-Status: No, score=-1.457 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jp+E3OqwFmoZ for ; Wed, 13 Aug 2008 10:48:03 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by core3.amsl.com (Postfix) with ESMTP id D0DD13A67F3 for ; Wed, 13 Aug 2008 10:48:03 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so74232rvf.49 for ; Wed, 13 Aug 2008 10:47:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=RA9do/Qv7uwl1eDHpuq3HTTN01gzcxAetPRdgvNcDMI=; b=YkUrh8m8Ckxy+swtAQ0ompMpLea++Y3sRAlpK0KaMO+HKVuGJT7JvwEKVcMZM/fnFM X1O2SqLekSf3uItPte/Y3sK/e+T7XUG0r0I+G8ZmkSGVCaD4jl0oNmh95Bldo3RGb2nH FvTpeRaYUwP2i2gIS28vRtT2jgb6owMVUcA+g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=cOL7bbw1IMHMha+G4oUj44SscyeSbRGMI/4ZFHtrYkPoHKYdlbMDsJ0zHrYlw/rJ7F xHGgOLZixkfGSoD4HieyVH1Ihj2cc7f67mYbehTecIIPpm6357DMwN6B9j4bKrOmgBBD fSIgowlTbqWOztXGlLfI2lNZl8fWdlu12bcUA= Received: by 10.141.176.13 with SMTP id d13mr73825rvp.196.1218649677134; Wed, 13 Aug 2008 10:47:57 -0700 (PDT) Received: by 10.141.37.3 with HTTP; Wed, 13 Aug 2008 10:47:57 -0700 (PDT) Message-ID: <396556a20808131047q781675a3if23d727ef5ae918f@mail.gmail.com> Date: Wed, 13 Aug 2008 10:47:57 -0700 From: "Adam Langley" To: "Eric Rescorla" In-Reply-To: <20080813172752.AA7A650846@romeo.rtfm.com> MIME-Version: 1.0 Content-Disposition: inline References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <20080813172752.AA7A650846@romeo.rtfm.com> X-Google-Sender-Auth: e14f5e4e880ec2db Cc: tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Wed, Aug 13, 2008 at 10:27 AM, Eric Rescorla wrote: > S 4. Opportunistic HTTP Encryption > > As I understand this mechanism, what's being proposed is this: [snip] > Do I have that right? Yep, > 1. The PPExt payload is overloaded here. First, it's signalling > a transport message "it's OK to put stuff in the SYN/ACK". Second, > it's signalling an application layer message "It's OK to send me > a crypto handshake as the first thing you send." Note that in > an ordinary HTTP connection, this data would be invalid. Actually, it's only signaling the application extension. The SYNACK payloads are valid in any TCP connection, although this spec does make some guarantees about weather the stacks will process them. > This overloading seems fairly unwise, since it would preclude > any other use of this SYN/ACK payload in the future. The format of the SYNACK payload for this scheme is similar to the option space: i.e. it's a tagged, extensible payload. > 2. It's not clear to me that opportunistic security for HTTP is that > great. Unlike, for instance, SMTP, HTTP fetches are nearly always > the result of some URI, so it's very easy to simply indicate > in the URI that the server supports HTTPS. This is superior > from a security perspective for the usual reasons (referential > integrity, etc...) I believe that there's a use for a low-cost cryptographic scheme, such as this. Despite widespread TLS deployment, most traffic is still in the clear, including semi-sensitive information. I would rather that traffic be protected with TLS but, since that isn't happening, I would rather this than nothing. Opinions on this vary. Some folks think it's a great idea (including some working on implementing the TLS Fast-Track you cite below), some, like you are unimpressed. Fundamentally, I'm only asking for an option number to try it out. > 4. Some of the latency benefit you're getting here is from not > negotiating the crypto algorithms; this is why in TLS the > client speaks first. This isn't an issue for the symmetric > algorithm since the server could provide a list, but it's > a real issue for the asymmetric algorithm, since it provides > no agility in the case of upgrade or compromise. If, for > instance, someone successfully attacks this curve but there > are other, strong curves available, then we'd be hosed. Firstly, this isn't rigorous crypto, so the primitives here are in the enviable situation of being good enough if it's infeasible to break them in near-real time. If you want real security, use TLS. As mentioned above, the SYNACK payload is a tagged structure. Since there are very tight space constraints it probably wouldn't be possible to offer several elliptic curve points, but if curve25519 were totally broken there is a gradual upgrade path by upgrading clients and then switching servers to offer another tag with a different curve. Older clients would fall back to no encryption, but it doesn't require a flag day. > It's true that SSH latency is really bad, but it's really much > worse than you suggest, since the authentication handshake takes > several exchanges as well. [GutXX] It's not clear to me that removing > 1 RTT helps here. I'm skeptical that there are really that > many applications that involve bringing up and tearing down > a lot of SSH connections. You're correct. This isn't the greatest example, I was just looking for some diversity to suggest that this isn't limited to HTTP. > S 6. Compressed HTTP Headers > I don't know how much value this adds, but note that the server's > indication that it supports compressed headers lives in the same > section of the datastream as the crypto stuff from S 5. So, we > now need some sort of framing mechanism for this data to allow > clients which know about opportunistic crypto but not compressed > headers to ignore that advertisement. Yep. Again, the framing mechanism already exists, although it's not specified in the draft because it's not in scope for a TCPM draft. The framing mechanism also allows for any other crazy HTTP (or any other "client transmits first") protocol extensions in the future. I think that, even if you don't much care for the opportunistic encryption, that's fairly powerful. Cheers AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Aug 13 11:05:47 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 268E63A6990; Wed, 13 Aug 2008 11:05:47 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D8343A683E for ; Wed, 13 Aug 2008 11:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.944 X-Spam-Level: X-Spam-Status: No, score=-0.944 tagged_above=-999 required=5 tests=[AWL=1.655, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-3OMVWb6hN2 for ; Wed, 13 Aug 2008 11:05:44 -0700 (PDT) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 6CB233A6A0B for ; Wed, 13 Aug 2008 11:05:44 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id A1E6750848; Wed, 13 Aug 2008 11:16:30 -0700 (PDT) Date: Wed, 13 Aug 2008 11:16:30 -0700 From: Eric Rescorla To: "Adam Langley" In-Reply-To: <396556a20808131047q781675a3if23d727ef5ae918f@mail.gmail.com> References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <20080813172752.AA7A650846@romeo.rtfm.com> <396556a20808131047q781675a3if23d727ef5ae918f@mail.gmail.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080813181630.A1E6750848@romeo.rtfm.com> Cc: tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At Wed, 13 Aug 2008 10:47:57 -0700, Adam Langley wrote: > > On Wed, Aug 13, 2008 at 10:27 AM, Eric Rescorla > wrote: > > S 4. Opportunistic HTTP Encryption > > > > As I understand this mechanism, what's being proposed is this: > [snip] > > Do I have that right? > > Yep, > > > 1. The PPExt payload is overloaded here. First, it's signalling > > a transport message "it's OK to put stuff in the SYN/ACK". Second, > > it's signalling an application layer message "It's OK to send me > > a crypto handshake as the first thing you send." Note that in > > an ordinary HTTP connection, this data would be invalid. > > Actually, it's only signaling the application extension. The SYNACK > payloads are valid in any TCP connection, although this spec does make > some guarantees about weather the stacks will process them. I'm srory, I don't understand what you're saying here. Does this data appear to the application to be part of the data stream or not? > > This overloading seems fairly unwise, since it would preclude > > any other use of this SYN/ACK payload in the future. > > The format of the SYNACK payload for this scheme is similar to the > option space: i.e. it's a tagged, extensible payload. OK, this wasn't entirely clear from reading the draft. > > 2. It's not clear to me that opportunistic security for HTTP is that > > great. Unlike, for instance, SMTP, HTTP fetches are nearly always > > the result of some URI, so it's very easy to simply indicate > > in the URI that the server supports HTTPS. This is superior > > from a security perspective for the usual reasons (referential > > integrity, etc...) > > I believe that there's a use for a low-cost cryptographic scheme, such > as this. Despite widespread TLS deployment, most traffic is still in > the clear, including semi-sensitive information. I would rather that > traffic be protected with TLS but, since that isn't happening, I would > rather this than nothing. But the premise of this scheme is that people don't do TLS because of either (1) latency or (2) lack of opportunistic negotiation. As far as I can tell, neither is correct. Rather, it's concerns about server performance. And server performance can be improved by a number of mechanisms within TLS that are (1) backward compatible with TLS and (2) don't require modifying the kernel. That said, if you're willing to burn even very small amounts of data in the SYN, you can do something TLS-compatible by passing a compressed ClientHello of some kind + FastTrack. This only works with static RSA one the server side, but so does the scheme you propose. > Opinions on this vary. Some folks think it's a great idea (including > some working on implementing the TLS Fast-Track you cite below), some, > like you are unimpressed. Fundamentally, I'm only asking for an option > number to try it out. As I indicated earlier, I'm not taking a position on whether you should be assigned an > > 4. Some of the latency benefit you're getting here is from not > > negotiating the crypto algorithms; this is why in TLS the > > client speaks first. This isn't an issue for the symmetric > > algorithm since the server could provide a list, but it's > > a real issue for the asymmetric algorithm, since it provides > > no agility in the case of upgrade or compromise. If, for > > instance, someone successfully attacks this curve but there > > are other, strong curves available, then we'd be hosed. > > Firstly, this isn't rigorous crypto, so the primitives here are in the > enviable situation of being good enough if it's infeasible to break > them in near-real time. If you want real security, use TLS. Yeah, I'm not a big fan of inventing new things we know to be weaker than the old things we already have, especially when the benefit claimed by the newer thing seems marginal. -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Aug 13 11:45:16 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37F5D3A6B76; Wed, 13 Aug 2008 11:45:14 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A18243A69E8 for ; Wed, 13 Aug 2008 11:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.544 X-Spam-Level: X-Spam-Status: No, score=-1.544 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHZvkuWi8eqr for ; Wed, 13 Aug 2008 11:45:04 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by core3.amsl.com (Postfix) with ESMTP id C19B13A6907 for ; Wed, 13 Aug 2008 11:45:03 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so93327rvf.49 for ; Wed, 13 Aug 2008 11:45:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=XRMZLLKrJHxGgsh5m2VNoZJbBecJ3gLaN3RsTWALdDg=; b=vhLgVkLZnQrvtZWPklGZWmeQUHjL0XEjrzdDwDuyXr+iR83NwWpTHkfZ9WLn2Euyil ITF5YV6e/4OTQ0Sme39IXrcXgU+mHxetVahQ4E8XFLIEmXh+56VOeU+jFmRCb2AH6UdV easpyFKnKttGNDjwOpOY9ZPqgNxfXhiBTQ4Ao= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=P8DjGCjvtbn1QErlO/z+2M7eS8MiQxBaag/A2SD4Rn4HEzwNy6jzmCuUTR9JqckJAI IEoBXQgeTtowQ2uqsiip58Ru0TXDDqWwy4kqv3jFQFdqxsY0h8OVhOL7n09nxTNWqUjv qFwtY7P/vr/TkYrCJT2jisiKyNdWehLTo4Zio= Received: by 10.141.163.12 with SMTP id q12mr128498rvo.190.1218653107397; Wed, 13 Aug 2008 11:45:07 -0700 (PDT) Received: by 10.141.37.3 with HTTP; Wed, 13 Aug 2008 11:45:07 -0700 (PDT) Message-ID: <396556a20808131145y1be0fb4saeb7bbf74d078268@mail.gmail.com> Date: Wed, 13 Aug 2008 11:45:07 -0700 From: "Adam Langley" To: "Eric Rescorla" In-Reply-To: <20080813181630.A1E6750848@romeo.rtfm.com> MIME-Version: 1.0 Content-Disposition: inline References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <20080813172752.AA7A650846@romeo.rtfm.com> <396556a20808131047q781675a3if23d727ef5ae918f@mail.gmail.com> <20080813181630.A1E6750848@romeo.rtfm.com> X-Google-Sender-Auth: 094beb542436a443 Cc: tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Wed, Aug 13, 2008 at 11:16 AM, Eric Rescorla wrote: > I'm srory, I don't understand what you're saying here. Does this > data appear to the application to be part of the data stream > or not? Yes, the data is part of the application stream. However, including a payload in the SYN/ACK frame is permitted by TCP. Thus application protocols in which the server speaks first could include payloads in the SYN/ACK today, with no changes. Admittedly many stacks will only ACK the SYN flag and not the data, so the data has to be retransmitted, but the changes needed don't need any standard work. The option proposed here is just for "client speaks first" to escape that mode and switch to a "server speaks first" mode. > OK, this wasn't entirely clear from reading the draft. I didn't include it in the draft because it seemed out of scope, but maybe I should since attentive readers are obviously picking up on it. > But the premise of this scheme is that people don't do TLS > because of either (1) latency or (2) lack of opportunistic > negotiation. As far as I can tell, neither is correct. Rather, > it's concerns about server performance. And server performance > can be improved by a number of mechanisms within TLS that > are (1) backward compatible with TLS and (2) don't require > modifying the kernel. (1) is certainly a concern today. Even a single round trip. Most actual numbers on this are considered secrets by the organisations in a good place to gather them, but here's one soundbite: "every 100ms of latency costs Amazon 1% of profit" http://radar.oreilly.com/2008/08/radar-theme-web-ops.html (2) is also a concern: simply put, users type http by habit. Additionally, getting TLS certificates is a pain for small sites. As for server load, curve25519 can be performed in 240us on a Core2 and Salsa20/8 runs at 2 cycles/byte (same hardware). That reduces server load. But, really, I don't really know the reasons why TLS isn't ubiquitous even with ubiquitous support. But, given that it isn't, I'm looking to the best that I can with a very low-cost (i.e. computation, latency) system. I should also add another point of the opportunistic encryption scheme that isn't covered in the draft: When in effect, servers may return an X-ObsTCP: header that specifies an https URL to a document that contains a list of Diffie-Hellman public values and validity time periods for each. (The hostname is required to match.) It's hoped that client's can cache it and validate keys in the future. (Credit to Markus Gutschke from the Google security team for that. However, as you point out, there's another route here: additional TLS. One of the tags that I have penciled in for the SYNACK payloads is "TLS upgrade" - e.g. the server can advertise TLS support without a round trip. With client-side context caching, that can be setup with only one extra RTT in the optimal case (2 otherwise I believe). The reason that I didn't include that as an explicit example is because it can be downgrade attacked (obviously) and so, it might actually be counter productive because it wouldn't teach users to type "https". However, if you have ideas for a zero RTT TLS, please send them my way (possibly off list in that case). If there's a possibility to use something standard(ish) with no additional latency I'll use it. > That said, if you're willing to burn even very small amounts > of data in the SYN, you can do something TLS-compatible by > passing a compressed ClientHello of some kind + FastTrack. > This only works with static RSA one the server side, but > so does the scheme you propose. I can reasonably fit 14 bytes in a SYN frame. I did consider trying to get RSA in the SYN (because then the computation costs could be mostly put on the server), but I don't think I can fit anything useful in there. (Not even a good elliptic key). AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Aug 13 12:39:59 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A28E3A6ACF; Wed, 13 Aug 2008 12:39:59 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 179F228C1AB for ; Wed, 13 Aug 2008 12:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.081 X-Spam-Level: X-Spam-Status: No, score=-1.081 tagged_above=-999 required=5 tests=[AWL=1.518, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqsgpTtIaUFI for ; Wed, 13 Aug 2008 12:39:52 -0700 (PDT) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id F3E6628C1AF for ; Wed, 13 Aug 2008 12:39:51 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id C4C5B50848; Wed, 13 Aug 2008 12:50:27 -0700 (PDT) Date: Wed, 13 Aug 2008 12:50:27 -0700 From: Eric Rescorla To: "Adam Langley" In-Reply-To: <396556a20808131145y1be0fb4saeb7bbf74d078268@mail.gmail.com> References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <20080813172752.AA7A650846@romeo.rtfm.com> <396556a20808131047q781675a3if23d727ef5ae918f@mail.gmail.com> <20080813181630.A1E6750848@romeo.rtfm.com> <396556a20808131145y1be0fb4saeb7bbf74d078268@mail.gmail.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080813195027.C4C5B50848@romeo.rtfm.com> Cc: tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At Wed, 13 Aug 2008 11:45:07 -0700, Adam Langley wrote: > > On Wed, Aug 13, 2008 at 11:16 AM, Eric Rescorla > wrote: > > I'm srory, I don't understand what you're saying here. Does this > > data appear to the application to be part of the data stream > > or not? > > Yes, the data is part of the application stream. However, including a > payload in the SYN/ACK frame is permitted by TCP. Thus application > protocols in which the server speaks first could include payloads in > the SYN/ACK today, with no changes. Admittedly many stacks will only > ACK the SYN flag and not the data, so the data has to be > retransmitted, but the changes needed don't need any standard work. > > The option proposed here is just for "client speaks first" to escape > that mode and switch to a "server speaks first" mode. Right, but this has application-level semantics because the content of the server's data is not what an unmodified client expects. So, it's not just a timing issue: the server sends different data to the client if this option is included or not. > > OK, this wasn't entirely clear from reading the draft. > > I didn't include it in the draft because it seemed out of scope, but > maybe I should since attentive readers are obviously picking up on it. > > > But the premise of this scheme is that people don't do TLS > > because of either (1) latency or (2) lack of opportunistic > > negotiation. As far as I can tell, neither is correct. Rather, > > it's concerns about server performance. And server performance > > can be improved by a number of mechanisms within TLS that > > are (1) backward compatible with TLS and (2) don't require > > modifying the kernel. > > (1) is certainly a concern today. Even a single round trip. Most > actual numbers on this are considered secrets by the organisations in > a good place to gather them, but here's one soundbite: > > "every 100ms of latency costs Amazon 1% of profit" > http://radar.oreilly.com/2008/08/radar-theme-web-ops.html Well, this is just an unsupported claim in the presentation, so I have no idea what the underlying data is. However, superficially I find it deeply implausible. I have a Comcast business line, a fast computer, and a modern version of Firefox and it takes about 5 seconds to load Amazon's home page. There are lots of things Amazon could do to improve that performance (e.g., show me less images on the main page). Given that they don't, it's pretty hard to take complaints about a couple of hundred ms latency seriously. > (2) is also a concern: simply put, users type http by habit. And the servers could say "use TLS next time" and the browsers could remember that. > Additionally, getting TLS certificates is a pain for small sites. Huh? I've done this. It's cheap (< $50/yr) and simple (< 10 minutes). > As > for server load, curve25519 can be performed in 240us on a Core2 and > Salsa20/8 runs at 2 cycles/byte (same hardware). That reduces server > load. You're conflating unrelated issues, since TLS is perfectly capable of using these algorithms, if someone thought it was worth defining a cipher suite. > But, really, I don't really know the reasons why TLS isn't ubiquitous > even with ubiquitous support. But, given that it isn't, I'm looking to > the best that I can with a very low-cost (i.e. computation, latency) > system. This sounds to me like a classic case of premature optimization. For all you know the reason TLS isn't ubiquitous is that it doesn't have a cool name. Maybe we should work on that instead. > > That said, if you're willing to burn even very small amounts > > of data in the SYN, you can do something TLS-compatible by > > passing a compressed ClientHello of some kind + FastTrack. > > This only works with static RSA one the server side, but > > so does the scheme you propose. > > I can reasonably fit 14 bytes in a SYN frame. I did consider trying to > get RSA in the SYN (because then the computation costs could be mostly > put on the server), but I don't think I can fit anything useful in > there. (Not even a good elliptic key). I'm talking about a different dataflow. your dataflow is: Client Server ------ ------ SYN + PPExt -> <- SYN/ACK + PPExt + [Crypto stuff] [Crypto Stuff] -> [HTTP Req] Consider the basic TLS handshake from 4346: ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data But the client can techncially start sending data as soon as it has sent Finished, so that leaves us with: ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> Application Data Which is the same number of messages as in your example. The problem is now sending them before the 3-way handshake completes. The Server's first message can be stuffed in the SYN/ACK payload, but the ClientHello cannot be stuffed in a SYN option. But if you were willing to define compressed versions of the most common ClientHello options, you could just say in the SYN option "I speak package 9" and then the server could send the ServerHello right away. You'd need to move some of the ClientHello (e.g., the Random) to the Client's first real message, but that's technically feasible. -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Aug 13 13:04:39 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA0243A6B7F; Wed, 13 Aug 2008 13:04:39 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4871A3A6D01 for ; Wed, 13 Aug 2008 13:04:38 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFNlX3UOTtpr for ; Wed, 13 Aug 2008 13:04:32 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id D04253A6928 for ; Wed, 13 Aug 2008 13:04:32 -0700 (PDT) Received: from [75.214.62.35] (35.sub-75-214-62.myvzw.com [75.214.62.35]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m7DK3qtC019892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Aug 2008 13:03:55 -0700 (PDT) Message-ID: <48A33DFD.7060502@isi.edu> Date: Wed, 13 Aug 2008 13:03:09 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Ted Faber References: <48A08295.8090903@juniper.net> <20080811184214.B300B50846@romeo.rtfm.com> <03d901c8fbe9$05673220$23d946ab@cisco.com> <20080811234626.GB2194@zod.isi.edu> In-Reply-To: <20080811234626.GB2194@zod.isi.edu> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: 'Adam Langley' , tcpm@ietf.org, Dan Wing Subject: Re: [tcpm] tcp-auth-opt issue: support for NATs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, all, I think the discussion on the issue of keyID uniqueness and the size of the keyID space indicates a deeper issue about keyIDs, as well as the TCP-AO option. The keyID is currently only an *intra-connection* identifier. It's sole purpose is to avoid testing multiple concurrent keys and configurations on a single connection, as would occur during rekeying. The primary security association identifier for a connection is the socket pair (addr/port pair). The TCP-AO option provides authentication; it does not provide automated ~ key or parameter negotiation. IMO, that is better left to an automated KMS. - --- There are certainly a number of issues that all appear to require more than simple, static keying in TCP-AO can handle: - dynamic endpoint address assignment - NATs - passive open with floating source IP address IMO, these can - and should - be handled more easily by an automated KMS. This would leave TCP-AO much simpler and easier to validate. The alternatives are problematic: - create and manage our own unique connection ID space - test all concurrently overlapping keys/configurations until each connection is resolved I thus feel that it's OK to say that the simplest static key configuration of TCP-AO solves some problems and not others. The problems we can solve (or have already solved) are: - unique per-connection keys (based on ISNs) - replay prevention using automated key rollover - passive open with floating source port only Solving NATs, dynamic IP address assignments, and full passive opens for statically configured keys will, AFAICT, require relaxing authentication to the point where we will end up developing an in-band KMS in the SYN packet, which I feel is complexity we can avoid. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkijPfwACgkQE5f5cImnZrtyvwCgs+QPQ0rBD+rm8sx5Um75/Dss eFIAoLeNaG8fZh7DjIHJsCUYorqKOUki =0aQt -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Aug 13 13:07:48 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B0D628C16E; Wed, 13 Aug 2008 13:07:48 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3E613A6990 for ; Wed, 13 Aug 2008 13:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.606 X-Spam-Level: X-Spam-Status: No, score=-1.606 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ubUMx+qvt73 for ; Wed, 13 Aug 2008 13:07:41 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by core3.amsl.com (Postfix) with ESMTP id 494F33A6870 for ; Wed, 13 Aug 2008 13:07:41 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so122269rvf.49 for ; Wed, 13 Aug 2008 13:07:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=oWKAuBb4cadRYIF9nY7V9ss57WFm5sLL4WViyoLW280=; b=Ll/d1dIilYZVag6s8s3O5pqzAJaMsyrkb3Ph535QdQ3IL8WZZ7n0TLGYXHIXaAk6P4 SL0+sZPZjYtQ/eXA+iCjMx3AZDWRrL3DRCn770mDqjWnof2RVKLyaQbRg6PUIxOxz+N+ dTANPGwgugNF4T2/juqE8BXzmOTUTfc7CBr/Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=lNGL4M+1ri+DCBH24auZHLNb2W/MLggvoVePRA46NyKvL5wSMq+v8pG+2jJV3qaBVq KLsOk9T0NBaEnPiQYF7say4/LOSJlV7cRtX4Y4oAubuqGZJdtFECE7vEl3caiNwrykPN wVkLhKAt9IioXyUsLwMPllmuiyINOA1CGOYQ8= Received: by 10.140.163.3 with SMTP id l3mr184401rve.55.1218658065099; Wed, 13 Aug 2008 13:07:45 -0700 (PDT) Received: by 10.141.37.3 with HTTP; Wed, 13 Aug 2008 13:07:45 -0700 (PDT) Message-ID: <396556a20808131307r65a9f6a0oe4365be029620b2c@mail.gmail.com> Date: Wed, 13 Aug 2008 13:07:45 -0700 From: "Adam Langley" To: "Eric Rescorla" In-Reply-To: <20080813195027.C4C5B50848@romeo.rtfm.com> MIME-Version: 1.0 Content-Disposition: inline References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <20080813172752.AA7A650846@romeo.rtfm.com> <396556a20808131047q781675a3if23d727ef5ae918f@mail.gmail.com> <20080813181630.A1E6750848@romeo.rtfm.com> <396556a20808131145y1be0fb4saeb7bbf74d078268@mail.gmail.com> <20080813195027.C4C5B50848@romeo.rtfm.com> X-Google-Sender-Auth: 440909a7c5e1257d Cc: tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Wed, Aug 13, 2008 at 12:50 PM, Eric Rescorla wrote: > Right, but this has application-level semantics because the content > of the server's data is not what an unmodified client expects. So, > it's not just a timing issue: the server sends different data > to the client if this option is included or not. Yes, it absolutely has application level semantics, that's its purpose: "Modifications to take advantage of SYNACK payloads would then require changes to the application level protocol ... Because of this, we also describe a TCP option that lets the application layer on both sides ... agree to use an alternative protocol which takes advantage of it." > Well, this is just an unsupported claim in the presentation, so I have > no idea what the underlying data is. However, superficially I find it > deeply implausible. As I suggested, this data is considered secret by the organisations who have it. But I can say that, had I suggested an opportunistic system that required an extra round trip, various teams here (at Google) would have (rightfully) laughed at me. I know that sucks as an argument, but I can't release company data. I'm a bit stuck here sadly. >> (2) is also a concern: simply put, users type http by habit. > > And the servers could say "use TLS next time" and the browsers could > remember that. And that's not a bad idea either. If I get around to it I might sketch something like that out and see what the Mozilla folks think of it. > But the client can techncially start sending data as soon as it has > sent Finished, so that leaves us with: > > > ClientHello --------> > ServerHello > Certificate* > ServerKeyExchange* > CertificateRequest* > <-------- ServerHelloDone > Certificate* > ClientKeyExchange > CertificateVerify* > [ChangeCipherSpec] > Finished --------> > Application Data > > Which is the same number of messages as in your example. The problem > is now sending them before the 3-way handshake completes. > > The Server's first message can be stuffed in the SYN/ACK payload, but > the ClientHello cannot be stuffed in a SYN option. But if you were > willing to define compressed versions of the most common ClientHello > options, you could just say in the SYN option "I speak package 9" and > then the server could send the ServerHello right away. You'd need to > move some of the ClientHello (e.g., the Random) to the Client's first > real message, but that's technically feasible. At which point, I think we have basically the same scheme, but with different names! ClientHello (1 bit) ----> <----- ServerHello, ServerHelloDone ClientRandom, Finished, Application Data -----> For implementation reasons I'm reducing the "I speak package 9" to a single bit. The sockets API makes it very painful to have applications process each SYN frame. One could imagine giving the kernel a list of different payloads to send in the case of different options in the SYN, but I didn't for complexity reasons. The major advantage would be that we could more easily recover from primitive compromise but, as I've outlined in a previous email, the tagged nature of the payload makes it doable anyway. We can't fit any certificates in the ServerHello and (unless we're moving this into the kernel) the key agreement value has to be constant. So we define a new cipher spec for a Diffie-Hellman function that works in the face of constant public values and is very fast (curve25519). I, indeed, put the client's random in the first real message. I could support client certificates with the tagged structure, currently I don't. So, given the space constraints, it's largely isomorphic, right? If there's anything important that I've missed please put me straight. Cheers AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Aug 13 13:25:59 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2DC628C1C2; Wed, 13 Aug 2008 13:25:59 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F312C28C1C2 for ; Wed, 13 Aug 2008 13:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[AWL=1.401, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShZJnNJkEXfo for ; Wed, 13 Aug 2008 13:25:52 -0700 (PDT) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id A459328C1A1 for ; Wed, 13 Aug 2008 13:25:52 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 1605A50846; Wed, 13 Aug 2008 13:36:07 -0700 (PDT) Date: Wed, 13 Aug 2008 13:36:07 -0700 From: Eric Rescorla To: "Adam Langley" In-Reply-To: <396556a20808131307r65a9f6a0oe4365be029620b2c@mail.gmail.com> References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <20080813172752.AA7A650846@romeo.rtfm.com> <396556a20808131047q781675a3if23d727ef5ae918f@mail.gmail.com> <20080813181630.A1E6750848@romeo.rtfm.com> <396556a20808131145y1be0fb4saeb7bbf74d078268@mail.gmail.com> <20080813195027.C4C5B50848@romeo.rtfm.com> <396556a20808131307r65a9f6a0oe4365be029620b2c@mail.gmail.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080813203607.1605A50846@romeo.rtfm.com> Cc: tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At Wed, 13 Aug 2008 13:07:45 -0700, Adam Langley wrote: > > On Wed, Aug 13, 2008 at 12:50 PM, Eric Rescorla > wrote: > > Well, this is just an unsupported claim in the presentation, so I have > > no idea what the underlying data is. However, superficially I find it > > deeply implausible. > > As I suggested, this data is considered secret by the organisations > who have it. But I can say that, had I suggested an opportunistic > system that required an extra round trip, various teams here (at > Google) would have (rightfully) laughed at me. I know that sucks as an > argument, but I can't release company data. I'm a bit stuck here > sadly. You're right, it does suck as an argument. And given that it's superficially implausible for the reasons you elided, I don't feel the need to entertain this as a serious design objective. If/when you can come up with someone who is actually willing to share this data, I'll be happy to reconsider that position. -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Aug 13 14:40:02 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFDDF3A68C7; Wed, 13 Aug 2008 14:40:02 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F15C23A6988 for ; Wed, 13 Aug 2008 14:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Sk7LvM0oJrJ for ; Wed, 13 Aug 2008 14:40:01 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by core3.amsl.com (Postfix) with ESMTP id E38113A693F for ; Wed, 13 Aug 2008 14:40:00 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so155277rvf.49 for ; Wed, 13 Aug 2008 14:40:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=BtqHPyd1j4C8DxnamIdqmVxrDP+BiLoU2+bVqRAZ25c=; b=nmC1Xm+di66GclgvjkUBge7U0pBtdO+sScAyN6TI6jCEq0lF1oA1+O1J0LBXLwH7le Mozjd4v6InmQk20HBIaCX5yP7Avzi0GYe3W8c3h8a4cvVbFJ8K3LMj4nZNyxYemRy95k KhJ+YwPfpv4U+FVyv9mP1BiDv7VFRKCEh1Pps= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=ubwjCWg0EYBwCSK4N+mVKUjUa7q+fbnVFzWk71QJHBcv6RP84wMOQUnUY8zJuv3eFC p/93vgrSM7od+MeGtz2SUFJMdEMJE2XpzuZnnE8DsJct8CCMtFG8GL96V4NLt8hCaBFQ 7imjuCplMUs4mT+Aaen2VQkhlLgLCyqBzpf0s= Received: by 10.140.157.1 with SMTP id f1mr233005rve.220.1218663602224; Wed, 13 Aug 2008 14:40:02 -0700 (PDT) Received: by 10.141.37.3 with HTTP; Wed, 13 Aug 2008 14:40:02 -0700 (PDT) Message-ID: <396556a20808131440j6b685405xc0fd78b83fb4857a@mail.gmail.com> Date: Wed, 13 Aug 2008 14:40:02 -0700 From: "Adam Langley" To: "Eric Rescorla" In-Reply-To: <20080813203607.1605A50846@romeo.rtfm.com> MIME-Version: 1.0 Content-Disposition: inline References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <20080813172752.AA7A650846@romeo.rtfm.com> <396556a20808131047q781675a3if23d727ef5ae918f@mail.gmail.com> <20080813181630.A1E6750848@romeo.rtfm.com> <396556a20808131145y1be0fb4saeb7bbf74d078268@mail.gmail.com> <20080813195027.C4C5B50848@romeo.rtfm.com> <396556a20808131307r65a9f6a0oe4365be029620b2c@mail.gmail.com> <20080813203607.1605A50846@romeo.rtfm.com> X-Google-Sender-Auth: 26723e8bb1685e60 Cc: tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Wed, Aug 13, 2008 at 1:36 PM, Eric Rescorla wrote: > You're right, it does suck as an argument. And given that it's > superficially implausible for the reasons you elided, I don't feel the > need to entertain this as a serious design objective. I certainly don't agree that it's superficially implausible. I shall ask someone senior here if I can release some of our latency affect data, although I doubt the answer will be positive. Remeber that > 40% of US homes are still using dial-up[1] and that's leveling out. Even if you are within the US, the RTT across the country on a dial-up is 300-400ms[2]. [1] http://www.websiteoptimization.com/bw/0804/ [2] http://www.rohwer.org/Latency/Latency9.html AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Aug 13 15:16:38 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A252528C16E; Wed, 13 Aug 2008 15:16:38 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B680D28C16E for ; Wed, 13 Aug 2008 15:16:37 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 769z0PpxlCDz for ; Wed, 13 Aug 2008 15:16:36 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id DE1AE28C13E for ; Wed, 13 Aug 2008 15:16:33 -0700 (PDT) Received: from [75.217.123.194] (194.sub-75-217-123.myvzw.com [75.217.123.194]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m7DMG69f001278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Aug 2008 15:16:09 -0700 (PDT) Message-ID: <48A35CFA.4060709@isi.edu> Date: Wed, 13 Aug 2008 15:15:22 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Adam Langley References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <20080813172752.AA7A650846@romeo.rtfm.com> <396556a20808131047q781675a3if23d727ef5ae918f@mail.gmail.com> <20080813181630.A1E6750848@romeo.rtfm.com> <396556a20808131145y1be0fb4saeb7bbf74d078268@mail.gmail.com> <20080813195027.C4C5B50848@romeo.rtfm.com> <396556a20808131307r65a9f6a0oe4365be029620b2c@mail.gmail.com> In-Reply-To: <396556a20808131307r65a9f6a0oe4365be029620b2c@mail.gmail.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adam Langley wrote: | On Wed, Aug 13, 2008 at 12:50 PM, Eric Rescorla | wrote: |> Right, but this has application-level semantics because the content |> of the server's data is not what an unmodified client expects. So, |> it's not just a timing issue: the server sends different data |> to the client if this option is included or not. This is, IMO, the most compelling argument that this mechanism ought to be bound to a TCP port, not a TCP option. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkijXPoACgkQE5f5cImnZrsZUQCcDndN7ItoO3pAceRKuiNMS4Ie qvQAoOcGYj0GVLsxRsDoA9tbs79A/jfO =ZYHh -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Aug 13 15:25:53 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75CAE28C16E; Wed, 13 Aug 2008 15:25:53 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3292A3A6D1D for ; Wed, 13 Aug 2008 15:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsvJQLjNzFzg for ; Wed, 13 Aug 2008 15:25:51 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by core3.amsl.com (Postfix) with ESMTP id 62B9E3A68F0 for ; Wed, 13 Aug 2008 15:25:51 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so170294rvf.49 for ; Wed, 13 Aug 2008 15:25:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=zecp7QaRaa5DiK5zC522NA/85enx41IzU9zvCKQ75WM=; b=cqorEfS+YTw6AQVCvf8l3tXH30WGhDOoslHr7Nf7ZvU1Tzu3qhK0a1yQbIf3OK5y5q rjdIDwDuB9Quq2uHGqetOvEPwBs+1Pt517J/8eAbnZlfjRLP8wBlhZBuxNjaSYegd9fQ jI4rZS3ypKy/RRAZ1oYccAiPM2JOQoyWahtE8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=POZS7J+QeoUKZP259CJbvtCUvJr7l23eUzxEFdpaRn3JjlDILYkznx7nxyCb5ZKw32 7FBw5oSwaV3Xj5rIwtLDELUaXkesD0/H87cSQxXHy3lg7dNXTXzm/SHYI+lsoL467tzO k1Ri8X3etomenLsEgE3+GtZySNGpaYV4E3qR4= Received: by 10.141.18.15 with SMTP id v15mr254905rvi.296.1218666338570; Wed, 13 Aug 2008 15:25:38 -0700 (PDT) Received: by 10.141.37.3 with HTTP; Wed, 13 Aug 2008 15:25:38 -0700 (PDT) Message-ID: <396556a20808131525i20dabf06w7a7a11e3468e541a@mail.gmail.com> Date: Wed, 13 Aug 2008 15:25:38 -0700 From: "Adam Langley" To: "Joe Touch" In-Reply-To: <48A35CFA.4060709@isi.edu> MIME-Version: 1.0 Content-Disposition: inline References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <20080813172752.AA7A650846@romeo.rtfm.com> <396556a20808131047q781675a3if23d727ef5ae918f@mail.gmail.com> <20080813181630.A1E6750848@romeo.rtfm.com> <396556a20808131145y1be0fb4saeb7bbf74d078268@mail.gmail.com> <20080813195027.C4C5B50848@romeo.rtfm.com> <396556a20808131307r65a9f6a0oe4365be029620b2c@mail.gmail.com> <48A35CFA.4060709@isi.edu> X-Google-Sender-Auth: 416c0ad862b734e4 Cc: tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Wed, Aug 13, 2008 at 3:15 PM, Joe Touch wrote: > This is, IMO, the most compelling argument that this mechanism ought to > be bound to a TCP port, not a TCP option. Although that removes any ability for it to be opportunistic since the latency of trying an alternative port is very high. Many sites will drop SYNs on ports other than 80 or 443. Even if the original port were to advertise the alternative port for future connections, many clients are behind firewalls that will restrict their outbound connections. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Aug 13 15:33:42 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04D5F3A6CE0; Wed, 13 Aug 2008 15:33:42 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE7133A6881 for ; Wed, 13 Aug 2008 15:33:40 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7G-nvPI0jA5 for ; Wed, 13 Aug 2008 15:33:39 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id D9BD93A6B1A for ; Wed, 13 Aug 2008 15:33:39 -0700 (PDT) Received: from [75.217.123.194] (194.sub-75-217-123.myvzw.com [75.217.123.194]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m7DMXK9b006809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Aug 2008 15:33:23 -0700 (PDT) Message-ID: <48A36104.6000000@isi.edu> Date: Wed, 13 Aug 2008 15:32:36 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Adam Langley References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <20080813172752.AA7A650846@romeo.rtfm.com> <396556a20808131047q781675a3if23d727ef5ae918f@mail.gmail.com> <20080813181630.A1E6750848@romeo.rtfm.com> <396556a20808131145y1be0fb4saeb7bbf74d078268@mail.gmail.com> <20080813195027.C4C5B50848@romeo.rtfm.com> <396556a20808131307r65a9f6a0oe4365be029620b2c@mail.gmail.com> <48A35CFA.4060709@isi.edu> <396556a20808131525i20dabf06w7a7a11e3468e541a@mail.gmail.com> In-Reply-To: <396556a20808131525i20dabf06w7a7a11e3468e541a@mail.gmail.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adam Langley wrote: | On Wed, Aug 13, 2008 at 3:15 PM, Joe Touch wrote: |> This is, IMO, the most compelling argument that this mechanism ought to |> be bound to a TCP port, not a TCP option. | | Although that removes any ability for it to be opportunistic since the | latency of trying an alternative port is very high. Many sites will | drop SYNs on ports other than 80 or 443. Sites that understand this option would be listening on the desired ports. It's trivial to issue two SYNs and wait to see which ones are returned. Further, I'm not even sure how to write the application at the server - one that responds with different data depending on signals in a SYN. What does that even mean, and how does the TCP API (as specified in RFC793, e.g.) need to be extended to support that? | Even if the original port | were to advertise the alternative port for future connections, many | clients are behind firewalls that will restrict their outbound | connections. Firewalls and NATs also sometimes munge TCP options, especially ones they don't understand, FWIW. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkijYQQACgkQE5f5cImnZrvYkACglc1GuY3R8hwH0lBFOBJjSLkm oysAn0ztkIqkaZQaYQzNMce/KgFgaeGi =y0YM -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Aug 13 16:05:20 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C464A3A69AE; Wed, 13 Aug 2008 16:05:20 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 662253A6A4A for ; Wed, 13 Aug 2008 16:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.277 X-Spam-Level: X-Spam-Status: No, score=0.277 tagged_above=-999 required=5 tests=[AWL=-1.734, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_STOCK2=3.988] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rpab8jWkWnCq for ; Wed, 13 Aug 2008 16:05:18 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by core3.amsl.com (Postfix) with ESMTP id 875383A69AE for ; Wed, 13 Aug 2008 16:05:18 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so183006rvf.49 for ; Wed, 13 Aug 2008 16:05:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=tEFDG2aQHVX855sHjjMmkJPYLt4OEtlKXcP1F3EfOYk=; b=sxqyJSLd2LpgrAyoh/49MXhmDU7TM1nmWCrFV0/bLupHJf+iFBq2uW4zeVSY+UPoTU tBdVJjZws4SAF/Ie361zfufrp2d04YKsbS46EwES06pv3Rgm+1f+zXnYMEmRhcxOg2SS k3znh5EpmoMB2lY/jPWummfBMUoL6MRJsSAd4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=l4o5w95LfSO2avf6EZQFC+jBgOr/O7VQEI1kRSbIWawk9AMmmPK8lF32AqaGNc/2Kd 3UOLsCE+u7drylwYBQZDLlNUAT2wboEIF3iUGn7oBYZ0ZWnHSzVpQZDVD55Sv7nfs3zm nFCzV06kleqv7UXj9X2DDnRZOXBWKx78ULWoU= Received: by 10.140.249.20 with SMTP id w20mr281670rvh.21.1218668722519; Wed, 13 Aug 2008 16:05:22 -0700 (PDT) Received: by 10.141.37.3 with HTTP; Wed, 13 Aug 2008 16:05:22 -0700 (PDT) Message-ID: <396556a20808131605w2ccac3ceo21160401e4545c15@mail.gmail.com> Date: Wed, 13 Aug 2008 16:05:22 -0700 From: "Adam Langley" To: "Joe Touch" In-Reply-To: <48A36104.6000000@isi.edu> MIME-Version: 1.0 Content-Disposition: inline References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <20080813172752.AA7A650846@romeo.rtfm.com> <396556a20808131047q781675a3if23d727ef5ae918f@mail.gmail.com> <20080813181630.A1E6750848@romeo.rtfm.com> <396556a20808131145y1be0fb4saeb7bbf74d078268@mail.gmail.com> <20080813195027.C4C5B50848@romeo.rtfm.com> <396556a20808131307r65a9f6a0oe4365be029620b2c@mail.gmail.com> <48A35CFA.4060709@isi.edu> <396556a20808131525i20dabf06w7a7a11e3468e541a@mail.gmail.com> <48A36104.6000000@isi.edu> X-Google-Sender-Auth: 43555101ed815f71 Cc: tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Wed, Aug 13, 2008 at 3:32 PM, Joe Touch wrote: > Sites that understand this option would be listening on the desired > ports. It's trivial to issue two SYNs and wait to see which ones are > returned. If the two connections are made in parallel, and port 80 returns first, how long do you wait for the other one? In this case, that additional latency effects all *existing* sites. Hopefully the difference would be small, but 5ms, 10ms? Also, in the case that both return, the application probably can't close the socket in time for the kernel not to ACK it, in which case clients would constantly be opening very short lived connections to port 80. I understand that application level changes based on options is a bit discomforting but, personally, I find racing SYNs to be much worse. > Further, I'm not even sure how to write the application at the server - > one that responds with different data depending on signals in a SYN. > What does that even mean, and how does the TCP API (as specified in > RFC793, e.g.) need to be extended to support that? The existing patches make the change fairly easy. From the comments: "A listening socket is configured with a setsockopt with non-zero payload len and, optionally, TCP_SADATA_INC_NONCE and tcpsa_nonce_offset if the kernel should include random data. On a resulting, accepted socket, a getsockopt reveals: TCP_SADATA_REQ - a SYN/ACK payload was requested TCP_SADATA_NONCE - the 8 random bytes generated are in tcpsa_payload" So the code looks like: int newsocket = accept(...) getsockopt(newsocket, SOL_TCP, &tcpsa, ...) if (TCP_SADATA_REQ & tcpsa.tcpsa_flags) { // The first data from the socket is the client's draft-agl handshake decode_tagged_data(newsocket); ... } else { // No special case, continue_as_normal(); } > Firewalls and NATs also sometimes munge TCP options, especially ones > they don't understand, FWIW. Certainly, and middleware which drops packets packets with the extra option would be a concern. (The draft makes provisions for retrying without the extra option in case implementations wish to do this). However, hosts with restricted outbound port numbers are downright common, sadly. Cheers AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Aug 13 17:52:15 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 878C33A680C; Wed, 13 Aug 2008 17:52:15 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F3D33A680C for ; Wed, 13 Aug 2008 17:52:13 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTEFB1nWcJ6T for ; Wed, 13 Aug 2008 17:52:12 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 7F81C3A67A8 for ; Wed, 13 Aug 2008 17:52:12 -0700 (PDT) Received: from [192.168.1.46] (pool-71-106-119-240.lsanca.dsl-w.verizon.net [71.106.119.240]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m7E0q1iJ013446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Aug 2008 17:52:03 -0700 (PDT) Message-ID: <48A38186.2020101@isi.edu> Date: Wed, 13 Aug 2008 17:51:18 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Adam Langley References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <20080813172752.AA7A650846@romeo.rtfm.com> <396556a20808131047q781675a3if23d727ef5ae918f@mail.gmail.com> <20080813181630.A1E6750848@romeo.rtfm.com> <396556a20808131145y1be0fb4saeb7bbf74d078268@mail.gmail.com> <20080813195027.C4C5B50848@romeo.rtfm.com> <396556a20808131307r65a9f6a0oe4365be029620b2c@mail.gmail.com> <20080813203607.1605A50846@romeo.rtfm.com> <396556a20808131440j6b685405xc0fd78b83fb4857a@mail.gmail.com> In-Reply-To: <396556a20808131440j6b685405xc0fd78b83fb4857a@mail.gmail.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adam Langley wrote: | On Wed, Aug 13, 2008 at 1:36 PM, Eric Rescorla wrote: |> You're right, it does suck as an argument. And given that it's |> superficially implausible for the reasons you elided, I don't feel the |> need to entertain this as a serious design objective. | | I certainly don't agree that it's superficially implausible. I shall | ask someone senior here if I can release some of our latency affect | data, although I doubt the answer will be positive. | | Remeber that > 40% of US homes are still using dial-up[1] and that's | leveling out. Even if you are within the US, the RTT across the | country on a dial-up is 300-400ms[2]. I think you're quoting >40% by assuming that anyone who doesn't use broadband uses a modem (i.e., 100-57% = 43%), which isn't what those charts indicate. The direct metric from citation [1] is Fig 2, which shows less than 12% of homes using dialup right now, a figure that has been steadily falling for the entire timeline shown. [2] is a VERY old reference using a 10-year-old modem standard that lasted only two years (1998-1999). V.92 superceded it in 1999. I measured RTTs from LA to Boston, and found 200-220ms. Pings locally were 140-150ms; the bulk of the increased ping delay was the modems. Unless you're going through a satellite or a very inefficient multihop radio system (e.g., anyone remember Metricom?), delays ought not exceed around 150ms + broadband delays, e.g., they ought to top out around 250ms. Joe | [1] http://www.websiteoptimization.com/bw/0804/ | [2] http://www.rohwer.org/Latency/Latency9.html | | AGL | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkijgAUACgkQE5f5cImnZrs8MgCdGyobw0N8ndbe7IZzCFBFS7gl 6ycAn2Qek6NLGikh+3H2HwYiyAHmiHix =ak1M -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Aug 13 18:02:49 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3110A3A6D5C; Wed, 13 Aug 2008 18:02:49 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D75D23A6D56 for ; Wed, 13 Aug 2008 18:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.605 X-Spam-Level: X-Spam-Status: No, score=-0.605 tagged_above=-999 required=5 tests=[AWL=-1.994, BAYES_00=-2.599, FRT_STOCK2=3.988] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibmr2Zbdbx-5 for ; Wed, 13 Aug 2008 18:02:47 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 2319D3A694C for ; Wed, 13 Aug 2008 18:02:47 -0700 (PDT) Received: from [192.168.1.46] (pool-71-106-119-240.lsanca.dsl-w.verizon.net [71.106.119.240]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m7E12JxZ016063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Aug 2008 18:02:21 -0700 (PDT) Message-ID: <48A383F0.9030601@isi.edu> Date: Wed, 13 Aug 2008 18:01:36 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Adam Langley References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <20080813172752.AA7A650846@romeo.rtfm.com> <396556a20808131047q781675a3if23d727ef5ae918f@mail.gmail.com> <20080813181630.A1E6750848@romeo.rtfm.com> <396556a20808131145y1be0fb4saeb7bbf74d078268@mail.gmail.com> <20080813195027.C4C5B50848@romeo.rtfm.com> <396556a20808131307r65a9f6a0oe4365be029620b2c@mail.gmail.com> <48A35CFA.4060709@isi.edu> <396556a20808131525i20dabf06w7a7a11e3468e541a@mail.gmail.com> <48A36104.6000000@isi.edu> <396556a20808131605w2ccac3ceo21160401e4545c15@mail.gmail.com> In-Reply-To: <396556a20808131605w2ccac3ceo21160401e4545c15@mail.gmail.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adam Langley wrote: ... | The existing patches make the change fairly easy. From the comments: | | "A listening socket is configured with a setsockopt with non-zero payload len | and, optionally, TCP_SADATA_INC_NONCE and tcpsa_nonce_offset if the kernel | should include random data. | | On a resulting, accepted socket, a getsockopt reveals: | TCP_SADATA_REQ - a SYN/ACK payload was requested | TCP_SADATA_NONCE - the 8 random bytes generated are in tcpsa_payload" | | So the code looks like: | | int newsocket = accept(...) | getsockopt(newsocket, SOL_TCP, &tcpsa, ...) | if (TCP_SADATA_REQ & tcpsa.tcpsa_flags) { | // The first data from the socket is the client's draft-agl handshake | decode_tagged_data(newsocket); | ... | } else { | // No special case, | continue_as_normal(); | } I'm wondering why an implementation in user space would expect to find out anything about a TCP connection that hadn't finished handshaking, i.e., the accept call above (AFAIR) ought to return only after the end of the three-way handshake (I'll have to dig out my Stephens book to confirm, though): syn -> <- syn/ack ack -> --->accept returns The above code would do what you intend only if the accept returns on the initial SYN. At the very least, even if the accept returns when the initial SYN is received, by the time the accept returns the syn/ack ought to have been sent. unix doesn't wait for the accept call to actually return the syn/ack - various discussions confirm this - or are you also modifying that code? Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkijg/AACgkQE5f5cImnZrtQXQCfegdXCInIO9WTnwfjPPGxEbxL S9EAmwR29E5/8jSnStzOKnSykzAHAfar =CQVT -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Aug 13 18:21:08 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC0693A6D62; Wed, 13 Aug 2008 18:21:08 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 583083A6D60 for ; Wed, 13 Aug 2008 18:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gi51HSAVwu2 for ; Wed, 13 Aug 2008 18:21:06 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by core3.amsl.com (Postfix) with ESMTP id 4C4B33A69F8 for ; Wed, 13 Aug 2008 18:21:06 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so150378yxg.49 for ; Wed, 13 Aug 2008 18:21:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=5nTkXSd7vyVIBSpoQPORyQR98uVNygVOixli0bv6nNc=; b=vSd/q+mgn6jfon5oJ6X9iyR9cXTaGwR+Fq1kNzv6RTFDCfQHA28SzDPZCi/jXMBpQX gnVDWbctAtPr9G0v9xV6GJpPvcjALy0vHLQv5OA0DMASPk6mPeKKI47h7+PgAImYNwRk lCdyj7nrtlcXn+CxJKXZNcoemczah6tfu+W7E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=uOo4ANIKJhbswn2TqvumSZrblQPsFsXPOGUE/TzcbjeG7Sbgs61YzWH9FRwNwLTNKw 1zSqOB5c6LrZHQF9YjtRTFlHrsbnkVsiFiUpYuI4w73RjIpjvKXo+tqKN6VzaOVvFa8b JGYFNgllhlIqWmeZQfjyxvNiIPP8fUmUsV0g4= Received: by 10.140.185.1 with SMTP id i1mr321354rvf.102.1218676868705; Wed, 13 Aug 2008 18:21:08 -0700 (PDT) Received: by 10.141.37.3 with HTTP; Wed, 13 Aug 2008 18:21:08 -0700 (PDT) Message-ID: <396556a20808131821v2c5ffa9cie1d66ef26dabd561@mail.gmail.com> Date: Wed, 13 Aug 2008 18:21:08 -0700 From: "Adam Langley" To: "Joe Touch" In-Reply-To: <48A38186.2020101@isi.edu> MIME-Version: 1.0 Content-Disposition: inline References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <20080813172752.AA7A650846@romeo.rtfm.com> <396556a20808131047q781675a3if23d727ef5ae918f@mail.gmail.com> <20080813181630.A1E6750848@romeo.rtfm.com> <396556a20808131145y1be0fb4saeb7bbf74d078268@mail.gmail.com> <20080813195027.C4C5B50848@romeo.rtfm.com> <396556a20808131307r65a9f6a0oe4365be029620b2c@mail.gmail.com> <20080813203607.1605A50846@romeo.rtfm.com> <396556a20808131440j6b685405xc0fd78b83fb4857a@mail.gmail.com> <48A38186.2020101@isi.edu> X-Google-Sender-Auth: a7062c61e367f8dc Cc: tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Wed, Aug 13, 2008 at 5:51 PM, Joe Touch wrote: > I think you're quoting >40% by assuming that anyone who doesn't use > broadband uses a modem (i.e., 100-57% = 43%), which isn't what those > charts indicate. The direct metric from citation [1] is Fig 2, which > shows less than 12% of homes using dialup right now, a figure that has > been steadily falling for the entire timeline shown. I believe that the number of homes with broadband is, indeed, 57%. (Although it's a fair point that some might be using's others unsecured wireless connections). On another reading of the report, it looks like this is the number of homes were broadband is /available/. There are /two/ figures labeled "Figure 2", so I'll refer to them as the first and second: I think the first fig 2 includes the numbers of people who are using broadband connections at work and the second figure 2 has a much higher number because it counts active users. Homes with broadband are more likely to use it, it seems. But, you're right, I should be using the number of active users rather than the number of homes with broadband. I knocked up a model for the losses experienced by an example website based on an extra round trip time. I'm still trying to get permission to release it. > [2] is a VERY old reference using a 10-year-old modem standard that > lasted only two years (1998-1999). V.92 superceded it in 1999. Yes, but I didn't find anything very good that was more recent - people don't seem to study modems much anymore. Also, the V.92 standard increased the upload speed at the determent of the download speed. It's not clear that V.92 would have have much, if any, effect on latency. > I measured RTTs from LA to Boston, and found 200-220ms. Pings locally > were 140-150ms; the bulk of the increased ping delay was the modems. > Unless you're going through a satellite or a very inefficient multihop > radio system (e.g., anyone remember Metricom?), delays ought not exceed > around 150ms + broadband delays, e.g., they ought to top out around 250ms. It's about 75ms from SF to NYC, so that makes sense. However, 250ms still makes a big difference. Like I said, I'm trying to get the numbers released. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Aug 13 18:27:04 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FD223A6A70; Wed, 13 Aug 2008 18:27:04 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D990C3A69F8 for ; Wed, 13 Aug 2008 18:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syhqI4KY7Zuz for ; Wed, 13 Aug 2008 18:27:03 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by core3.amsl.com (Postfix) with ESMTP id 1C2A23A6941 for ; Wed, 13 Aug 2008 18:27:02 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id x19so170070pyg.24 for ; Wed, 13 Aug 2008 18:27:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=AaJM5Px/4cEo+GrzqzXcm5dqkehAXgL5dxkGdTN5zXg=; b=A3qITchZY9jVkkDXTpMC3/5bVoiBCXj7aknKfjUGcvILl1+frXXkUyW+UTMYZi2yhy sQmRgXUXF6v+EjV9lgk9ofRS5+/YKWf9NgCBdoMKQxCND6OBU+xJiMSLlGDxwZlUDAxG uR0UoDVg2ORNuv8HnnZDopZt3OmfpNBnhcQpM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=ZB3aTf+GGxwGZ8UUsLxNd0DgYWCB978rbGXluuSivWUZ9XQ7f7mZlDmkHZYLDC+2z8 cNaCRtICgaKtgUCDq4fHUhdglk7YHq4BT+Akdz2W03pRoWAkMocOkSjku1ycejiAld/i zDHGWH0clX5Y0+QhnfntmvAC4ZMSB26k8VlZE= Received: by 10.141.206.13 with SMTP id i13mr323185rvq.100.1218677225005; Wed, 13 Aug 2008 18:27:05 -0700 (PDT) Received: by 10.141.37.3 with HTTP; Wed, 13 Aug 2008 18:27:04 -0700 (PDT) Message-ID: <396556a20808131827x1ab32b13yaa9358ac1a70c6ed@mail.gmail.com> Date: Wed, 13 Aug 2008 18:27:04 -0700 From: "Adam Langley" To: "Joe Touch" In-Reply-To: <48A383F0.9030601@isi.edu> MIME-Version: 1.0 Content-Disposition: inline References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <20080813181630.A1E6750848@romeo.rtfm.com> <396556a20808131145y1be0fb4saeb7bbf74d078268@mail.gmail.com> <20080813195027.C4C5B50848@romeo.rtfm.com> <396556a20808131307r65a9f6a0oe4365be029620b2c@mail.gmail.com> <48A35CFA.4060709@isi.edu> <396556a20808131525i20dabf06w7a7a11e3468e541a@mail.gmail.com> <48A36104.6000000@isi.edu> <396556a20808131605w2ccac3ceo21160401e4545c15@mail.gmail.com> <48A383F0.9030601@isi.edu> X-Google-Sender-Auth: 0b1cf2ecd9bc5182 Cc: tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Wed, Aug 13, 2008 at 6:01 PM, Joe Touch wrote: > I'm wondering why an implementation in user space would expect to find > out anything about a TCP connection that hadn't finished handshaking, > i.e., the accept call above (AFAIR) ought to return only after the end > of the three-way handshake (I'll have to dig out my Stephens book to > confirm, though): Absolutely accept() only returns after the 3-way has completed. Note that the draft only requires that the stack be able to configure a static payload. Additionally, it suggests that it should be able to insert some random bytes in there for cryptographic protocols that need it. Thus, the kernel is able to send the SYN/ACK (with payload) without any application involvement. Thus, all the application needs to find out, after an accept() is weather the kernel echoed the SYNACK Payload Permitted option. If it did, then the server knows that it's SYNACK payload was sent and the data from the client will be a tagged structure that I don't actually define in the draft (since it's not anything to do with TCP). Otherwise, the option wasn't echoed in which case the protocol continues as normal. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Aug 13 22:12:26 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31AF73A6857; Wed, 13 Aug 2008 22:12:26 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A99AB3A63CB for ; Wed, 13 Aug 2008 22:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[AWL=0.997, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4j5EQ0avI3Wv for ; Wed, 13 Aug 2008 22:12:23 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 8354F3A67E5 for ; Wed, 13 Aug 2008 22:12:23 -0700 (PDT) Received: from [192.168.1.46] (pool-71-106-119-240.lsanca.dsl-w.verizon.net [71.106.119.240]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m7E5CFX0027031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Aug 2008 22:12:17 -0700 (PDT) Message-ID: <48A3BE83.1080403@isi.edu> Date: Wed, 13 Aug 2008 22:11:31 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Adam Langley References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <20080813172752.AA7A650846@romeo.rtfm.com> <396556a20808131047q781675a3if23d727ef5ae918f@mail.gmail.com> <20080813181630.A1E6750848@romeo.rtfm.com> <396556a20808131145y1be0fb4saeb7bbf74d078268@mail.gmail.com> <20080813195027.C4C5B50848@romeo.rtfm.com> <396556a20808131307r65a9f6a0oe4365be029620b2c@mail.gmail.com> <20080813203607.1605A50846@romeo.rtfm.com> <396556a20808131440j6b685405xc0fd78b83fb4857a@mail.gmail.com> <48A38186.2020101@isi.edu> <396556a20808131821v2c5ffa9cie1d66ef26dabd561@mail.gmail.com> In-Reply-To: <396556a20808131821v2c5ffa9cie1d66ef26dabd561@mail.gmail.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adam Langley wrote: | On Wed, Aug 13, 2008 at 5:51 PM, Joe Touch wrote: |> I think you're quoting >40% by assuming that anyone who doesn't use |> broadband uses a modem (i.e., 100-57% = 43%), which isn't what those |> charts indicate. The direct metric from citation [1] is Fig 2, which |> shows less than 12% of homes using dialup right now, a figure that has |> been steadily falling for the entire timeline shown. | | I believe that the number of homes with broadband is, indeed, 57%. It's 57% of homes having broadband access. That does NOT imply that the other 43% use dialup; some people still don't use the Internet, or (as you note below) that all 57% have broadband turned on. | (Although it's a fair point that some might be using's others | unsecured wireless connections). On another reading of the report, it | looks like this is the number of homes were broadband is /available/. | There are /two/ figures labeled "Figure 2", so I'll refer to them as | the first and second: | | I think the first fig 2 includes the numbers of people who are using | broadband connections at work and the second figure 2 has a much | higher number because it counts active users. Homes with broadband are | more likely to use it, it seems. Fig 2 is fairly conclusive to the point you're making; the ratio of broadband to dialup - by house - is 88:12. You've noted that reducing a single RTT is significant for dialup users; these figures argue that such users are a small minority (12%), and perhaps this is thus optimizing for a small, disappearing group. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkijvoMACgkQE5f5cImnZrt6fQCdEdP3rSdl5T3gzaz5IEst8f6l HoAAoOxPusU7JX//7ZMfEtmSZ+D/lK74 =lSTf -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Aug 13 22:21:54 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ED073A682A; Wed, 13 Aug 2008 22:21:54 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6ADC3A67F3 for ; Wed, 13 Aug 2008 22:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.06 X-Spam-Level: X-Spam-Status: No, score=0.06 tagged_above=-999 required=5 tests=[AWL=-1.329, BAYES_00=-2.599, FRT_STOCK2=3.988] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsgUrtvtzass for ; Wed, 13 Aug 2008 22:21:52 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 0D2AF3A682A for ; Wed, 13 Aug 2008 22:21:52 -0700 (PDT) Received: from [192.168.1.46] (pool-71-106-119-240.lsanca.dsl-w.verizon.net [71.106.119.240]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m7E5LZ8i029638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Aug 2008 22:21:38 -0700 (PDT) Message-ID: <48A3C0B3.8050003@isi.edu> Date: Wed, 13 Aug 2008 22:20:51 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Adam Langley References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <20080813181630.A1E6750848@romeo.rtfm.com> <396556a20808131145y1be0fb4saeb7bbf74d078268@mail.gmail.com> <20080813195027.C4C5B50848@romeo.rtfm.com> <396556a20808131307r65a9f6a0oe4365be029620b2c@mail.gmail.com> <48A35CFA.4060709@isi.edu> <396556a20808131525i20dabf06w7a7a11e3468e541a@mail.gmail.com> <48A36104.6000000@isi.edu> <396556a20808131605w2ccac3ceo21160401e4545c15@mail.gmail.com> <48A383F0.9030601@isi.edu> <396556a20808131827x1ab32b13yaa9358ac1a70c6ed@mail.gmail.com> In-Reply-To: <396556a20808131827x1ab32b13yaa9358ac1a70c6ed@mail.gmail.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adam Langley wrote: | On Wed, Aug 13, 2008 at 6:01 PM, Joe Touch wrote: |> I'm wondering why an implementation in user space would expect to find |> out anything about a TCP connection that hadn't finished handshaking, |> i.e., the accept call above (AFAIR) ought to return only after the end |> of the three-way handshake (I'll have to dig out my Stephens book to |> confirm, though): | | Absolutely accept() only returns after the 3-way has completed. | | Note that the draft only requires that the stack be able to configure | a static payload. I'm confused now; your code - and your note. Let's go back to the key issue: - is the data received by the client dependent on the option? Here's your code: - ---- The existing patches make the change fairly easy. From the comments: "A listening socket is configured with a setsockopt with non-zero payload len and, optionally, TCP_SADATA_INC_NONCE and tcpsa_nonce_offset if the kernel should include random data. On a resulting, accepted socket, a getsockopt reveals: ~ TCP_SADATA_REQ - a SYN/ACK payload was requested ~ TCP_SADATA_NONCE - the 8 random bytes generated are in tcpsa_payload" So the code looks like: int newsocket = accept(...) getsockopt(newsocket, SOL_TCP, &tcpsa, ...) if (TCP_SADATA_REQ & tcpsa.tcpsa_flags) { ~ // The first data from the socket is the client's draft-agl handshake ~ decode_tagged_data(newsocket); ~ ... } else { ~ // No special case, ~ continue_as_normal(); } - --- The SERVER is the one in listen; this means that the server thinks there is different data on the socket depending on whether the client has the option set? That would mean that the SYN had the data, not the SYN-ACK. Or am I misreading the code? Further, how does the server put different code in the connection depending on a socket option it can't see until after the listen? It can't write to the socket until the listen completes, at which point the SYN-ACK is gone. It seems like you're going to end up needing a new call to write to the socket before the listen completes, i.e., a setsockopt that effectively 'writes'. Again, this is --far-- afield from TCP semantics. | Thus, the kernel is able to send the SYN/ACK (with payload) without | any application involvement. This is truly confusing to me. The payload **is** application communication. You're creating an option to generate that data inside the TCP protocol? | Thus, all the application needs to find | out, after an accept() is weather the kernel echoed the SYNACK Payload | Permitted option. If it did, then the server knows that it's SYNACK | payload was sent and the data from the client will be a tagged | structure that I don't actually define in the draft (since it's not | anything to do with TCP). Otherwise, the option wasn't echoed in which | case the protocol continues as normal. As a final question, if this is experimental, why not just use the experimental TCP option KIND? (and how much of this has been implemented, traced, and checked for things like simultaneous open - I don't recall if you noted that before) Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkijwLMACgkQE5f5cImnZruCBgCgrAvDgU64o97PAsLJU06yqJJ0 aMgAoM98Y1W3EMCRFPgrt2AJ5n2gY/3A =VihK -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 14 00:04:37 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AAB23A6C3A; Thu, 14 Aug 2008 00:04:37 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31E263A6C2A for ; Wed, 13 Aug 2008 23:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.71 X-Spam-Level: *** X-Spam-Status: No, score=3.71 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6kTIkzIG5IM for ; Wed, 13 Aug 2008 23:51:10 -0700 (PDT) Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 3A3AF3A6BDB for ; Wed, 13 Aug 2008 23:51:08 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA186036613; Thu, 14 Aug 2008 08:50:13 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id IAA05627; Thu, 14 Aug 2008 08:50:09 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200808140650.IAA05627@TR-Sys.de> To: ananth@cisco.com, rrs@cisco.com, mdalal@cisco.com Date: Thu, 14 Aug 2008 08:50:09 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Cc: tcpm@ietf.org Subject: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="hp-roman8" Content-Transfer-Encoding: base64 Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org SGVsbG8gYWxsLApJIGhhdmUgb25jZSBtb3JlIHRyaWVkIHRvIGNsb3NlbHkgcmVhZCB0aGUgbGF0 ZXN0ICgtMTApIHZlcnNpb24gb2YKdGhlICd0Y3BzZWN1cmUnIGRyYWZ0LCBhbmQgb25seSBmb3Vu ZCBhIHZlcnkgc21hbGwgbnVtYmVyIG9mIG5pdHMgLS0Kc2VlIGJlbG93LgoKCkZ1cnRoZXJtb3Jl LCBJIG9uY2UgbW9yZSBhZHZvY2F0ZSBtYWtpbmcgY2xlYXIgaW4gdGhlIGRvY3VtZW50Cm1ldGFk YXRhIHdoYXQgdGhlIGRvY3VtZW50IGRvZXMsIGJ5IGFkZGluZyB0byB0aGUgaGVhZGluZzoKCiAg ICBVcGRhdGVzOiA3OTMgKGlmIGFwcHJvdmVkKQoKRG9pbmcgc28gd2lsbCBkZWZpbml0ZWx5IGhl bHAgZ3VpZGUgaW1wbGVtZW50ZXJzIHRvIHF1aWNrbHkgbG9jYXRlCnRoZSBkb2N1bWVudCBvbmNl IHB1Ymxpc2hlZCBhcyBhbiBSRkMuCkJ5IFdHIGNvbnNlbnN1cywgdGhlIGRvY3VtZW50IGlzIGlu dGVuZGVkIGZvciBTdGFuZGFyZHMgVHJhY2ssIGFuZApTZWN0aW9ucyAzLjIsIDQuMiwgYW5kIDUu MiBjbGVhcmx5IHN0YXRlIHRoYXQgdGhleSB1cGRhdGUgUkZDIDc5MzsKdGh1cywgdGhpcyBzaG91 bGQgYmUgbWFkZSB2aXNpYmxlIGF0IHRoZSBtZXRhZGF0YSBsZXZlbCBhcyB3ZWxsLgoKCk5pdHMg KGluIHJlY2VudGx5IGFkZGVkIC8gbW9kaWZpZWQgdGV4dCk6CgooMSkKQXQgdGhlIHZlcnkgZW5k IG9mIHNlY3Rpb24gMSwgcGxlYXNlIGNoYW5nZToKCiAgICAgICAgICAgICAgWy4uLl0gcGxlYXNl IHJlZmVyIHRvIGRyYWZ0IFtSRkM0OTUzXQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIF5eXl5eXiAgICAgICAgICBeCiAgIHRvOgogICAgICAgICAgICAgIFsuLi5dIHBsZWFzZSBy ZWZlciB0byBSRkMgNDk1MyBbUkZDNDk1M10uCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgXl5eXl5eXl5eICAgICAgICAgIF4KICAgb3I6CiAgICAgICAgICAgICAgWy4uLl0gcGxl YXNlIHJlZmVyIHRvIFtSRkM0OTUzXS4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBeICAgICAgICAgXgoKKDIpCkluIHRoZSBmaXJzdCBwYXJhZ3JhcGggb2Ygc2VjdGlvbiA1LjIs IHBsZWFzZSBjb3JyZWN0IHR3bwpwdW5jdHVhdGlvbiBmbGF3cyAobWlzc2luZyBwZXJpb2QsIGFu ZCBleHRyYW5lb3VzIGFwb3N0cm9waGUpLgpJIGFsc28gaGF2ZSBpbmNsdWRlZCB0d28gbWlub3Ig c3R5bGlzdGljIGltcHJvdmVtZW50IGJlbG93OgoKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFsuLi5dLiAgSXQgbmVlZHMgdG8KfCAgYmUgbm90ZWQg dGhhdCBSRkMgNzkzIHBhZ2UgNzIgKGZpZnRoIGNoZWNrKSBzYXlzIDogIklmIHRoZSBBQ0sgaXMg YQogICAgICAgICAgICAgICAgICAgICAgICBeICAgICAgICAgICAgICAgICAgICAgICAgICBeXgog ICBkdXBsaWNhdGUgKFNFRy5BQ0sgPCBTTkQuVU5BKSwgaXQgY2FuIGJlIGlnbm9yZWQuICBJZiB0 aGUgQUNLCiAgIGFja25vd2xlZGdlcyBzb21ldGhpbmcgbm90IHlldCBzZW50IChTRUcuQUNLID4g U05ELk5YVCkgdGhlbiBzZW5kIGFuCnwgIEFDSywgZHJvcCB0aGUgc2VnbWVudCwgYW5kIHJldHVy biIgVGhpcyBtaXRpZ2F0aW9uIG1ha2VzIHRoZSBBQ0sKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgXl4KICAgY2hlY2sgbW9yZSBzdHJpbmdlbnQgc2luY2UgYW55IEFDSyA8IFNO RC5VTkEgd291bGRuJ3QgYmUgYWNjZXB0ZWQsCnwgIGluc3RlYWQgb25seSBBQ0sncyB3aGljaCBh cmUgaW4gdGhlIHJhbmdlICgoU05ELlVOQSAtIE1BWC5TTkQuV05EKSA8PQogICAgICAgICAgICAg ICAgICAgXl4KICAgU0VHLkFDSyA8PSBTTkQuTlhUKSBnZXRzIHRocm91Z2guCi0tLQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWy4uLl0uICBJdCBu ZWVkcyB0bwp8ICBiZSBub3RlZCB0aGF0IFJGQyA3OTMgb24gcGFnZSA3MiAoZmlmdGggY2hlY2sp IHNheXM6ICJJZiB0aGUgQUNLIGlzIGEKICAgICAgICAgICAgICAgICAgICAgICAgXl5eXiAgICAg ICAgICAgICAgICAgICAgICAgICAgXgogICBkdXBsaWNhdGUgKFNFRy5BQ0sgPCBTTkQuVU5BKSwg aXQgY2FuIGJlIGlnbm9yZWQuICBJZiB0aGUgQUNLCiAgIGFja25vd2xlZGdlcyBzb21ldGhpbmcg bm90IHlldCBzZW50IChTRUcuQUNLID4gU05ELk5YVCkgdGhlbiBzZW5kIGFuCnwgIEFDSywgZHJv cCB0aGUgc2VnbWVudCwgYW5kIHJldHVybi4iICBUaGlzIG1pdGlnYXRpb24gbWFrZXMgdGhlIEFD SwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBeXl5eCiAgIGNoZWNrIG1vcmUg c3RyaW5nZW50IHNpbmNlIGFueSBBQ0sgPCBTTkQuVU5BIHdvdWxkbid0IGJlIGFjY2VwdGVkLAp8 ICBpbnN0ZWFkIG9ubHkgQUNLcyB3aGljaCBhcmUgaW4gdGhlIHJhbmdlICgoU05ELlVOQSAtIE1B WC5TTkQuV05EKSA8PQogICAgICAgICAgICAgICAgICAgXl4KICAgU0VHLkFDSyA8PSBTTkQuTlhU KSBnZXRzIHRocm91Z2guCgpOb3RlOiBUaGUgcXVvdGF0aW9uIGNvbXByaXNlcyBtdWx0aXBsZSBz ZW50ZW5jZXM7IGhlbmNlIHRoZSAicmF0aW9uYWwKICAgICAgcXVvdGF0aW9uIiBydWxlIG9mIHRo ZSBSRkMtRWQgZG9lcyBub3QgYXBwbHkuCgoKSU1PLCBvdGhlcndpc2UgdGhlIGRyYWZ0IGlzIHJl YWR5IHRvIGdvLCBhbmQgYmVjYXVzZSBvZiB0aGUgaW1wb3J0YW5jZQpvZiB0aGUgdG9waWMsIGl0 IHNob3VsZCBub3cgYmUgYWR2YW5jZWQgcXVpY2tseSEKCktpbmQgcmVnYXJkcywKICBBbGZyZWQg SM5uZXMuCgotLSAKCistLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCnwgVFItU3lzIEFsZnJlZCBIb2VuZXMgICB8ICBB bGZyZWQgSG9lbmVzICAgRGlwbC4tTWF0aC4sIERpcGwuLVBoeXMuICB8CnwgR2VybGluZ2VyIFN0 cmFzc2UgMTIgICB8ICBQaG9uZTogKCs0OSk3MTU2Lzk2MzUtMCwgRmF4OiAtMTggICAgICAgICB8 CnwgRC03MTI1NCAgRGl0emluZ2VuICAgICB8ICBFLU1haWw6ICBhaEBUUi1TeXMuZGUgICAgICAg ICAgICAgICAgICAgICB8CistLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCgpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwp0Y3BtIG1haWxpbmcgbGlzdAp0Y3BtQGlldGYub3JnCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNwbQo= From tcpm-bounces@ietf.org Thu Aug 14 08:27:56 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D88383A6ACF; Thu, 14 Aug 2008 08:27:56 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 211743A6ACF for ; Thu, 14 Aug 2008 08:27:55 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lwt0e4C7il6J for ; Thu, 14 Aug 2008 08:27:54 -0700 (PDT) Received: from owa.neterion.com (mx.neterion.com [72.1.205.142]) by core3.amsl.com (Postfix) with ESMTP id 1930C3A6886 for ; Thu, 14 Aug 2008 08:27:53 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 14 Aug 2008 11:27:13 -0400 Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD77040E3E2E@nekter> In-Reply-To: <396556a20808121155h4e3c551aqcf5260d551bcdd4a@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] SYN/ACK Payloads, draft 01 Thread-Index: Acj8rS3J837JTcOLQU2FA/aoetRZkgBcliAw References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com><000001c8fbfe$0dba0960$292e1c20$@pt><396556a20808111617n622aceabn62db0d55b25ae712@mail.gmail.com><000301c8fc81$8e02d470$aa087d50$@pt><396556a20808120914k6d087534o5c34dfd51dd7d1c5@mail.gmail.com><000b01c8fc9f$4d9f3c20$e8ddb460$@pt> <396556a20808121155h4e3c551aqcf5260d551bcdd4a@mail.gmail.com> From: "Caitlin Bestler" To: "Adam Langley" , Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org There are several separable issues here. Each needs to be considered on its own to determine if they should be addressed by TCPM. 1) The sockets API forces applications to supply the necessary content for the first application message only after connection establishment has been signaled to the application layer. This typically results in an unneeded round-trip between the application domain and the TCP stack domain, which under most conventional Operating Systems is relatively expensive. This is true. In addition to the problem cited, virtually all client applications could supply the first request message in the same call/request to initiate the connection. But optimizing the local TCP stack interface can be done by any TCP stack developer. It is a local interface. No IETF permission is required. 2) There are applications which would benefit from having optional application payload during connection setup. Such optional application payload is optionally provided by the client, and optionally provided to the server if the server requests it. This allows a "free upgrade" to the upper layer protocol, because *both* sender and receiver must be aware of the enhanced transport capability. If either is unaware, the protocol functions in compatibility mode based on the pre-existing definition of the TCP Stream. While this is an application layer problem that any application could have solved on its own, there is some merit in providing this as a generic transport capability precisely because it enables support of existing clients and servers. This is especially relevant when the client obtains the server contact info through a URL whose format and distribution is already fixed (meaning that the URL cannot effectively be used to tell the client which way to attempt the connection). As the draft points out, the goal of the optional data is typically to expedite latency, therefore trial and error probing for capabilities would undermine the intended benefit. The two strongest counter-arguments against supporting such an option are 1) it's new, all new TCP features should be viewed with suspicion and avoided unless their benefits are strong, and 2) Designing a feature that deliberately throws away some of the TCP payload stream seems contrary to the whole concept of a reliable transport. 3) The presence of this optional payload should be signaled through TCP options. If this is going to be done, this is the only way to do it. The existing definition of TCP payloads encompasses all possible byte streams. Therefore the alternate semantics must come from outside of the TCP payload stream itself. For ULPs driven by URLs (HTTP, SMTP, etc.) the TCP options are the only solution. 4) The size of the optional payload is what fits in the SYN ACK response. I have a major problem with this. Having an option to indicate that the TCP payload stream will start with a special header that documents its own length would make a lot more sense to me. The key problem here is that if the active side is not capable of delivering SYN-ACK payload it will just not ACK that portion. There is no guarantee that the resulting retransmit will be segmented the same way. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 14 09:40:44 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A3423A6DB7; Thu, 14 Aug 2008 09:40:44 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 581883A6D53 for ; Thu, 14 Aug 2008 09:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.435 X-Spam-Level: X-Spam-Status: No, score=0.435 tagged_above=-999 required=5 tests=[AWL=-1.576, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_STOCK2=3.988] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQJrTcCSFxbx for ; Thu, 14 Aug 2008 09:40:42 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by core3.amsl.com (Postfix) with ESMTP id 1452D3A6D17 for ; Thu, 14 Aug 2008 09:40:42 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so439071rvf.49 for ; Thu, 14 Aug 2008 09:40:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=dAIYDTmstaw4vOKQj+YMugsZb7iJUSzl5dlyXVQTy9w=; b=b5QqDEEQdu7vIw/OxxMsYTT0YHikrmuSrxLOWbBqeznlqw/JPYV7tzr6tWbwCP2c6/ vaXVxUZo2PIw/G44xU6EjfesoBmIHaR7BxoVB25Vb39ynE4FS/L1sgr97y9X86OmkytD MpwzJQbFEW486REoKyx6VV7ICAd/vA0v6jXWs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=Q5HrL+KvYm9asC1+YfMqm+hvP6kJCjN12OxBIySlxO2L0SCqS6j4zvXKx4oZmXsdOQ Xmn7Np837qQIrkHxGMwmgYzUZj7xK3jhecx2q/EjENt1uSmLz2r/2SQs2Xo42eJUt8Ha bju6v8eDeN9KU40X29SMdp0r0v0GcId3mt7ss= Received: by 10.141.142.15 with SMTP id u15mr824701rvn.171.1218732046273; Thu, 14 Aug 2008 09:40:46 -0700 (PDT) Received: by 10.141.37.3 with HTTP; Thu, 14 Aug 2008 09:40:46 -0700 (PDT) Message-ID: <396556a20808140940p63dec2d2ib3332b27da8260ae@mail.gmail.com> Date: Thu, 14 Aug 2008 09:40:46 -0700 From: "Adam Langley" To: "Joe Touch" In-Reply-To: <48A3C0B3.8050003@isi.edu> MIME-Version: 1.0 Content-Disposition: inline References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <20080813195027.C4C5B50848@romeo.rtfm.com> <396556a20808131307r65a9f6a0oe4365be029620b2c@mail.gmail.com> <48A35CFA.4060709@isi.edu> <396556a20808131525i20dabf06w7a7a11e3468e541a@mail.gmail.com> <48A36104.6000000@isi.edu> <396556a20808131605w2ccac3ceo21160401e4545c15@mail.gmail.com> <48A383F0.9030601@isi.edu> <396556a20808131827x1ab32b13yaa9358ac1a70c6ed@mail.gmail.com> <48A3C0B3.8050003@isi.edu> X-Google-Sender-Auth: 00862bc176bbbe3b Cc: tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Wed, Aug 13, 2008 at 10:20 PM, Joe Touch wrote: > I'm confused now; your code - and your note. Let's go back to the key issue: > > - is the data received by the client dependent on the option? I do apologise, the confusion is my fault: There are two extensions interacting here. Firstly, there's an extension to include data in the SYNACK. Then there's the application layer signaling with the option. I was outlining the code for the latter. The former is an extension that could be deployed today, it's managed with a setsockopt on the server socket: struct tcpsa tcpsa; memcpy(tcpsa.tcpsa_payload, mysynackdata, length); setsockopt(socket, SOL_TCP, TCP_SADATA, &tcpsa, sizeof(tcpsa)); listen(socket); for (;;) { accept(); ... } Obviously, this is just an implementation detail. It's nice for sockets based APIs to do it like this. Since such stacks are dominant, the idea of a constant payload appears in the draft. I make a couple of exceptions to this. The ability to include a 64-bit nonce is very useful and easy for the stack to manage. That's done with: struct tcpsa tcpsa; memcpy(tcpsa.tcpsa_payload, mysynackdata, length); tcpsa.tcpsa_flags = TCP_SADATA_INC_NONCE; tcpsa.tcpsa_nonce_offset = 0; setsockopt(socket, SOL_TCP, TCP_SADATA, &tcpsa, sizeof(tcpsa)); Also, the ability to only send this data when the SYN includes the SAPP option. At the moment, this is the default, although there is space in the flags set aside for when I get round to it. Example client side code and stack patches are referenced below. Again, this is just to appease the sockets API. Stacks like [1] allow the application to process the SYN directly and construct any SYNACK payload they like on a per-packet basis. [1] http://tservice.net.ru/~s0mbre/old/?section=projects&item=unetstack > As a final question, if this is experimental, why not just use the > experimental TCP option KIND? > > (and how much of this has been implemented, traced, and checked for > things like simultaneous open - I don't recall if you noted that before) A linux patch[2] has been reviewed by the networking maintainer, although I haven't asked for it to be applied yet because it's not quite final. (It's using an experimental KIND number for one). Example client side code example can be found at [3]. This includes preload code to support Apache, Firefox etc (screenshot: [4]). It's been tested by several people over the real Internet. (Note that [3] is just a dump of my current code, it has many rough edges at the moment. And ignore the TCP-AO stuff therein, it's #ifdef'ed out). Also, I believe that I currently have the Diffie-Hellman speed record with [5] since my implementation is 10% faster than the previously claimed best[6]. (The version in [3] is much slower, I've yet to update it.) I'm am currently using an experimental KIND. However, if I were to, say, deploy this on all the Google frontend servers (hypothetically, of course), I suspect that would be in excess of what the experimental kinds were for. As for simultaneous open. The linux patch handles it by not doing anything different. The option may be carried in the SYN, but the ACKs are as normal. Since all BSD like stacks would, very likely, work the same, it might be best to specify that behaviour in the draft. Cheers AGL [2] http://marc.info/?l=linux-netdev&m=121857466907992&w=2 [3] http://www.imperialviolet.org/binary/libobstcp-0.2a.tar.bz2 [4] http://bp3.blogger.com/_kRcqvZJgJFs/SH0B_oPSlzI/AAAAAAAAAUM/eg-IxgbyhIs/s1600-h/firefox-obstcp.png [5] http://code.google.com/p/curve25519-donna [6] http://cr.yp.to/ecdh/reports.html -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 14 09:57:04 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D313C3A6C5E; Thu, 14 Aug 2008 09:57:04 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EDAE3A6942 for ; Thu, 14 Aug 2008 09:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.605 X-Spam-Level: X-Spam-Status: No, score=-0.605 tagged_above=-999 required=5 tests=[AWL=-1.994, BAYES_00=-2.599, FRT_STOCK2=3.988] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9iTkywEPd9ZU for ; Thu, 14 Aug 2008 09:57:03 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 052733A6CB2 for ; Thu, 14 Aug 2008 09:57:00 -0700 (PDT) Received: from [75.214.2.40] (40.sub-75-214-2.myvzw.com [75.214.2.40]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m7EGtxq1001476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Aug 2008 09:56:02 -0700 (PDT) Message-ID: <48A46373.4090606@isi.edu> Date: Thu, 14 Aug 2008 09:55:15 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Adam Langley References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <20080813195027.C4C5B50848@romeo.rtfm.com> <396556a20808131307r65a9f6a0oe4365be029620b2c@mail.gmail.com> <48A35CFA.4060709@isi.edu> <396556a20808131525i20dabf06w7a7a11e3468e541a@mail.gmail.com> <48A36104.6000000@isi.edu> <396556a20808131605w2ccac3ceo21160401e4545c15@mail.gmail.com> <48A383F0.9030601@isi.edu> <396556a20808131827x1ab32b13yaa9358ac1a70c6ed@mail.gmail.com> <48A3C0B3.8050003@isi.edu> <396556a20808140940p63dec2d2ib3332b27da8260ae@mail.gmail.com> In-Reply-To: <396556a20808140940p63dec2d2ib3332b27da8260ae@mail.gmail.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FWIW, IMO it is not wise to deploy code into a widely-used codebase that uses the experimental KIND values. Experiments should be controlled. See RFC4727, notably: ~ ... The network scope of support ~ for experimental values should carefully be evaluated before ~ deploying any experiment across extended network domains, such as the ~ public Internet. Joe Adam Langley wrote: | On Wed, Aug 13, 2008 at 10:20 PM, Joe Touch wrote: |> I'm confused now; your code - and your note. Let's go back to the key issue: |> |> - is the data received by the client dependent on the option? | | I do apologise, the confusion is my fault: | | There are two extensions interacting here. Firstly, there's an | extension to include data in the SYNACK. Then there's the application | layer signaling with the option. I was outlining the code for the | latter. The former is an extension that could be deployed today, it's | managed with a setsockopt on the server socket: | | struct tcpsa tcpsa; | memcpy(tcpsa.tcpsa_payload, mysynackdata, length); | setsockopt(socket, SOL_TCP, TCP_SADATA, &tcpsa, sizeof(tcpsa)); | | listen(socket); | | for (;;) { accept(); ... } | | Obviously, this is just an implementation detail. It's nice for | sockets based APIs to do it like this. Since such stacks are dominant, | the idea of a constant payload appears in the draft. I make a couple | of exceptions to this. The ability to include a 64-bit nonce is very | useful and easy for the stack to manage. That's done with: | | struct tcpsa tcpsa; | memcpy(tcpsa.tcpsa_payload, mysynackdata, length); | tcpsa.tcpsa_flags = TCP_SADATA_INC_NONCE; | tcpsa.tcpsa_nonce_offset = 0; | setsockopt(socket, SOL_TCP, TCP_SADATA, &tcpsa, sizeof(tcpsa)); | | Also, the ability to only send this data when the SYN includes the | SAPP option. At the moment, this is the default, although there is | space in the flags set aside for when I get round to it. | | Example client side code and stack patches are referenced below. | | Again, this is just to appease the sockets API. Stacks like [1] allow | the application to process the SYN directly and construct any SYNACK | payload they like on a per-packet basis. | | [1] http://tservice.net.ru/~s0mbre/old/?section=projects&item=unetstack | |> As a final question, if this is experimental, why not just use the |> experimental TCP option KIND? |> |> (and how much of this has been implemented, traced, and checked for |> things like simultaneous open - I don't recall if you noted that before) | | A linux patch[2] has been reviewed by the networking maintainer, | although I haven't asked for it to be applied yet because it's not | quite final. (It's using an experimental KIND number for one). Example | client side code example can be found at [3]. This includes preload | code to support Apache, Firefox etc (screenshot: [4]). It's been | tested by several people over the real Internet. (Note that [3] is | just a dump of my current code, it has many rough edges at the moment. | And ignore the TCP-AO stuff therein, it's #ifdef'ed out). | | Also, I believe that I currently have the Diffie-Hellman speed record | with [5] since my implementation is 10% faster than the previously | claimed best[6]. (The version in [3] is much slower, I've yet to | update it.) | | I'm am currently using an experimental KIND. However, if I were to, | say, deploy this on all the Google frontend servers (hypothetically, | of course), I suspect that would be in excess of what the experimental | kinds were for. | | As for simultaneous open. The linux patch handles it by not doing | anything different. The option may be carried in the SYN, but the ACKs | are as normal. Since all BSD like stacks would, very likely, work the | same, it might be best to specify that behaviour in the draft. | | | Cheers | | | AGL | | [2] http://marc.info/?l=linux-netdev&m=121857466907992&w=2 | [3] http://www.imperialviolet.org/binary/libobstcp-0.2a.tar.bz2 | [4] http://bp3.blogger.com/_kRcqvZJgJFs/SH0B_oPSlzI/AAAAAAAAAUM/eg-IxgbyhIs/s1600-h/firefox-obstcp.png | [5] http://code.google.com/p/curve25519-donna | [6] http://cr.yp.to/ecdh/reports.html | | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkikY3IACgkQE5f5cImnZru7hQCg1o2zdXMursx8kNpgMLh0xtuj R+EAoOTQhKfHeKusrxwDuxY1qCO68oee =r4iA -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 14 09:59:56 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 708483A6C45; Thu, 14 Aug 2008 09:59:56 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ADF33A6C45 for ; Thu, 14 Aug 2008 09:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.428 X-Spam-Level: X-Spam-Status: No, score=-1.428 tagged_above=-999 required=5 tests=[AWL=0.549, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIholjAAXnLv for ; Thu, 14 Aug 2008 09:59:54 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by core3.amsl.com (Postfix) with ESMTP id C86493A6BB4 for ; Thu, 14 Aug 2008 09:59:54 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so445589rvf.49 for ; Thu, 14 Aug 2008 09:59:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=FBewD5U7UQr2TsP6oylDEzT4YtCj3rc88T1cBVcgA+U=; b=CfX3PdROOitJ6q/uA+k2C6Pp4JMVp9lySG6Y9UgVKjo6jHwXKO6PBKsgYVnD6Vpk36 kpv0hCgZOsRR8XFJLQPOBjHcFMYZiMgdhBT/9pKbZKcKZd8KezB1aHBrXGfQIwt0Pffr 22BCrsbJZsMy+1xfnokgYhPqh7rwo8zgyvOcI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=lYc6qiWTFbZuqpMjuNir6CVRFYNorkasgLgh3HIqtzJZzCUfWEdvoWUHLRbNrFlxjV vmflAAnoH49hyRpDoDupeIwyfDWSd0aKZKGEc9AtD9UnpKc70Gjn1DAcA+CjNVm/VWyy Tw79S1z03FiZ3n6u/D7tbk6CPGRABrunDQWj0= Received: by 10.141.113.6 with SMTP id q6mr838705rvm.135.1218733190789; Thu, 14 Aug 2008 09:59:50 -0700 (PDT) Received: by 10.141.37.3 with HTTP; Thu, 14 Aug 2008 09:59:50 -0700 (PDT) Message-ID: <396556a20808140959k639aa174wc2a5809b5b69cdbd@mail.gmail.com> Date: Thu, 14 Aug 2008 09:59:50 -0700 From: "Adam Langley" To: "Joe Touch" In-Reply-To: <48A46373.4090606@isi.edu> MIME-Version: 1.0 Content-Disposition: inline References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <48A35CFA.4060709@isi.edu> <396556a20808131525i20dabf06w7a7a11e3468e541a@mail.gmail.com> <48A36104.6000000@isi.edu> <396556a20808131605w2ccac3ceo21160401e4545c15@mail.gmail.com> <48A383F0.9030601@isi.edu> <396556a20808131827x1ab32b13yaa9358ac1a70c6ed@mail.gmail.com> <48A3C0B3.8050003@isi.edu> <396556a20808140940p63dec2d2ib3332b27da8260ae@mail.gmail.com> <48A46373.4090606@isi.edu> X-Google-Sender-Auth: 5dc2b64016496d73 Cc: tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Thu, Aug 14, 2008 at 9:55 AM, Joe Touch wrote: > FWIW, IMO it is not wise to deploy code into a widely-used codebase that > uses the experimental KIND values. Experiments should be controlled. Agreed. I've not requested that the Linux patch be applied, primarily because it's using an experimental kind number. That's also way I'm requesting a real option number. Cheers -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 14 10:06:34 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7E9E3A6C89; Thu, 14 Aug 2008 10:06:34 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE4273A6C60 for ; Thu, 14 Aug 2008 10:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.392 X-Spam-Level: X-Spam-Status: No, score=0.392 tagged_above=-999 required=5 tests=[AWL=-0.997, BAYES_00=-2.599, FRT_STOCK2=3.988] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2Y5b2-MAzyZ for ; Thu, 14 Aug 2008 10:06:32 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 190DB3A6B7F for ; Thu, 14 Aug 2008 10:06:32 -0700 (PDT) Received: from [75.214.2.40] (40.sub-75-214-2.myvzw.com [75.214.2.40]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m7EH60kh006995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Aug 2008 10:06:02 -0700 (PDT) Message-ID: <48A465CC.8000402@isi.edu> Date: Thu, 14 Aug 2008 10:05:16 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Adam Langley References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <20080813195027.C4C5B50848@romeo.rtfm.com> <396556a20808131307r65a9f6a0oe4365be029620b2c@mail.gmail.com> <48A35CFA.4060709@isi.edu> <396556a20808131525i20dabf06w7a7a11e3468e541a@mail.gmail.com> <48A36104.6000000@isi.edu> <396556a20808131605w2ccac3ceo21160401e4545c15@mail.gmail.com> <48A383F0.9030601@isi.edu> <396556a20808131827x1ab32b13yaa9358ac1a70c6ed@mail.gmail.com> <48A3C0B3.8050003@isi.edu> <396556a20808140940p63dec2d2ib3332b27da8260ae@mail.gmail.com> In-Reply-To: <396556a20808140940p63dec2d2ib3332b27da8260ae@mail.gmail.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adam Langley wrote: | On Wed, Aug 13, 2008 at 10:20 PM, Joe Touch wrote: |> I'm confused now; your code - and your note. Let's go back to the key issue: |> |> - is the data received by the client dependent on the option? | | I do apologise, the confusion is my fault: | | There are two extensions interacting here. Firstly, there's an | extension to include data in the SYNACK. Then there's the application | layer signaling with the option. I was outlining the code for the | latter. The former is an extension that could be deployed today, it's | managed with a setsockopt on the server socket: | | struct tcpsa tcpsa; | memcpy(tcpsa.tcpsa_payload, mysynackdata, length); | setsockopt(socket, SOL_TCP, TCP_SADATA, &tcpsa, sizeof(tcpsa)); | | listen(socket); | | for (;;) { accept(); ... } | | Obviously, this is just an implementation detail. It's a lot more than that; it hints that the socket interface is insufficient for using the available TCP capability for sending data with either SYNs or SYN-ACKs. I'm wondering how/if this has been explored before, and whether there would be a solution that maps to TCP's model of a stream better. The socket option above is incorrect, IMO. It implies that the user should have control over data that ends up in the SYN-ACK directly; IMO, TCP's stream model should allow only that data be written to the stream early - which may require a socket option - BUT should *not* imply that the data maps to the SYN-ACK directly. E.g., what happens if the data is larger than the MSS? Or if the SYN-ACK comes back with an ICMP 'too-big'? I.e., this should be called just TCP_DATA, not TCP_SADATA. | It's nice for | sockets based APIs to do it like this. Since such stacks are dominant, | the idea of a constant payload appears in the draft. I make a couple | of exceptions to this. The ability to include a 64-bit nonce is very | useful and easy for the stack to manage. That's done with: | | struct tcpsa tcpsa; | memcpy(tcpsa.tcpsa_payload, mysynackdata, length); | tcpsa.tcpsa_flags = TCP_SADATA_INC_NONCE; | tcpsa.tcpsa_nonce_offset = 0; | setsockopt(socket, SOL_TCP, TCP_SADATA, &tcpsa, sizeof(tcpsa)); | | Also, the ability to only send this data when the SYN includes the | SAPP option. At the moment, this is the default, although there is | space in the flags set aside for when I get round to it. I do not understand the semantics of a TCP option that changes the TCP stream. TCP is a stream-oriented protocol, and each connection provides one stream. If you want a separate channel, you ought to be using a different protocol, e.g., SCTP. | Example client side code and stack patches are referenced below. | | Again, this is just to appease the sockets API. Stacks like [1] allow | the application to process the SYN directly and construct any SYNACK | payload they like on a per-packet basis. That's fine as an implementation decision, as Caitlin notes, but has no business affecting the TCP protocol spec. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkikZcsACgkQE5f5cImnZrso6ACgoHYVA1x+SiEZE+I/WIKPeBlL nekAoKTmhId3CpGqVk4cwaRjQ/7/AHjf =XmHR -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 14 10:14:49 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 928513A6E07; Thu, 14 Aug 2008 10:14:49 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2FC73A6E01 for ; Thu, 14 Aug 2008 10:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.47 X-Spam-Level: X-Spam-Status: No, score=-1.47 tagged_above=-999 required=5 tests=[AWL=0.507, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDwI+qbWGyBt for ; Thu, 14 Aug 2008 10:14:48 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by core3.amsl.com (Postfix) with ESMTP id EE2643A6E07 for ; Thu, 14 Aug 2008 10:14:47 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so450692rvf.49 for ; Thu, 14 Aug 2008 10:14:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=cTkg8t1SlS472lha+BV1/7BVZp63O6cQxuhlulMGWz0=; b=ga9I6gSF/ovG2NJT69Z/AAyqEj5964Lva/sLfrnhimqqE4On2FSYmnOHyw/QAAz5Qy hF8qW/L0h+eauKegjaSaAHDllydVrabA42Xl++Qt0RE+yF5t4puAFkpfX1DcSNMHorAO xn1uRpah3PtQXq+LtJQaymPNHnTDvkU82ZhNc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=wzVd18UiHbhR/nb2I6b/f3Ltmc7MMnaWflO3lPfjpohqKf2+ewN+y22QfOZacZi5yq az9Qgd7HYVIp/ibekQaMns023ZfBjr6zMxXoqWQJEdiFBSQW0+PCJRD5HIAPA8H3ozvn Ke81L0IarAPjKUWZRMeS2JxIIWO2GqdVTSwdc= Received: by 10.141.5.3 with SMTP id h3mr850835rvi.138.1218734091329; Thu, 14 Aug 2008 10:14:51 -0700 (PDT) Received: by 10.141.37.3 with HTTP; Thu, 14 Aug 2008 10:14:51 -0700 (PDT) Message-ID: <396556a20808141014m459e07ebh667aaee60e355ac9@mail.gmail.com> Date: Thu, 14 Aug 2008 10:14:51 -0700 From: "Adam Langley" To: "Caitlin Bestler" In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD77040E3E2E@nekter> MIME-Version: 1.0 Content-Disposition: inline References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <000001c8fbfe$0dba0960$292e1c20$@pt> <396556a20808111617n622aceabn62db0d55b25ae712@mail.gmail.com> <000301c8fc81$8e02d470$aa087d50$@pt> <396556a20808120914k6d087534o5c34dfd51dd7d1c5@mail.gmail.com> <000b01c8fc9f$4d9f3c20$e8ddb460$@pt> <396556a20808121155h4e3c551aqcf5260d551bcdd4a@mail.gmail.com> <78C9135A3D2ECE4B8162EBDCE82CAD77040E3E2E@nekter> X-Google-Sender-Auth: 5b165c73be2bd24a Cc: tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org If I might address your concern first: On Thu, Aug 14, 2008 at 8:27 AM, Caitlin Bestler wrote: > 4) The size of the optional payload is what fits in the SYN ACK > response. > > I have a major problem with this. Having an option to indicate > that the TCP payload stream will start with a special header > that documents its own length would make a lot more sense to me. > > The key problem here is that if the active side is not capable of > delivering SYN-ACK payload it will just not ACK that portion. > There is no guarantee that the resulting retransmit will be > segmented the same way. I've not included any details of the application level data in the draft because I didn't think it to be in scope for TCPM. However, the payload is self deliminating. It has to be because, if you are a client application using the sockets API you might not run for an arbitary amount of time. In that time, the server can have sent any amount of data and there's no deliminators in the bytestream from the socket. If you are interested, I've included by current notes on the format at the end of this email. (It's certainly not set in stone). However, the draft does require a minimal level of support in conforming stacks to allow applications to decide not to use the ability unless they know that it has certain charactoristics. That minimal level is: the active open side must be able to enqueue 64 bytes of payload from a SYN/ACK and that the server be able to include 64-byte of data in a SYN/ACK. I'll skip the points with which I agree with entirely. > and 2) Designing a feature that deliberately throws away some > of the TCP payload stream seems contrary to the whole concept > of a reliable transport. Here you are thinking about including SYN/ACK payloads when many clients will ignore them? It does have some inefficiency problems, I'll agree. However, I mostly expect that SYN/ACK payloads will only be returned to clients which have explicitly requested it with an option. There are certainly some server-speaks-first protocols (like SMTP) which could oppitunistically use SYN/ACK payloads. Then the inefficiency decision has to be made on a per application basis, probably a config option somewhere. Cheers --- Current notes on the possible format of the start of the application data streams --- This is nothing to do with TCP. It describes an extensible, self deliminating format which is expected to prefix the usual application data (say HTTP) in both directions: // The format is like a TCP options structure. We wish to have an extensible // set of options. // // The payload is in two sections. First, a bit-packed list of option numbers // and payload lengths. Second, byte aligned, the payloads of all those // options, concatenated. // // Numbers in the first part are encoded thus: // // The number of bits needed is encoded in uniary form, terminated by a zero // bit, followed by that many bits. // // Thus, 0 is encoded with a single 0 bit. // One is encoded by specify that one bit is needed with bits 10, followed by // one bit of content. This bit is actually a zero. Since we already know that // the number isn't 0, we bias the payload by one. // // Likewise, four is encoded with 110 to specify two bits, followed by 01. // Since the 110 means that the smallest number that it could be is three, we // only need to add one to make four. // // The first part of the payload is then a list of (kind number delta, payload // length) tuples, where both elements are numbers, encoded as above. The kind // numbers MUST appear in order, smallest first. The delta of the tuple // specifies the difference between the current kind number and the next one. // The current kind number is initially 0. A delta of 0 terminates the list. // Such a delta doesn't have a payload length following it. // // Kinds which are a power of two (1, 2, 4, 8, ...) are defined to be protocol // agnostic. Other kind numbers are availible for per-protocol options. // // Kinds 1 and 2 are special in that they have no payload length encoded. The // payload length of kind 1 is defined to be 40 bytes and the payload length of // kind 2 is defined to be 0 bytes. // // After all the tuples have been encoded, 0 bits are added to align to the // next 8-bit boundary. Then the payloads are added, in order. // // If the end of the first section and the end of the whole bytestring lie within the same 4-byte word, 0 bytes are appened to pad to the next 4 byte word. -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 14 10:23:33 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 466F13A6B77; Thu, 14 Aug 2008 10:23:33 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17DBF3A6B77 for ; Thu, 14 Aug 2008 10:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.017 X-Spam-Level: X-Spam-Status: No, score=0.017 tagged_above=-999 required=5 tests=[AWL=-1.994, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_STOCK2=3.988] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+qQ06a5rs6E for ; Thu, 14 Aug 2008 10:23:27 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by core3.amsl.com (Postfix) with ESMTP id 8DE743A696B for ; Thu, 14 Aug 2008 10:23:27 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id x19so444358pyg.24 for ; Thu, 14 Aug 2008 10:23:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=OsX2h2sz+6oxYEZsYvYINirzhG81i+V/CSDlmeJTuD8=; b=jZoBS10NOGSN87B6AAPtXcyJ4k7xLHiOBvCrYZGVjCrS8jf80/ijYeuE5D48euZIJf dc/a6Xu+6QvpdES2RGNjMkGPQrrGE0LRsxpBQQwAHRjC1Ri+DfC4OVdbi8mHq3DzM4vU /hez/bNYk9IMYdCsrPVxtqQO4JuMzUNwyrRB8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=Bcr1pbu0xXNmgSsQ5Hsop9zzOWwVEXM7NJIuNJ/jTp8F9OBvnXFPe6gW3a49To9Qvv V55Ro1t2FS0dNsM+VOnKcB8ezuhhAG4dJiBPJAzEBEoekOU4B2Nz2kH3oX69RXVal7XN Dt2tZNBL1cXnHDjXQWkMA9RRF5gB8K8Qb11Ts= Received: by 10.141.179.5 with SMTP id g5mr858922rvp.30.1218734611397; Thu, 14 Aug 2008 10:23:31 -0700 (PDT) Received: by 10.141.37.3 with HTTP; Thu, 14 Aug 2008 10:23:31 -0700 (PDT) Message-ID: <396556a20808141023s3abddc96u43b9e6e7898033ed@mail.gmail.com> Date: Thu, 14 Aug 2008 10:23:31 -0700 From: "Adam Langley" To: "Joe Touch" In-Reply-To: <48A465CC.8000402@isi.edu> MIME-Version: 1.0 Content-Disposition: inline References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <48A35CFA.4060709@isi.edu> <396556a20808131525i20dabf06w7a7a11e3468e541a@mail.gmail.com> <48A36104.6000000@isi.edu> <396556a20808131605w2ccac3ceo21160401e4545c15@mail.gmail.com> <48A383F0.9030601@isi.edu> <396556a20808131827x1ab32b13yaa9358ac1a70c6ed@mail.gmail.com> <48A3C0B3.8050003@isi.edu> <396556a20808140940p63dec2d2ib3332b27da8260ae@mail.gmail.com> <48A465CC.8000402@isi.edu> X-Google-Sender-Auth: 9b9a3485ebe71395 Cc: tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Thu, Aug 14, 2008 at 10:05 AM, Joe Touch wrote: > It's a lot more than that; it hints that the socket interface is > insufficient for using the available TCP capability for sending data > with either SYNs or SYN-ACKs. I'm wondering how/if this has been > explored before, and whether there would be a solution that maps to > TCP's model of a stream better. > > The socket option above is incorrect, IMO. It implies that the user > should have control over data that ends up in the SYN-ACK directly; IMO, > TCP's stream model should allow only that data be written to the stream > early - which may require a socket option - BUT should *not* imply that > the data maps to the SYN-ACK directly. > > E.g., what happens if the data is larger than the MSS? Or if the SYN-ACK > comes back with an ICMP 'too-big'? I.e., this should be called just > TCP_DATA, not TCP_SADATA. There are several cases: If the setsockopt has requested that the data be included in the stream without exception, then it is enqueued like any other data. If there's space in the SYN/ACK, it can go in there. If not, it will be sent as usual. If the client doesn't ACK a SYNACK payload, it will be retransmitted etc. This requires no standards effort, it's a TODO for me at the moment. If the setsockopt flags request that the data only be sent in reply to SYNs with the SAPP option: If the payload fits in the SYNACK (given MSS etc) then it is transmitted and the option is echoed back. Otherwise, a bare SYNACK (without the option) is sent back. In the latter case, the data is not enqueued to be sent in the future. The applications on both sides are aware of what happened and proceed correctly given the situation. > I do not understand the semantics of a TCP option that changes the TCP > stream. TCP is a stream-oriented protocol, and each connection provides > one stream. If you want a separate channel, you ought to be using a > different protocol, e.g., SCTP. It's not a separate channel, it's just that the option is an application level signal. Caitlin probably puts it's better than I do: "While this is an application layer problem that any application could have solved on its own, there is some merit in providing this as a generic transport capability precisely because it enables support of existing clients and servers." Cheers AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 14 10:32:38 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB75A3A6974; Thu, 14 Aug 2008 10:32:37 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD40F3A6957 for ; Thu, 14 Aug 2008 10:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.724 X-Spam-Level: X-Spam-Status: No, score=0.724 tagged_above=-999 required=5 tests=[AWL=-0.665, BAYES_00=-2.599, FRT_STOCK2=3.988] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyjH0Fc74G2t for ; Thu, 14 Aug 2008 10:32:35 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id C33903A692D for ; Thu, 14 Aug 2008 10:32:35 -0700 (PDT) Received: from [75.214.2.40] (40.sub-75-214-2.myvzw.com [75.214.2.40]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m7EHVnH1021671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Aug 2008 10:31:52 -0700 (PDT) Message-ID: <48A46BD3.4030408@isi.edu> Date: Thu, 14 Aug 2008 10:30:59 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Adam Langley References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <48A35CFA.4060709@isi.edu> <396556a20808131525i20dabf06w7a7a11e3468e541a@mail.gmail.com> <48A36104.6000000@isi.edu> <396556a20808131605w2ccac3ceo21160401e4545c15@mail.gmail.com> <48A383F0.9030601@isi.edu> <396556a20808131827x1ab32b13yaa9358ac1a70c6ed@mail.gmail.com> <48A3C0B3.8050003@isi.edu> <396556a20808140940p63dec2d2ib3332b27da8260ae@mail.gmail.com> <48A465CC.8000402@isi.edu> <396556a20808141023s3abddc96u43b9e6e7898033ed@mail.gmail.com> In-Reply-To: <396556a20808141023s3abddc96u43b9e6e7898033ed@mail.gmail.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adam Langley wrote: | On Thu, Aug 14, 2008 at 10:05 AM, Joe Touch wrote: |> It's a lot more than that; it hints that the socket interface is |> insufficient for using the available TCP capability for sending data |> with either SYNs or SYN-ACKs. I'm wondering how/if this has been |> explored before, and whether there would be a solution that maps to |> TCP's model of a stream better. |> |> The socket option above is incorrect, IMO. It implies that the user |> should have control over data that ends up in the SYN-ACK directly; IMO, |> TCP's stream model should allow only that data be written to the stream |> early - which may require a socket option - BUT should *not* imply that |> the data maps to the SYN-ACK directly. |> |> E.g., what happens if the data is larger than the MSS? Or if the SYN-ACK |> comes back with an ICMP 'too-big'? I.e., this should be called just |> TCP_DATA, not TCP_SADATA. | | There are several cases: | | If the setsockopt has requested that the data be included in the | stream without exception, then it is enqueued like any other data. If | there's space in the SYN/ACK, it can go in there. If not, it will be | sent as usual. If the client doesn't ACK a SYNACK payload, it will be | retransmitted etc. This requires no standards effort, it's a TODO for | me at the moment. OK. So why bother with an option at that point? Why does the user data need to be different if the option is present? If the user data were not different, then this all boils down to a change in the implementation of the API. The trouble is that you're expecting a TCP option to change the *content* of the data stream, and that seems bizarre to me. | If the setsockopt flags request that the data only be sent in reply to | SYNs with the SAPP option: | | If the payload fits in the SYNACK (given MSS etc) then it is | transmitted and the option is echoed back. Otherwise, a bare SYNACK | (without the option) is sent back. In the latter case, the data is not | enqueued to be sent in the future. The applications on both sides are | aware of what happened and proceed correctly given the situation. This is a big change - you're saying that if the payload fits, it goes in the SYN-ACK. If not, *none* of it is sent in the SYN-ACK? Why? TCP provides a *byte stream*. The description above implies that the application knows/sees segment boundaries, which isn't TCP anymore. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkika9IACgkQE5f5cImnZrvUUQCgwS0gBBPzVhXF5YoJCpEw84B7 XCMAnj+w6SpKM39Gv7e9AdrfUmb1allb =OzbR -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 14 10:45:00 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F23783A68FE; Thu, 14 Aug 2008 10:44:59 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10D9E3A6A2C for ; Thu, 14 Aug 2008 10:44:58 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-ul8Mlcmfrd for ; Thu, 14 Aug 2008 10:44:57 -0700 (PDT) Received: from owa.neterion.com (mx.neterion.com [72.1.205.142]) by core3.amsl.com (Postfix) with ESMTP id 325E13A68FE for ; Thu, 14 Aug 2008 10:44:57 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 14 Aug 2008 13:44:36 -0400 Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD77040E3F07@nekter> In-Reply-To: <396556a20808141014m459e07ebh667aaee60e355ac9@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] SYN/ACK Payloads, draft 01 Thread-Index: Acj+MUZEqj8ua0UVRWqdDx0Uy70oPwAA0x9w References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <000001c8fbfe$0dba0960$292e1c20$@pt> <396556a20808111617n622aceabn62db0d55b25ae712@mail.gmail.com> <000301c8fc81$8e02d470$aa087d50$@pt> <396556a20808120914k6d087534o5c34dfd51dd7d1c5@mail.gmail.com> <000b01c8fc9f$4d9f3c20$e8ddb460$@pt> <396556a20808121155h4e3c551aqcf5260d551bcdd4a@mail.gmail.com> <78C9135A3D2ECE4B8162EBDCE82CAD77040E3E2E@nekter> <396556a20808141014m459e07ebh667aaee60e355ac9@mail.gmail.com> From: "Caitlin Bestler" To: "Adam Langley" Cc: tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Adam Langley wrote: > > > and 2) Designing a feature that deliberately throws away some > > of the TCP payload stream seems contrary to the whole concept > > of a reliable transport. > > Here you are thinking about including SYN/ACK payloads when many > clients will ignore them? It does have some inefficiency problems, > I'll agree. However, I mostly expect that SYN/ACK payloads will only > be returned to clients which have explicitly requested it with an > option. There are certainly some server-speaks-first protocols (like > SMTP) which could oppitunistically use SYN/ACK payloads. Then the > inefficiency decision has to be made on a per application basis, > probably a config option somewhere. > My reservation is entirely theoretical. The "overhead" of 64 data bytes on a SYN/ACK frame that is being sent anyway is very slight or even zero, depending on exactly what forms of intermediate queuing are in use. The real concern would be if applications that did not use the special sockopts were to have this special payload automatically discarded by the stack. Automatic discarding of payload, no matter how efficient, just strikes me as contrary to the definition of what it means to be a "reliable transport" service. And experience has taught me that when something looks really bad from a "purely theoretical" viewpoint it merely means that I have not yet identified the specific case where it *will* cause problems. So at the minimum I like to come up with a strong reason why something is intrinsically safe, not just "So far, I haven't thought of how it goes wrong." _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 14 13:03:58 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 312E03A6878; Thu, 14 Aug 2008 13:03:58 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 337503A686D for ; Thu, 14 Aug 2008 13:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.506 X-Spam-Level: X-Spam-Status: No, score=-1.506 tagged_above=-999 required=5 tests=[AWL=0.471, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Krpg3wXqNxIf for ; Thu, 14 Aug 2008 13:03:55 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by core3.amsl.com (Postfix) with ESMTP id 1EDEC3A6878 for ; Thu, 14 Aug 2008 13:03:51 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so508230rvf.49 for ; Thu, 14 Aug 2008 13:03:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=coeOcVVxbL+1aGVZxjf33xkZGoi/28rptCZm+Xxaeac=; b=A2KB3/BDrCo6pBnjtaekdIO2mEVVrLZdKcHguJytKBpZmMayfroY1rpkn4ADbEXlGa hit4Xdy4HUYQlGICRsHtsjAUCwu1hK2ASQkW5GOYzkIGEJEhMr1hESKjOtBsfjKEwl12 OA/HS80WWcIT3zPvVPfZVBKzthEtBbkxXAjLc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=oHiJ1rvE84MZ3eMbO916srzkfoWYSsqnJx6ghmUbl0FPHmYjsjtPZi7P603EehqExm cx2eaq0zqb9RDOZT/vrrW3AsY/+K+gtV44JIBcfFdx912LV2dXYqMCCu/YgPFBMCxCcB 3uhnIKuSB1A+CtTy7QBm1YY+0KssJhe7YDhGQ= Received: by 10.141.33.21 with SMTP id l21mr995215rvj.9.1218744208927; Thu, 14 Aug 2008 13:03:28 -0700 (PDT) Received: by 10.141.37.3 with HTTP; Thu, 14 Aug 2008 13:03:28 -0700 (PDT) Message-ID: <396556a20808141303k341599wfeef32d0841e9f76@mail.gmail.com> Date: Thu, 14 Aug 2008 13:03:28 -0700 From: "Adam Langley" To: "Joe Touch" In-Reply-To: <48A46BD3.4030408@isi.edu> MIME-Version: 1.0 Content-Disposition: inline References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <48A36104.6000000@isi.edu> <396556a20808131605w2ccac3ceo21160401e4545c15@mail.gmail.com> <48A383F0.9030601@isi.edu> <396556a20808131827x1ab32b13yaa9358ac1a70c6ed@mail.gmail.com> <48A3C0B3.8050003@isi.edu> <396556a20808140940p63dec2d2ib3332b27da8260ae@mail.gmail.com> <48A465CC.8000402@isi.edu> <396556a20808141023s3abddc96u43b9e6e7898033ed@mail.gmail.com> <48A46BD3.4030408@isi.edu> X-Google-Sender-Auth: 8453fde795b91652 Cc: tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Thu, Aug 14, 2008 at 10:30 AM, Joe Touch wrote: > OK. So why bother with an option at that point? Why does the user data > need to be different if the option is present? > > If the user data were not different, then this all boils down to a > change in the implementation of the API. The trouble is that you're > expecting a TCP option to change the *content* of the data stream, and > that seems bizarre to me. Because for server-speaks-first application protocols there's no problem. This is just for client-speaks-first protocols. For these protocols, had common stacks been able to send data in the SYN/ACK when they were being designed, then they might have ended up as server-speaks-first protocols. But they didn't for latency reasons. In order for them to take advantage of this they need to be able to signal their compliance somehow. There is, indeed, a cleanliness argument against such a option, but I'm arguing that it's worthwhile for backward compatibility reasons. > This is a big change - you're saying that if the payload fits, it goes > in the SYN-ACK. If not, *none* of it is sent in the SYN-ACK? Why? I'm saying that implementations have latitude here. If the passive open end wishes to ignore the client's option it may. Equally, it may echo it, but not include the data in the SYNACK if the MTU makes it troublesome. In that case, it needs to send it in the next packet as normal. Since the implementation has the best knowledge of what's best, I didn't see any reason to constrain it. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 14 13:14:22 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 860053A6872; Thu, 14 Aug 2008 13:14:22 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF24F3A6872 for ; Thu, 14 Aug 2008 13:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[AWL=0.997, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yefxHCdhNYoQ for ; Thu, 14 Aug 2008 13:14:20 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 6BC7C3A6407 for ; Thu, 14 Aug 2008 13:14:20 -0700 (PDT) Received: from [192.168.1.46] (pool-71-106-119-240.lsanca.dsl-w.verizon.net [71.106.119.240]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m7EKDQiY012167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Aug 2008 13:13:28 -0700 (PDT) Message-ID: <48A491B9.3000209@isi.edu> Date: Thu, 14 Aug 2008 13:12:41 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Adam Langley References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <48A36104.6000000@isi.edu> <396556a20808131605w2ccac3ceo21160401e4545c15@mail.gmail.com> <48A383F0.9030601@isi.edu> <396556a20808131827x1ab32b13yaa9358ac1a70c6ed@mail.gmail.com> <48A3C0B3.8050003@isi.edu> <396556a20808140940p63dec2d2ib3332b27da8260ae@mail.gmail.com> <48A465CC.8000402@isi.edu> <396556a20808141023s3abddc96u43b9e6e7898033ed@mail.gmail.com> <48A46BD3.4030408@isi.edu> <396556a20808141303k341599wfeef32d0841e9f76@mail.gmail.com> In-Reply-To: <396556a20808141303k341599wfeef32d0841e9f76@mail.gmail.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adam Langley wrote: | On Thu, Aug 14, 2008 at 10:30 AM, Joe Touch wrote: |> OK. So why bother with an option at that point? Why does the user data |> need to be different if the option is present? |> |> If the user data were not different, then this all boils down to a |> change in the implementation of the API. The trouble is that you're |> expecting a TCP option to change the *content* of the data stream, and |> that seems bizarre to me. | | Because for server-speaks-first application protocols there's no | problem. This is just for client-speaks-first protocols. For these | protocols, had common stacks been able to send data in the SYN/ACK | when they were being designed, then they might have ended up as | server-speaks-first protocols. But they didn't for latency reasons. Client-speaks-first puts data in the SYN, not the SYN-ACK. Or have you got the roles reversed, as with FTP data connections? | In order for them to take advantage of this they need to be able to | signal their compliance somehow. There is, indeed, a cleanliness | argument against such a option, but I'm arguing that it's worthwhile | for backward compatibility reasons. | |> This is a big change - you're saying that if the payload fits, it goes |> in the SYN-ACK. If not, *none* of it is sent in the SYN-ACK? Why? | | I'm saying that implementations have latitude here. If the passive | open end wishes to ignore the client's option it may. Equally, it may | echo it, but not include the data in the SYNACK if the MTU makes it | troublesome. In that case, it needs to send it in the next packet as | normal. If the option is ignored, and you don't intend to change TCP semantics, then the data - i.e., the hash or whatever - needs to be sent in the next data packet. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkikkbgACgkQE5f5cImnZruy5gCfZvj6azlW6J5XITA9qESS0ovN W7wAmwWpXEzT+gMsXWT5PgpnLQsJ6uDx =mqEW -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 14 13:25:36 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 339403A68C2; Thu, 14 Aug 2008 13:25:36 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB7D33A6851 for ; Thu, 14 Aug 2008 13:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.538 X-Spam-Level: X-Spam-Status: No, score=-1.538 tagged_above=-999 required=5 tests=[AWL=0.439, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kEJOVHYN7ccP for ; Thu, 14 Aug 2008 13:25:34 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id E871B3A67F8 for ; Thu, 14 Aug 2008 13:25:33 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so515682rvf.49 for ; Thu, 14 Aug 2008 13:25:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=lJnMjRBsORiXwVaRf5sG7Kte31A4TVEoOXtqW+hN+vo=; b=Orw7LCdFKS0XTnHDpUUx1jFz2/hR6L0lLtjnYtqWUt+V+COqpkEy9GVIbEb6VMHN5p /sDEA+ETZW1xasKK+dLhY+jxpmOCE4dnN46D2Km0dVAkUfFgHrT+kAeMti9wXUIDzp72 HkmwQDa2zaqCVFfxzHdyOq1Mp7jBlyyETDHTo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=bTV3gf+YSYHUbi8wTPnWTA9lkx2nHJV+56P9tUivEFezB5dWAq9dULmpdq93zL61bp WQO2vyr2t5KYBAipF47saFvlfuGrZa5sClbOnt0nIhif1RxY9GG71XBRcSEzQZFio1rp WxdK0y+iHfTvnNqhL+AHsflM4pmAodQ9Xyov4= Received: by 10.141.195.5 with SMTP id x5mr1002142rvp.263.1218745508350; Thu, 14 Aug 2008 13:25:08 -0700 (PDT) Received: by 10.141.37.3 with HTTP; Thu, 14 Aug 2008 13:25:08 -0700 (PDT) Message-ID: <396556a20808141325u1e67c93co595eadeb3341539@mail.gmail.com> Date: Thu, 14 Aug 2008 13:25:08 -0700 From: "Adam Langley" To: "Joe Touch" In-Reply-To: <48A491B9.3000209@isi.edu> MIME-Version: 1.0 Content-Disposition: inline References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <48A383F0.9030601@isi.edu> <396556a20808131827x1ab32b13yaa9358ac1a70c6ed@mail.gmail.com> <48A3C0B3.8050003@isi.edu> <396556a20808140940p63dec2d2ib3332b27da8260ae@mail.gmail.com> <48A465CC.8000402@isi.edu> <396556a20808141023s3abddc96u43b9e6e7898033ed@mail.gmail.com> <48A46BD3.4030408@isi.edu> <396556a20808141303k341599wfeef32d0841e9f76@mail.gmail.com> <48A491B9.3000209@isi.edu> X-Google-Sender-Auth: 4869652acc1cd3fb Cc: tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Thu, Aug 14, 2008 at 1:12 PM, Joe Touch wrote: > Client-speaks-first puts data in the SYN, not the SYN-ACK. Or have you > got the roles reversed, as with FTP data connections? Sorry, I was speaking of the application layer protocol. Commonly, client-speaks-first application protocols are putting data in the final ACK of the 3-way handshake. > If the option is ignored, and you don't intend to change TCP semantics, > then the data - i.e., the hash or whatever - needs to be sent in the > next data packet. Ok, I'm fine with that. But there will always be servers which ignore the option because they don't understand it. In that case, obviously, they can't send it in the next packet. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 14 13:37:45 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DE013A6840; Thu, 14 Aug 2008 13:37:45 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58C463A6840 for ; Thu, 14 Aug 2008 13:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[AWL=0.798, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKbgErfDQEDR for ; Thu, 14 Aug 2008 13:37:43 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 5FEC63A67B7 for ; Thu, 14 Aug 2008 13:37:43 -0700 (PDT) Received: from [192.168.1.46] (pool-71-106-119-240.lsanca.dsl-w.verizon.net [71.106.119.240]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m7EKbUwD020250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Aug 2008 13:37:32 -0700 (PDT) Message-ID: <48A4975D.3070303@isi.edu> Date: Thu, 14 Aug 2008 13:36:45 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Adam Langley References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <48A383F0.9030601@isi.edu> <396556a20808131827x1ab32b13yaa9358ac1a70c6ed@mail.gmail.com> <48A3C0B3.8050003@isi.edu> <396556a20808140940p63dec2d2ib3332b27da8260ae@mail.gmail.com> <48A465CC.8000402@isi.edu> <396556a20808141023s3abddc96u43b9e6e7898033ed@mail.gmail.com> <48A46BD3.4030408@isi.edu> <396556a20808141303k341599wfeef32d0841e9f76@mail.gmail.com> <48A491B9.3000209@isi.edu> <396556a20808141325u1e67c93co595eadeb3341539@mail.gmail.com> In-Reply-To: <396556a20808141325u1e67c93co595eadeb3341539@mail.gmail.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adam Langley wrote: | On Thu, Aug 14, 2008 at 1:12 PM, Joe Touch wrote: |> Client-speaks-first puts data in the SYN, not the SYN-ACK. Or have you |> got the roles reversed, as with FTP data connections? | | Sorry, I was speaking of the application layer protocol. Commonly, | client-speaks-first application protocols are putting data in the | final ACK of the 3-way handshake. | |> If the option is ignored, and you don't intend to change TCP semantics, |> then the data - i.e., the hash or whatever - needs to be sent in the |> next data packet. | | Ok, I'm fine with that. But there will always be servers which ignore | the option because they don't understand it. In that case, obviously, | they can't send it in the next packet. Please walk through this again. AFAIK, "client" refers to the initiator of the first connection. Let's use that convention here: client sets socket option before connect server sets socket option after listen, before accept? (again, this is a problem; the socket of the connection exists only after the accept returns; before that, the 'socket' applies to *any* connection that would return a subsequent listen call) 1. SYN-> 2. <- SYN/ACK 3. ACK-> 4. data-> 5. <- data The option you're talking is useful, AFAICT, only in #2 (the SYN/ACK). I'm proposing that the data that the server sends in the socket option be considered equivalent to a WRITE on the socket - which would otherwise have been possible only after the ACCEPT call. I.e.: - if the SYN (#1) has the option, then the socket option data commences in the SYN/ACK (#2) [it could spill over into later data segments #5 (or even between steps 3 and 4)] - if the SYN (#1) lacks the option, then the socket option data commences in the data segments #5 (or between steps 3 and 4) At that point, there is no real need for an option. The server can ALWAYS send the data in the SYN/ACK, and just resend it if the ACK (#3) is just for the SYN (in the SYN/ACK #2). Isn't it a *lot* simpler to avoid an option and just send the data anyway? Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkikl10ACgkQE5f5cImnZrtgKgCgkhBNp2K7PsklAYLRKhv2ljJN t3EAn1Ehv8SJTJc4QN6AHGwRZJQEpvWN =/GhB -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 14 13:41:54 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E47083A67DF; Thu, 14 Aug 2008 13:41:54 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AEC33A67DF for ; Thu, 14 Aug 2008 13:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03gY0Y8A6xPS for ; Thu, 14 Aug 2008 13:41:53 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by core3.amsl.com (Postfix) with ESMTP id 7AC013A67B7 for ; Thu, 14 Aug 2008 13:41:53 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so405913yxg.49 for ; Thu, 14 Aug 2008 13:41:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=C08tE1GbRx1HEXw6HvnsVryCrf1hdU96Q0jVuysIf8k=; b=WxEYrUzNcivxaJlNpwwj1xk4IAKKc6PtrL3d16Wv+Sko18KMoJtjanYxHmiBjSa9+H HDIxyYqsF6OHd+OVlKotKOHca+Cz0hzz38tPbGwc7Z2yo9JquGKyvYN6oJ5hPeyCFznY ekahkotk62EGTjDpJOHWOifJlnPX8Q5IWB9wA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=w0nnTE8i54Dr24YHngwt4G3O1HXiEIzATLnI3QdZMjWTIBdHSrBC4WmH2tS6cWQB2/ qtUGWkHzKHp+x4H8/NSB9NM8tFmWNjz5/IfkbhW1vv7hAEmG6n+W5Gbl7uf++d01/2F9 6Ke9aJToY8hMZMLLpWowmT4L2cavtYMjP4x68= Received: by 10.140.172.21 with SMTP id u21mr1011689rve.262.1218746480430; Thu, 14 Aug 2008 13:41:20 -0700 (PDT) Received: by 10.141.37.3 with HTTP; Thu, 14 Aug 2008 13:41:20 -0700 (PDT) Message-ID: <396556a20808141341p5cb6f6b6m59c95094517a142f@mail.gmail.com> Date: Thu, 14 Aug 2008 13:41:20 -0700 From: "Adam Langley" To: "Caitlin Bestler" In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD77040E3F07@nekter> MIME-Version: 1.0 Content-Disposition: inline References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <000001c8fbfe$0dba0960$292e1c20$@pt> <396556a20808111617n622aceabn62db0d55b25ae712@mail.gmail.com> <000301c8fc81$8e02d470$aa087d50$@pt> <396556a20808120914k6d087534o5c34dfd51dd7d1c5@mail.gmail.com> <000b01c8fc9f$4d9f3c20$e8ddb460$@pt> <396556a20808121155h4e3c551aqcf5260d551bcdd4a@mail.gmail.com> <78C9135A3D2ECE4B8162EBDCE82CAD77040E3E2E@nekter> <396556a20808141014m459e07ebh667aaee60e355ac9@mail.gmail.com> <78C9135A3D2ECE4B8162EBDCE82CAD77040E3F07@nekter> X-Google-Sender-Auth: c2aa76549094ffac Cc: tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Thu, Aug 14, 2008 at 10:44 AM, Caitlin Bestler wrote: > And experience has taught me that when something looks really > bad from a "purely theoretical" viewpoint it merely means that > I have not yet identified the specific case where it *will* > cause problems. So at the minimum I like to come up with > a strong reason why something is intrinsically safe, not > just "So far, I haven't thought of how it goes wrong." I haven't been able to think of any case where it goes horribly wrong yet ;) So, we're considering the case where there are no options in play. This is a pure implementation trick. To make it concrete, we have an SMTP server which puts "220 example.com ESMTP\r\n" in the SYN/ACK. If the client ACKs less than the full payload, we retransmit the remaining bytes in the next packet. That's not a strong reason, but I'll ponder how it could go wrong again tonight. If you think of anything, please do say. Cheers AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 14 14:01:03 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9B8B3A68BD; Thu, 14 Aug 2008 14:01:03 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 759133A68EB for ; Thu, 14 Aug 2008 14:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.429 X-Spam-Level: X-Spam-Status: No, score=0.429 tagged_above=-999 required=5 tests=[AWL=-1.582, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_STOCK2=3.988] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XizEQSWUqm6C for ; Thu, 14 Aug 2008 14:01:01 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by core3.amsl.com (Postfix) with ESMTP id 627253A68A0 for ; Thu, 14 Aug 2008 14:01:01 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so528067rvf.49 for ; Thu, 14 Aug 2008 14:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=m01m94hv5WB1YuwPcHS/tY90xvPiN35kiBQW4KM/sPA=; b=VEciHx0SCNwaHmHLoRpEK84Yv9j52Wvv6B/yXjO7obl9KCvt6eyGb0pU4AIB9zWb/m uAeUICkmCAtunRovl6eRlqP+CQnSFl2lWThFYzoYpEyEUH2UgFh7Y6pUHKc2gwaRSMVE /9pDYXrAHdF7r+xKZLfT29Cig6L+2HHNBcD44= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=KpiVNieNVPgpnzDAC6B/XKTSR9NqWQhqeR6xXZ13XmjhL3oy/Py81hYfm3fR08MmbB 88WUVqxC0lavf86gTuvN0Ux6vTQ2Dg5DDml41qnv+RNgdSOhfVNIl8XIu9ka8nL3m/uj U+WUDLGG4Pz+XSbbmSyfUOlNw5zmxEID1o5y8= Received: by 10.141.137.6 with SMTP id p6mr1018582rvn.279.1218747665287; Thu, 14 Aug 2008 14:01:05 -0700 (PDT) Received: by 10.141.37.3 with HTTP; Thu, 14 Aug 2008 14:01:05 -0700 (PDT) Message-ID: <396556a20808141401of8ad149w5850e8dc552a9948@mail.gmail.com> Date: Thu, 14 Aug 2008 14:01:05 -0700 From: "Adam Langley" To: "Joe Touch" In-Reply-To: <48A4975D.3070303@isi.edu> MIME-Version: 1.0 Content-Disposition: inline References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <48A3C0B3.8050003@isi.edu> <396556a20808140940p63dec2d2ib3332b27da8260ae@mail.gmail.com> <48A465CC.8000402@isi.edu> <396556a20808141023s3abddc96u43b9e6e7898033ed@mail.gmail.com> <48A46BD3.4030408@isi.edu> <396556a20808141303k341599wfeef32d0841e9f76@mail.gmail.com> <48A491B9.3000209@isi.edu> <396556a20808141325u1e67c93co595eadeb3341539@mail.gmail.com> <48A4975D.3070303@isi.edu> X-Google-Sender-Auth: 390a47e1123c65c7 Cc: tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Thu, Aug 14, 2008 at 1:36 PM, Joe Touch wrote: > Isn't it a *lot* simpler to avoid an option and just send the data anyway? Yep! And I intend to patch Linux to support exactly this (no options involved anywhere) at some point. To reuse an example, I could have an SMTP server which writes "200 example.com ESMTP\r\n" this way and save a round trip. (Although SMTP isn't too latency sensitive some busy servers might be glad of it.) But many application level protocols have been designed as client-speaks-first, like HTTP. So, let's define HTTP-ssf (server speaks first). HTTP-ssf is exactly the same as HTTP, except that the client waits for a banner from the HTTP server before sending a banner of it's own. We can use the same trick as the SMTP server to maybe fit this banner in the SYNACK. If it doesn't fit, no loss, it can go in later packets. If the client doesn't ACK all the data from the SYNACK, no loss, again it goes in the next packets. Now, I can run an HTTP-ssf server, but no web browser on the planet can talk to me! And the browsers that I modify to speak HTTP-ssf can't take to any non-ssf HTTP servers. It's a very lonely website. I could define a whole new URL scheme (httpssf://...) and a new port. But then there's no gradual deployment path because users with old browsers don't understand httpssf:// and it confuses the users anyway. Most type http:// by habit. My HTTP-ssf server happens to be an embedded device and it handles the TCP processing directly. So, I have browsers that understand HTTP-ssf set an option in the SYN packet. If I see this option, I start talking HTTP-ssf, otherwise I stick with HTTP. When I start talking HTTP-ssf, I echo the option to let the client know which protocol is in effect. Now HTTP-ssf can be deployed gradually. In order to run HTTP-ssf servers on non-embedded machines I define a couple of (get|set)sockopt's to set and query the option so I know what protocol to speak. I also want to include the banner in the SYNACK for latency reasons, so I include another setsockopt to set a constant banner that's prepended to the beginning of the server's outgoing data stream. However, the kernel needs to know only to prepend this banner if the client include the option, so I add that ability too. Now my server gets SYN flooded and, to mitigate the problem, it doesn't want to send large SYNACKs out, even when the client has requested them. It can send minimal SYNACKs and put the banner in later packets. However, user's hate it when their websites slow down so, rather than do that, the kernel can also ignore the requests and fall back to HTTP. (Sorry, I don't mean to be condescending in the slightest! I just got carried away with the personification there. However, I don't think the clarity suffered for it, so I'm going to stick with it. I hope you don't mind) AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 14 14:27:18 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD0533A67EF; Thu, 14 Aug 2008 14:27:18 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF5A03A67EF for ; Thu, 14 Aug 2008 14:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[AWL=0.665, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVJAqmRgdqwe for ; Thu, 14 Aug 2008 14:27:16 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id C06493A67E7 for ; Thu, 14 Aug 2008 14:27:16 -0700 (PDT) Received: from [192.168.1.46] (pool-71-106-119-240.lsanca.dsl-w.verizon.net [71.106.119.240]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m7ELQalR006788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Aug 2008 14:26:40 -0700 (PDT) Message-ID: <48A4A2DE.3090400@isi.edu> Date: Thu, 14 Aug 2008 14:25:50 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Adam Langley References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <48A3C0B3.8050003@isi.edu> <396556a20808140940p63dec2d2ib3332b27da8260ae@mail.gmail.com> <48A465CC.8000402@isi.edu> <396556a20808141023s3abddc96u43b9e6e7898033ed@mail.gmail.com> <48A46BD3.4030408@isi.edu> <396556a20808141303k341599wfeef32d0841e9f76@mail.gmail.com> <48A491B9.3000209@isi.edu> <396556a20808141325u1e67c93co595eadeb3341539@mail.gmail.com> <48A4975D.3070303@isi.edu> <396556a20808141401of8ad149w5850e8dc552a9948@mail.gmail.com> In-Reply-To: <396556a20808141401of8ad149w5850e8dc552a9948@mail.gmail.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adam Langley wrote: | On Thu, Aug 14, 2008 at 1:36 PM, Joe Touch wrote: |> Isn't it a *lot* simpler to avoid an option and just send the data anyway? | | Yep! And I intend to patch Linux to support exactly this (no options | involved anywhere) at some point. To reuse an example, I could have an | SMTP server which writes "200 example.com ESMTP\r\n" this way and save | a round trip. (Although SMTP isn't too latency sensitive some busy | servers might be glad of it.) | | But many application level protocols have been designed as | client-speaks-first, like HTTP. OK, so the crux of the matter is that: - most app protocols are client-speaks first - you want server-speaks-first There's nothing about TCP that prevents that, but I agree that the current socket interface isn't quite sufficient. | So, let's define HTTP-ssf (server | speaks first). HTTP-ssf is exactly the same as HTTP, except that the | client waits for a banner from the HTTP server before sending a banner | of it's own. We can use the same trick as the SMTP server to maybe fit | this banner in the SYNACK. If it doesn't fit, no loss, it can go in | later packets. If the client doesn't ACK all the data from the SYNACK, | no loss, again it goes in the next packets. Yup. That works. | Now, I can run an HTTP-ssf server, but no web browser on the planet | can talk to me! And the browsers that I modify to speak HTTP-ssf can't | take to any non-ssf HTTP servers. It's a very lonely website. YES. You have a problem because you're redefining HTTP, not because of anything in TCP. FWIW, there's an HTTPbis WG in which this issue would be relevant. | I could define a whole new URL scheme (httpssf://...) and a new port. | But then there's no gradual deployment path because users with old | browsers don't understand httpssf:// and it confuses the users anyway. | Most type http:// by habit. So let's consider secure HTTP. That could have been done with a TCP option, but instead it was done in exactly the way you don't think works - - a new port, and a new URI prefix (https:). Initially, users needed to know what to type; eventually, that ended up being embedded in URLs on web pages people click anyway (e.g., search engine results). OK, so why doesn't that path suffice? It worked once, why won't it work again? - ---- What you're *really* asking for is a way to send data from client to server BEFORE the TWHS completes. You talk about server-talks-first, but it's really the client speaking - by sending the option. If this were a flag in the HTTP request, and if the data were available to the server app when the SYN arrives, you'd be done. You're using the option as a trick to get around the fact that TCP doesn't want to send user data up to the app until the end of the TWHS. I don't think that sort of channel is something TCP needs. IMO, this is precisely what T/TCP was designed for; T/TCP may need fixing, but that's a different issue. I'm not familiar enough with SCTP to know if that's an alternate path. I don't support the idea that doing this in TCP is appropriate just to get around deployment issues. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkikot4ACgkQE5f5cImnZrvyWACgtAlcCP3R5UijYW+IpRc2x3VX Rw0AoPiUJhbWhD2cWKliTRFrhtINfYai =pX3/ -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 14 14:43:23 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F2BA3A6A5A; Thu, 14 Aug 2008 14:43:23 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FB883A68F4 for ; Thu, 14 Aug 2008 14:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.98 X-Spam-Level: X-Spam-Status: No, score=-0.98 tagged_above=-999 required=5 tests=[AWL=0.997, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6ASJswBHOxk for ; Thu, 14 Aug 2008 14:43:19 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by core3.amsl.com (Postfix) with ESMTP id B93343A684C for ; Thu, 14 Aug 2008 14:43:19 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id x19so521135pyg.24 for ; Thu, 14 Aug 2008 14:43:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=HxVLniJvEVi5P/aQlDFVmJm9gXrSMzZOI+VySgywfxs=; b=CKWhgPc9MIwgoLXVX8oKpRBAHI50aDs9STga02zWqUcXyajevFHIg8andsJeDEXhHw V/Zo5PxGyCVkP53SlRBFSlAI8SEHNbKkupx3tjec2OVP3quC9gQMkDwURA4o7v7fKY5G +kyNMVlcJrP2+m3Gxzc90yECCaDTddtcyWm94= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=kYmk6PTKHOw6DvRoOxOKYvMbyRxm5mBoq9gpTBaCl/zZ8vtuliVarWTzvwEZBFb6zS FCUNpNI+6IKD1Fei0xorAjdwb5sSUeifzzLI/bsmTW82GSuOdd27H5ba81xulndRfz0x sPtqUZbP7YtZSNGkrS9lsKguRZchuasLGJXTM= Received: by 10.140.135.19 with SMTP id i19mr1046391rvd.169.1218750183711; Thu, 14 Aug 2008 14:43:03 -0700 (PDT) Received: by 10.141.37.3 with HTTP; Thu, 14 Aug 2008 14:43:03 -0700 (PDT) Message-ID: <396556a20808141443y4524c5b7y35b5ce707db3b628@mail.gmail.com> Date: Thu, 14 Aug 2008 14:43:03 -0700 From: "Adam Langley" To: "Joe Touch" In-Reply-To: <48A4A2DE.3090400@isi.edu> MIME-Version: 1.0 Content-Disposition: inline References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <48A465CC.8000402@isi.edu> <396556a20808141023s3abddc96u43b9e6e7898033ed@mail.gmail.com> <48A46BD3.4030408@isi.edu> <396556a20808141303k341599wfeef32d0841e9f76@mail.gmail.com> <48A491B9.3000209@isi.edu> <396556a20808141325u1e67c93co595eadeb3341539@mail.gmail.com> <48A4975D.3070303@isi.edu> <396556a20808141401of8ad149w5850e8dc552a9948@mail.gmail.com> <48A4A2DE.3090400@isi.edu> X-Google-Sender-Auth: 3df826af29fe241e Cc: tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Thu, Aug 14, 2008 at 2:25 PM, Joe Touch wrote: > So let's consider secure HTTP. That could have been done with a TCP > option, but instead it was done in exactly the way you don't think works > - - a new port, and a new URI prefix (https:). Initially, users needed to > know what to type; eventually, that ended up being embedded in URLs on > web pages people click anyway (e.g., search engine results). HTTPS was slightly different because it had to be resistant to downgrade attacks - it couldn't have been done as an option for that reason. However, I'd cite HTTPS as an example that new uri schemes don't work. Despite widespread support, far too few people use it. There are other user interaction problems with TLS (and all other secure protocols) to be sure (user's will click past invalid certificate warnings etc), but having to know what "https" is certainly one of them. (One's mother is the canonical example here, but you can confirm this by asking random, non-technical people) > What you're *really* asking for is a way to send data from client to > server BEFORE the TWHS completes. You talk about server-talks-first, but > it's really the client speaking - by sending the option. Hmm, yea. That's a fair view of matters. I'm sending a single bit from the client in the SYN. > I don't support the idea that doing this in TCP is appropriate just to > get around deployment issues. Ok. You've certainly understood the issues, so that's reasonable. If others feel the same way I shall withdrawl the options request and figure out another path. Thanks for all your time, Joe. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 14 15:04:39 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F6F13A6857; Thu, 14 Aug 2008 15:04:39 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 588183A6918 for ; Thu, 14 Aug 2008 15:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.038 X-Spam-Level: ** X-Spam-Status: No, score=2.038 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHH7DrwxcfO3 for ; Thu, 14 Aug 2008 15:04:37 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 4F50F3A6857 for ; Thu, 14 Aug 2008 15:04:35 -0700 (PDT) Received: from [192.168.1.15] (p508FE40C.dip.t-dialin.net [80.143.228.12]) by mail-n.franken.de (Postfix) with ESMTP id 3DE5B1C0C0BC0; Fri, 15 Aug 2008 00:04:36 +0200 (CEST) Message-Id: <6FEDDE45-C396-4A97-A510-0FD236229197@lurchi.franken.de> From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: Joe Touch In-Reply-To: <48A4A2DE.3090400@isi.edu> Mime-Version: 1.0 (Apple Message framework v926) Date: Fri, 15 Aug 2008 00:04:35 +0200 References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <48A3C0B3.8050003@isi.edu> <396556a20808140940p63dec2d2ib3332b27da8260ae@mail.gmail.com> <48A465CC.8000402@isi.edu> <396556a20808141023s3abddc96u43b9e6e7898033ed@mail.gmail.com> <48A46BD3.4030408@isi.edu> <396556a20808141303k341599wfeef32d0841e9f76@mail.gmail.com> <48A491B9.3000209@isi.edu> <396556a20808141325u1e67c93co595eadeb3341539@mail.gmail.com> <48A4975D.3070303@isi.edu> <396556a20808141401of8ad149w5850e8dc552a9948@mail.gmail.com> <48A4A2DE.3090400@isi.edu> X-Mailer: Apple Mail (2.926) Cc: Adam Langley , tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Aug 14, 2008, at 11:25 PM, Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Adam Langley wrote: > | On Thu, Aug 14, 2008 at 1:36 PM, Joe Touch wrote: > |> Isn't it a *lot* simpler to avoid an option and just send the data > anyway? > | > | Yep! And I intend to patch Linux to support exactly this (no options > | involved anywhere) at some point. To reuse an example, I could > have an > | SMTP server which writes "200 example.com ESMTP\r\n" this way and > save > | a round trip. (Although SMTP isn't too latency sensitive some busy > | servers might be glad of it.) > | > | But many application level protocols have been designed as > | client-speaks-first, like HTTP. > > OK, so the crux of the matter is that: > > - most app protocols are client-speaks first > - you want server-speaks-first > > There's nothing about TCP that prevents that, but I agree that the > current socket interface isn't quite sufficient. > > | So, let's define HTTP-ssf (server > | speaks first). HTTP-ssf is exactly the same as HTTP, except that the > | client waits for a banner from the HTTP server before sending a > banner > | of it's own. We can use the same trick as the SMTP server to maybe > fit > | this banner in the SYNACK. If it doesn't fit, no loss, it can go in > | later packets. If the client doesn't ACK all the data from the > SYNACK, > | no loss, again it goes in the next packets. > > Yup. That works. > > | Now, I can run an HTTP-ssf server, but no web browser on the planet > | can talk to me! And the browsers that I modify to speak HTTP-ssf > can't > | take to any non-ssf HTTP servers. It's a very lonely website. > > YES. You have a problem because you're redefining HTTP, not because of > anything in TCP. FWIW, there's an HTTPbis WG in which this issue would > be relevant. > > | I could define a whole new URL scheme (httpssf://...) and a new > port. > | But then there's no gradual deployment path because users with old > | browsers don't understand httpssf:// and it confuses the users > anyway. > | Most type http:// by habit. > > So let's consider secure HTTP. That could have been done with a TCP > option, but instead it was done in exactly the way you don't think > works > - - a new port, and a new URI prefix (https:). Initially, users > needed to > know what to type; eventually, that ended up being embedded in URLs on > web pages people click anyway (e.g., search engine results). > > OK, so why doesn't that path suffice? It worked once, why won't it > work > again? > > - ---- > > What you're *really* asking for is a way to send data from client to > server BEFORE the TWHS completes. You talk about server-talks-first, > but > it's really the client speaking - by sending the option. If this > were a > flag in the HTTP request, and if the data were available to the server > app when the SYN arrives, you'd be done. You're using the option as a > trick to get around the fact that TCP doesn't want to send user data > up > to the app until the end of the TWHS. > > I don't think that sort of channel is something TCP needs. IMO, this > is > precisely what T/TCP was designed for; T/TCP may need fixing, but > that's > a different issue. I'm not familiar enough with SCTP to know if that's > an alternate path. SCTP has a four way handshake: ---- INIT ----> <-- INIT-ACK -- --- COOKIE ---> <- COOKIE-ACK - You can send user data with the third and fourth message, not with the first or second. The socket API supports sending user data on the third message... > > > I don't support the idea that doing this in TCP is appropriate just to > get around deployment issues. > > Joe > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkikot4ACgkQE5f5cImnZrvyWACgtAlcCP3R5UijYW+IpRc2x3VX > Rw0AoPiUJhbWhD2cWKliTRFrhtINfYai > =pX3/ > -----END PGP SIGNATURE----- > _______________________________________________ > 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 From tcpm-bounces@ietf.org Thu Aug 14 15:44:02 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A68AD3A6A7B; Thu, 14 Aug 2008 15:44:02 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A55B3A6A70 for ; Thu, 14 Aug 2008 15:44:00 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIRlW053e+h1 for ; Thu, 14 Aug 2008 15:43:59 -0700 (PDT) Received: from owa.neterion.com (mx.neterion.com [72.1.205.142]) by core3.amsl.com (Postfix) with ESMTP id 68D7F3A67B7 for ; Thu, 14 Aug 2008 15:43:59 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 14 Aug 2008 18:44:11 -0400 Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD770417B23A@nekter> In-Reply-To: <396556a20808141401of8ad149w5850e8dc552a9948@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] SYN/ACK Payloads, draft 01 Thread-Index: Acj+UOLTGcutM0Q+Q4KaoL09zOHnpwAC+vBg References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com><48A3C0B3.8050003@isi.edu><396556a20808140940p63dec2d2ib3332b27da8260ae@mail.gmail.com><48A465CC.8000402@isi.edu><396556a20808141023s3abddc96u43b9e6e7898033ed@mail.gmail.com><48A46BD3.4030408@isi.edu><396556a20808141303k341599wfeef32d0841e9f76@mail.gmail.com><48A491B9.3000209@isi.edu><396556a20808141325u1e67c93co595eadeb3341539@mail.gmail.com><48A4975D.3070303@isi.edu> <396556a20808141401of8ad149w5850e8dc552a9948@mail.gmail.com> From: "Caitlin Bestler" To: "Adam Langley" , "Joe Touch" Cc: tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Adam Langley wrote: > > But many application level protocols have been designed as > client-speaks-first, like HTTP. So, let's define HTTP-ssf (server > speaks first). HTTP-ssf is exactly the same as HTTP, except that the > client waits for a banner from the HTTP server before sending a banner > of it's own. We can use the same trick as the SMTP server to maybe fit > this banner in the SYNACK. If it doesn't fit, no loss, it can go in > later packets. If the client doesn't ACK all the data from the SYNACK, > no loss, again it goes in the next packets. > > Now, I can run an HTTP-ssf server, but no web browser on the planet > can talk to me! And the browsers that I modify to speak HTTP-ssf can't > take to any non-ssf HTTP servers. It's a very lonely website. > > I could define a whole new URL scheme (httpssf://...) and a new port. > But then there's no gradual deployment path because users with old > browsers don't understand httpssf:// and it confuses the users anyway. > Most type http:// by habit. > > My HTTP-ssf server happens to be an embedded device and it handles the > TCP processing directly. So, I have browsers that understand HTTP-ssf > set an option in the SYN packet. If I see this option, I start talking > HTTP-ssf, otherwise I stick with HTTP. When I start talking HTTP-ssf, > I echo the option to let the client know which protocol is in effect. > Now HTTP-ssf can be deployed gradually. This is an excellent summary of the core problem. It also summarizes why SCTP is not the solution. An httpsctp protocol would be far superior to an httpssf protocol, but it would be just as lonely. So to translate your application level problem into transport layer terms, you want to subdivide the class TCP payload stream into a finite-sized "banner" that is at the start of the stream and is followed by the traditional byte stream payload. Further, you want to establish both bannerless and banner-enabled connections using the same server-side listen. That is: - When a banner-unaware client attempts to connect to a banner-capable server, everything will work. The server will know that the client did not provide a banner, and the client will never see a banner that it does not know what to do with. - When a banner-aware client attempts to connect to a banner-unaware server, everything will work because the client does not send a banner until it has seen the server's TCP options. The client will be told that the connection was accepted by a banner-unaware server, and the server will think it has a traditional client. - When a banner-aware client attempts to connect to a banner-capable server they will actually exchange banners, and the banner payloads will be delivered to the client and server applications in a manner that is separate from the normal payload. The rationale for doing this in TCP is that the total application infrastructure cannot steer banner-aware clients to an alternate port due to the class chicken-and-egg problem. If only 1% of clients understand banner-enabled HTTP then no sites will be encoded to use the special URL indicating banner capability. Since no sites use the banner indicating URL there is no reason for new clients to add that capability. So there *is* rationale for doing this at the transport layer. Whether there is *sufficient* rationale is subject to debate. My key reservation remains that this breaks a fundamental concept of TCP. Instead of the TCP payload being "a stream of bytes" it is now "an optional banner message sent only when the peer's TCP options indicate it can be parsed followed by a stream of bytes". I've never been a fan of the "stream of bytes" model (I far prefer the SCTP "stream of messages" model), but it is very simple and it is what TCP is. I'm not sure the improvements cited here are reaching a threshold sufficient to justify the required extra conceptual complexity. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 14 16:35:45 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F5DA3A6962; Thu, 14 Aug 2008 16:35:45 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C1323A6918 for ; Thu, 14 Aug 2008 16:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.472 X-Spam-Level: X-Spam-Status: No, score=-1.472 tagged_above=-999 required=5 tests=[AWL=0.505, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFBT4YkmMaf2 for ; Thu, 14 Aug 2008 16:35:43 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by core3.amsl.com (Postfix) with ESMTP id 63F1D3A68BF for ; Thu, 14 Aug 2008 16:35:43 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so579881rvf.49 for ; Thu, 14 Aug 2008 16:35:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=+ZdmdeFlbsk08SuG7P6+CPBjf9woqep0j6z4DJC1ZDs=; b=rP7b61AbdqtlCCz4ElBKaK5ToCODV4ThuMu6euujJOwoVJdpn/ysnicis9mZb2Tltu VUYL2TSxL9LyawB9eVDAHVamax9MRzP4QJ6sCk6ovmuanvnfj7WFsHEO9ESrGdtoPxYt lVxhldWv3MVYYvPTJewLhCrwPFa2uHk/Ig2u4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=nOnRIJ3DRyxns3kJ74hEFp8YWWw/102dhld9SHm9uk3bzi7o1boZCLm64G+iN2i343 z6WIc447+0ANALA9Uzqv4pUyHS9P4mvqYlYEFjHfOZka5uhXtTr//GqkdsVPxOYsTKBo n+h0nvjj/2scaoV4mqLGUdE4CymfMr6p9R+Ns= Received: by 10.140.133.9 with SMTP id g9mr1097967rvd.235.1218756947145; Thu, 14 Aug 2008 16:35:47 -0700 (PDT) Received: by 10.141.37.3 with HTTP; Thu, 14 Aug 2008 16:35:47 -0700 (PDT) Message-ID: <396556a20808141635s43981c99g301065585f22127c@mail.gmail.com> Date: Thu, 14 Aug 2008 16:35:47 -0700 From: "Adam Langley" To: "Caitlin Bestler" In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD770417B23A@nekter> MIME-Version: 1.0 Content-Disposition: inline References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <48A465CC.8000402@isi.edu> <396556a20808141023s3abddc96u43b9e6e7898033ed@mail.gmail.com> <48A46BD3.4030408@isi.edu> <396556a20808141303k341599wfeef32d0841e9f76@mail.gmail.com> <48A491B9.3000209@isi.edu> <396556a20808141325u1e67c93co595eadeb3341539@mail.gmail.com> <48A4975D.3070303@isi.edu> <396556a20808141401of8ad149w5850e8dc552a9948@mail.gmail.com> <78C9135A3D2ECE4B8162EBDCE82CAD770417B23A@nekter> X-Google-Sender-Auth: 61ee17a3b4be86db Cc: tcpm@ietf.org, Joe Touch Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Thu, Aug 14, 2008 at 3:44 PM, Caitlin Bestler wrote: > So there *is* rationale for doing this at the transport layer. Whether > there is *sufficient* rationale is subject to debate. My key reservation > remains that this breaks a fundamental concept of TCP. Instead of the > TCP payload being "a stream of bytes" it is now "an optional banner > message sent only when the peer's TCP options indicate it can be > parsed followed by a stream of bytes". Just to correct one point - the banners are still seen as part of the stream of bytes by both ends. The option communicates a single bit, out of band, to both ends. I think that's the problem. So it looks like the concenous for this is pretty thin. (Un)fortunately, I'm persistant as hell, so I shall consider what other avenues I have. I still firmly believe that a world with opportunistic encryption would be a better world than we have now. Cheers all, AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 14 19:03:44 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ECED3A6A79; Thu, 14 Aug 2008 19:03:44 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 508003A69FE for ; Thu, 14 Aug 2008 19:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.263 X-Spam-Level: X-Spam-Status: No, score=-0.263 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMTffY3wv9gy for ; Thu, 14 Aug 2008 19:03:41 -0700 (PDT) Received: from kilo.rtfm.com (unknown [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 93A2C3A69C4 for ; Thu, 14 Aug 2008 19:03:41 -0700 (PDT) Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 46406539CB0; Thu, 14 Aug 2008 19:03:46 -0700 (PDT) Date: Thu, 14 Aug 2008 19:03:45 -0700 From: Eric Rescorla To: "Adam Langley" In-Reply-To: <396556a20808141635s43981c99g301065585f22127c@mail.gmail.com> References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <48A465CC.8000402@isi.edu> <396556a20808141023s3abddc96u43b9e6e7898033ed@mail.gmail.com> <48A46BD3.4030408@isi.edu> <396556a20808141303k341599wfeef32d0841e9f76@mail.gmail.com> <48A491B9.3000209@isi.edu> <396556a20808141325u1e67c93co595eadeb3341539@mail.gmail.com> <48A4975D.3070303@isi.edu> <396556a20808141401of8ad149w5850e8dc552a9948@mail.gmail.com> <78C9135A3D2ECE4B8162EBDCE82CAD770417B23A@nekter> <396556a20808141635s43981c99g301065585f22127c@mail.gmail.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080815020346.46406539CB0@kilo.rtfm.com> Cc: tcpm@ietf.org, Caitlin Bestler , Joe Touch Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At Thu, 14 Aug 2008 16:35:47 -0700, Adam Langley wrote: > > On Thu, Aug 14, 2008 at 3:44 PM, Caitlin Bestler > wrote: > > So there *is* rationale for doing this at the transport layer. Whether > > there is *sufficient* rationale is subject to debate. My key reservation > > remains that this breaks a fundamental concept of TCP. Instead of the > > TCP payload being "a stream of bytes" it is now "an optional banner > > message sent only when the peer's TCP options indicate it can be > > parsed followed by a stream of bytes". > > Just to correct one point - the banners are still seen as part of the > stream of bytes by both ends. The option communicates a single bit, > out of band, to both ends. I think that's the problem. > > So it looks like the concenous for this is pretty thin. > > (Un)fortunately, I'm persistant as hell, so I shall consider what > other avenues I have. I still firmly believe that a world with > opportunistic encryption would be a better world than we have now. I believe this too. But there are lots of ways to get opportunistic encryption that don't involve screwing with TCP. For starters, there could simply be a header that said "You can use TLS to talk to me as well" and supporting clients could redirect. The rationale for this mechanism is opportunistic encryption PLUS lower latency than currently offered by TLS. It's the second piece you haven't made the case for. -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Aug 15 00:14:34 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C9593A67D2; Fri, 15 Aug 2008 00:14:34 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFA5E3A6819 for ; Fri, 15 Aug 2008 00:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.038 X-Spam-Level: ** X-Spam-Status: No, score=2.038 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQbOv9yHV+Vl for ; Fri, 15 Aug 2008 00:14:33 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 70F9B3A6403 for ; Fri, 15 Aug 2008 00:14:32 -0700 (PDT) Received: from [192.168.1.15] (p508FD8D4.dip.t-dialin.net [80.143.216.212]) by mail-n.franken.de (Postfix) with ESMTP id 847231C0C0BCE; Fri, 15 Aug 2008 09:14:32 +0200 (CEST) Message-Id: <9AA6852B-C938-41A3-BFE0-0D150E9EB4AB@lurchi.franken.de> From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: Eric Rescorla In-Reply-To: <20080815020346.46406539CB0@kilo.rtfm.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Fri, 15 Aug 2008 09:14:31 +0200 References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <48A465CC.8000402@isi.edu> <396556a20808141023s3abddc96u43b9e6e7898033ed@mail.gmail.com> <48A46BD3.4030408@isi.edu> <396556a20808141303k341599wfeef32d0841e9f76@mail.gmail.com> <48A491B9.3000209@isi.edu> <396556a20808141325u1e67c93co595eadeb3341539@mail.gmail.com> <48A4975D.3070303@isi.edu> <396556a20808141401of8ad149w5850e8dc552a9948@mail.gmail.com> <78C9135A3D2ECE4B8162EBDCE82CAD770417B23A@nekter> <396556a20808141635s43981c99g301065585f22127c@mail.gmail.com> <20080815020346.46406539CB0@kilo.rtfm.com> X-Mailer: Apple Mail (2.926) Cc: Adam Langley , tcpm@ietf.org, Caitlin Bestler , Joe Touch Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Aug 15, 2008, at 4:03 AM, Eric Rescorla wrote: > At Thu, 14 Aug 2008 16:35:47 -0700, > Adam Langley wrote: >> >> On Thu, Aug 14, 2008 at 3:44 PM, Caitlin Bestler >> wrote: >>> So there *is* rationale for doing this at the transport layer. >>> Whether >>> there is *sufficient* rationale is subject to debate. My key >>> reservation >>> remains that this breaks a fundamental concept of TCP. Instead of >>> the >>> TCP payload being "a stream of bytes" it is now "an optional banner >>> message sent only when the peer's TCP options indicate it can be >>> parsed followed by a stream of bytes". >> >> Just to correct one point - the banners are still seen as part of the >> stream of bytes by both ends. The option communicates a single bit, >> out of band, to both ends. I think that's the problem. >> >> So it looks like the concenous for this is pretty thin. >> >> (Un)fortunately, I'm persistant as hell, so I shall consider what >> other avenues I have. I still firmly believe that a world with >> opportunistic encryption would be a better world than we have now. > > I believe this too. But there are lots of ways to get opportunistic > encryption that don't involve screwing with TCP. For starters, > there could simply be a header that said "You can use TLS to > talk to me as well" and supporting clients could redirect. In SCTP, RFC 5061, there is a features called 'Adaptation Layer Indication', which could be used to signal this kind of information during the handshake... > > The rationale for this mechanism is opportunistic encryption PLUS > lower latency than currently offered by TLS. It's the second > piece you haven't made the case for. > > -Ekr > > > _______________________________________________ > 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 From tcpm-bounces@ietf.org Fri Aug 15 07:57:47 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B32573A6B4F; Fri, 15 Aug 2008 07:57:47 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F0433A6AA6 for ; Fri, 15 Aug 2008 07:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[AWL=0.477, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUye33kuOmkG for ; Fri, 15 Aug 2008 07:57:45 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id 2C69C3A67A8 for ; Fri, 15 Aug 2008 07:57:45 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so855843rvf.49 for ; Fri, 15 Aug 2008 07:57:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=w7qwZtnBlQs2/jaCa5EDFBxGSjbNyQEkveROzH/Mh2Q=; b=Em71x5dxt3G0txgOlCgDdmf2l3XJId3x8JiL9MRx90aX4RXvHxivF30SqWaYuZNqn/ w2etaFNbaqT5Q+hfxUDAiSaLjX7TvvZzFCeqG0FnrngAUeIjgTTlEK2zUYDnAuyT9NHL gZr7fzAw9R0yu/bVv0weg3+oh07B2YLCV+ml0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=g6art/veOOt62NTDcyszodWDZjQ+Vo4P0m19N98TYIc4UTP1+mIZJZTgaRmlp3uyvG BjXlwo0BPKGoqfjKmtHU+p5bKkk7SeHhAx2uPSlfdsLO6Q9ZjytTc6mEBxa4Igl3VhFu m7haTpNT1a37irRKVnqJeZgG0/UsZBNAavaSI= Received: by 10.141.212.5 with SMTP id o5mr1539330rvq.20.1218812269306; Fri, 15 Aug 2008 07:57:49 -0700 (PDT) Received: by 10.141.37.3 with HTTP; Fri, 15 Aug 2008 07:57:49 -0700 (PDT) Message-ID: <396556a20808150757n576ebcd7ie12f44034cc26321@mail.gmail.com> Date: Fri, 15 Aug 2008 07:57:49 -0700 From: "Adam Langley" To: "Anders Waldenborg" In-Reply-To: <48A563F1.8060607@0x63.nu> MIME-Version: 1.0 Content-Disposition: inline References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <000301c8fc81$8e02d470$aa087d50$@pt> <396556a20808120914k6d087534o5c34dfd51dd7d1c5@mail.gmail.com> <000b01c8fc9f$4d9f3c20$e8ddb460$@pt> <396556a20808121155h4e3c551aqcf5260d551bcdd4a@mail.gmail.com> <78C9135A3D2ECE4B8162EBDCE82CAD77040E3E2E@nekter> <396556a20808141014m459e07ebh667aaee60e355ac9@mail.gmail.com> <78C9135A3D2ECE4B8162EBDCE82CAD77040E3F07@nekter> <396556a20808141341p5cb6f6b6m59c95094517a142f@mail.gmail.com> <48A563F1.8060607@0x63.nu> X-Google-Sender-Auth: 749beef23130e7c5 Cc: tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Fri, Aug 15, 2008 at 4:09 AM, Anders Waldenborg wrote: > Doesn't SA payloads open up for DoS-amplification (attacker would send SYN > packets to your SMTP server with spoofed source address to send more data to > victim then would be possible by sending them directly to victim)? It's certainly a consideration, which is why the draft recommended that 64 bytes be the maximum payload size. At this size there are more juicy targets for amplification, like DNS servers. Cheers AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Aug 15 09:09:03 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BE493A6ABD; Fri, 15 Aug 2008 09:09:03 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D785B3A6B34 for ; Fri, 15 Aug 2008 09:09:01 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71z-0uI099PU for ; Fri, 15 Aug 2008 09:09:01 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id EF3023A687E for ; Fri, 15 Aug 2008 09:09:00 -0700 (PDT) Received: from [75.211.28.114] (114.sub-75-211-28.myvzw.com [75.211.28.114]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m7FG8IID020790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 15 Aug 2008 09:08:20 -0700 (PDT) Message-ID: <48A5A9C5.5000806@isi.edu> Date: Fri, 15 Aug 2008 09:07:33 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Adam Langley References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <48A465CC.8000402@isi.edu> <396556a20808141023s3abddc96u43b9e6e7898033ed@mail.gmail.com> <48A46BD3.4030408@isi.edu> <396556a20808141303k341599wfeef32d0841e9f76@mail.gmail.com> <48A491B9.3000209@isi.edu> <396556a20808141325u1e67c93co595eadeb3341539@mail.gmail.com> <48A4975D.3070303@isi.edu> <396556a20808141401of8ad149w5850e8dc552a9948@mail.gmail.com> <48A4A2DE.3090400@isi.edu> <396556a20808141443y4524c5b7y35b5ce707db3b628@mail.gmail.com> In-Reply-To: <396556a20808141443y4524c5b7y35b5ce707db3b628@mail.gmail.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adam Langley wrote: ... | Thanks for all your time, Joe. And thanks to you (and others on the list) for taking the time to explain this in detail. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkilqcUACgkQE5f5cImnZrvyHQCg+MS2i9H/VcnhN2sHPgYE+wUz y8QAn16srbzr1U7tOqfMe0/S/DzsZa71 =VQ+X -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Aug 15 09:35:57 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBC6428C24A; Fri, 15 Aug 2008 09:35:57 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1375928C249 for ; Fri, 15 Aug 2008 09:35:57 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfYfo50d6hHe for ; Fri, 15 Aug 2008 09:35:56 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 3074F28B797 for ; Fri, 15 Aug 2008 09:35:56 -0700 (PDT) Received: from [75.211.28.114] (114.sub-75-211-28.myvzw.com [75.211.28.114]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m7FGYxpr000437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 15 Aug 2008 09:35:02 -0700 (PDT) Message-ID: <48A5B003.5070408@isi.edu> Date: Fri, 15 Aug 2008 09:34:11 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Adam Langley References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <000301c8fc81$8e02d470$aa087d50$@pt> <396556a20808120914k6d087534o5c34dfd51dd7d1c5@mail.gmail.com> <000b01c8fc9f$4d9f3c20$e8ddb460$@pt> <396556a20808121155h4e3c551aqcf5260d551bcdd4a@mail.gmail.com> <78C9135A3D2ECE4B8162EBDCE82CAD77040E3E2E@nekter> <396556a20808141014m459e07ebh667aaee60e355ac9@mail.gmail.com> <78C9135A3D2ECE4B8162EBDCE82CAD77040E3F07@nekter> <396556a20808141341p5cb6f6b6m59c95094517a142f@mail.gmail.com> <48A563F1.8060607@0x63.nu> <396556a20808150757n576ebcd7ie12f44034cc26321@mail.gmail.com> In-Reply-To: <396556a20808150757n576ebcd7ie12f44034cc26321@mail.gmail.com> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Anders Waldenborg Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adam Langley wrote: > On Fri, Aug 15, 2008 at 4:09 AM, Anders Waldenborg wrote: >> Doesn't SA payloads open up for DoS-amplification (attacker would send SYN >> packets to your SMTP server with spoofed source address to send more data to >> victim then would be possible by sending them directly to victim)? > > It's certainly a consideration, which is why the draft recommended > that 64 bytes be the maximum payload size. At this size there are more > juicy targets for amplification, like DNS servers. FWIW, since this is payload data, the size of the data is an implementation detail - unless, as I've noted, you're changing the semantics of TCP from a byte stream to delineated messages. (yes, you're already changing the semantics from one where connection info is available only after TWHS to one that allows info to be used by the app before the TWHS completes, which is a different issue) Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkilsAMACgkQE5f5cImnZrukEgCgmJ8EMS2Ok5wrxzMl9IpziV9w tGgAnj2Lc1kNceJVbamjJvUMnP21TRzH =G70K -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Aug 15 09:57:17 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F5FD3A68F9; Fri, 15 Aug 2008 09:57:17 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C5173A68F9 for ; Fri, 15 Aug 2008 09:57:15 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-q5Ut8Wa-pH for ; Fri, 15 Aug 2008 09:57:14 -0700 (PDT) Received: from owa.neterion.com (mx.neterion.com [72.1.205.142]) by core3.amsl.com (Postfix) with ESMTP id 47F333A687A for ; Fri, 15 Aug 2008 09:56:57 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Aug 2008 12:56:24 -0400 Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD770417B3EE@nekter> In-Reply-To: <48A5B003.5070408@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] SYN/ACK Payloads, draft 01 Thread-Index: Acj+9QP9J4CFMrl7RZG3KJwordCtbAAAme4A References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <000301c8fc81$8e02d470$aa087d50$@pt> <396556a20808120914k6d087534o5c34dfd51dd7d1c5@mail.gmail.com> <000b01c8fc9f$4d9f3c20$e8ddb460$@pt> <396556a20808121155h4e3c551aqcf5260d551bcdd4a@mail.gmail.com> <78C9135A3D2ECE4B8162EBDCE82CAD77040E3E2E@nekter> <396556a20808141014m459e07ebh667aaee60e355ac9@mail.gmail.com> <78C9135A3D2ECE4B8162EBDCE82CAD77040E3F07@nekter> <396556a20808141341p5cb6f6b6m59c95094517a142f@mail.gmail.com> <48A563F1.8060607@0x63.nu><396556a20808150757n576ebcd7ie12f44034cc26321@mail.gmail.com> <48A5B003.5070408@isi.edu> From: "Caitlin Bestler" To: "Joe Touch" , "Adam Langley" Cc: tcpm@ietf.org, Anders Waldenborg Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Joe Touch wrote: > > > > > It's certainly a consideration, which is why the draft recommended > > that 64 bytes be the maximum payload size. At this size there are > more > > juicy targets for amplification, like DNS servers. > > FWIW, since this is payload data, the size of the data is an > implementation detail - unless, as I've noted, you're changing the > semantics of TCP from a byte stream to delineated messages. > > (yes, you're already changing the semantics from one where connection > info is available only after TWHS to one that allows info to be used by > the app before the TWHS completes, which is a different issue) > If this were to move forward, the Security Considerations would need to document the amplification attack, and probably have SHOULD language about a default maximum packet size. But this is probably not something that the TCP stack should enforce. There are many situations where the system administrator would have valid reasons for knowing that a DoS was already blocked by other means. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Aug 15 10:09:25 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3781628C1AB; Fri, 15 Aug 2008 10:09:25 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F22C53A6879 for ; Fri, 15 Aug 2008 10:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.525 X-Spam-Level: X-Spam-Status: No, score=-1.525 tagged_above=-999 required=5 tests=[AWL=0.452, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHWO8K6BuRw2 for ; Fri, 15 Aug 2008 10:09:23 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by core3.amsl.com (Postfix) with ESMTP id 0B6323A6768 for ; Fri, 15 Aug 2008 10:09:22 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so899664rvf.49 for ; Fri, 15 Aug 2008 10:09:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=zgLSde9FuLVklkZC/BTX3NvtQokv+HWaTsMc7D9G8Sk=; b=N4R/2Qt8bwMUquXsQYpTxmhSrUXzhRQuiUDmuG4M+9wuM4eXduhWrQ6n5XF82RHCJU JFM4O7hI5wSC5zsxlTbr5iR1vUjOVDKJRyEnA6Ei/WHeMEfS2byuJpPOFRxRC9hgqQB/ FThz1ZJ0/n9hKHq20LhFO2S6aDVg6Ut/QgZ9U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=I4O7Eg9mVAKOQVO4Pe1m7anzeIe7xA24INBVrCF7GyGHAb9lvc5lw2XB+m11sXj/2U +deOjQJeCfUxwJwlKl0AT9z3w8caMYibW4uhvOJsr2JMpIYh11S9Ub1Eg25nqQxtPyfG VkpGqorIIR/qec8rQOfEgEs8PPCsjAQtUl5eo= Received: by 10.140.164.6 with SMTP id m6mr1647228rve.208.1218820167262; Fri, 15 Aug 2008 10:09:27 -0700 (PDT) Received: by 10.141.37.3 with HTTP; Fri, 15 Aug 2008 10:09:27 -0700 (PDT) Message-ID: <396556a20808151009g2e830590ic1b47afbb19084ef@mail.gmail.com> Date: Fri, 15 Aug 2008 10:09:27 -0700 From: "Adam Langley" To: "Caitlin Bestler" In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD770417B3EE@nekter> MIME-Version: 1.0 Content-Disposition: inline References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <396556a20808121155h4e3c551aqcf5260d551bcdd4a@mail.gmail.com> <78C9135A3D2ECE4B8162EBDCE82CAD77040E3E2E@nekter> <396556a20808141014m459e07ebh667aaee60e355ac9@mail.gmail.com> <78C9135A3D2ECE4B8162EBDCE82CAD77040E3F07@nekter> <396556a20808141341p5cb6f6b6m59c95094517a142f@mail.gmail.com> <48A563F1.8060607@0x63.nu> <396556a20808150757n576ebcd7ie12f44034cc26321@mail.gmail.com> <48A5B003.5070408@isi.edu> <78C9135A3D2ECE4B8162EBDCE82CAD770417B3EE@nekter> X-Google-Sender-Auth: a9bc568f36e6746c Cc: tcpm@ietf.org, Joe Touch Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Fri, Aug 15, 2008 at 9:56 AM, Caitlin Bestler wrote: > If this were to move forward, the Security Considerations would need > to document the amplification attack, and probably have SHOULD language > about a default maximum packet size. The 01 draft says this in the security considerations: " Any payload in a SYNACK packet must be as frugal as possible since a host will be transmitting it to an unconfirmed address. If a 40 byte frame could elicit a 1500 byte reply to an attacker controlled address, this would be readily used to hide and amplify distributed denial of service attacks." > But this is probably not something that the TCP stack should enforce. > There are many situations where the system administrator would have > valid reasons for knowing that a DoS was already blocked by other means. You're correct here, the current MUST should be downgraded to a SHOULD. Implementations can make the best decision here. As for it moving forward, I don't feel that I would ever get consensus for the current design. (Although I don't really know how these things work, I believe that's required.) I shall ponder other means this weekend, but a quick discussion amongst those who (ab)use TCP stacks for our internal networks didn't come up with anything. Cheers AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 21 10:42:07 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 135F23A69D9; Thu, 21 Aug 2008 10:42:07 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F1473A688D for ; Thu, 21 Aug 2008 10:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghqIsWffZrIi for ; Thu, 21 Aug 2008 10:41:41 -0700 (PDT) Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id 01B9A3A695D for ; Thu, 21 Aug 2008 10:41:31 -0700 (PDT) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id m7LHekKL012474; Thu, 21 Aug 2008 10:40:46 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Aug 2008 10:40:46 -0700 Received: from [172.25.34.27] ([172.25.34.27]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Aug 2008 10:40:46 -0700 Message-Id: <24D2F5D3-93E7-4B64-BA96-2086F3E5754E@windriver.com> From: David Borman To: tcpm@ietf.org In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Date: Thu, 21 Aug 2008 12:40:43 -0500 References: X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 21 Aug 2008 17:40:46.0279 (UTC) FILETIME=[0AD9F570:01C903B5] Cc: rrs@cisco.com, mdalal@cisco.com, "Anantha Ramaiah \(ananth\)" Subject: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Wes and I would like to start the WG Last Call for: Title : Improving TCP's Robustness to Blind In-Window Attacks' Author(s) : A. Ramaiah, R. Stewart & M. Dalal Filename : draft-ietf-tcpm-tcpsecure-10.txt Pages : 27 Date : July 9, 2008 Intended Status : Proposed Standard http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-10.txt It is our understanding that all the feedback has been incorporated into this latest version and that there are no known outstanding issues with this document. Please send feedback to the list, even if it is just a "yes, go ahead and publish". The WGLC will end on Friday, September 5, 2009. David Borman & Wes Eddy, TCPM WG co-chairs _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 21 14:09:03 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4269A28C164; Thu, 21 Aug 2008 14:09:03 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38D4A3A6A57 for ; Thu, 21 Aug 2008 14:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jctqfodAn+SC for ; Thu, 21 Aug 2008 14:04:04 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 0C07C3A698B for ; Thu, 21 Aug 2008 14:04:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,247,1217808000"; d="scan'208";a="20516872" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 21 Aug 2008 21:03:42 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m7LL3gGX022576; Thu, 21 Aug 2008 14:03:42 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m7LL3g1o006012; Thu, 21 Aug 2008 21:03:42 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Aug 2008 14:03:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 21 Aug 2008 14:02:28 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5805AA26E1@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <48A383F0.9030601@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] SYN/ACK Payloads, draft 01 Thread-Index: Acj9qX/tARC5pKH6TVeTAHuBp5T/kQGIoGGQ References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <20080813172752.AA7A650846@romeo.rtfm.com> <396556a20808131047q781675a3if23d727ef5ae918f@mail.gmail.com> <20080813181630.A1E6750848@romeo.rtfm.com> <396556a20808131145y1be0fb4saeb7bbf74d078268@mail.gmail.com> <20080813195027.C4C5B50848@romeo.rtfm.com> <396556a20808131307r65a9f6a0oe4365be029620b2c@mail.gmail.com> <48A35CFA.4060709@isi.edu> <396556a20808131525i20dabf06w7a7a11e3468e541a@mail.gmail.com> <48A36104.6000000@isi.edu><396556a20808131605w2ccac3ceo21160401e4545c15@mail.gmail.com> <48A383F0.9030601@isi.edu> From: "Anantha Ramaiah (ananth)" To: "Joe Touch" , "Adam Langley" X-OriginalArrivalTime: 21 Aug 2008 21:03:42.0053 (UTC) FILETIME=[642DA150:01C903D1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1460; t=1219352622; x=1220216622; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20 |Subject:=20RE=3A=20[tcpm]=20SYN/ACK=20Payloads,=20draft=20 01 |Sender:=20; bh=I4wil+4XagxPYDrr6YEnmkFA3+/iecCPfaFrQiVn7P0=; b=OJp9+c3pPer2E6NpFNy/GOEQeu9jc3RefzcPTgPvOZJ8ZBYB22Wt6+ds31 SAnUk6+k3HjvnVp3uRI//Arz8p0O6lsJ2AVXx0TRC+bmo2QpsJFCfcMOuSbn CViY2mZ8bf; Authentication-Results: sj-dkim-4; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org > | > | int newsocket = accept(...) > | getsockopt(newsocket, SOL_TCP, &tcpsa, ...) if (TCP_SADATA_REQ & > | tcpsa.tcpsa_flags) { > | // The first data from the socket is the client's > draft-agl handshake > | decode_tagged_data(newsocket); > | ... > | } else { > | // No special case, > | continue_as_normal(); > | } > > I'm wondering why an implementation in user space would > expect to find out anything about a TCP connection that > hadn't finished handshaking, i.e., the accept call above This has been done in some stacks today (like ours). The incoming SYN is reported to the application and the application can suggest whether or not to accept the connection. If the application gives a nod, proceed with the 3 way handshake else send an RST. This is different from a 3 way handshake happening (which involves the TCB and the associated baggage creation) and then informing the application and applications can reject this connection during accept(). Applications wishing to use this special property would set a socket option indicating the notification of SYN when the listener is created. The advantage is that you don't allocate the memory ahead of time if the application isn't interested in accepting this connection. Other ways of handling this is to have the application program the access control list in TCP or below, so that an early discard can be made. -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 21 17:05:55 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DAAC3A6BD1; Thu, 21 Aug 2008 17:05:55 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA29028C143 for ; Thu, 21 Aug 2008 17:03:28 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8JKfBbLvd53 for ; Thu, 21 Aug 2008 17:03:27 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id C99233A69E3 for ; Thu, 21 Aug 2008 17:03:27 -0700 (PDT) Received: from [70.193.90.230] (230.sub-70-193-90.myvzw.com [70.193.90.230]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m7M02QHZ029051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Aug 2008 17:02:29 -0700 (PDT) Message-ID: <48AE01DB.1020303@isi.edu> Date: Thu, 21 Aug 2008 17:01:31 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <20080813172752.AA7A650846@romeo.rtfm.com> <396556a20808131047q781675a3if23d727ef5ae918f@mail.gmail.com> <20080813181630.A1E6750848@romeo.rtfm.com> <396556a20808131145y1be0fb4saeb7bbf74d078268@mail.gmail.com> <20080813195027.C4C5B50848@romeo.rtfm.com> <396556a20808131307r65a9f6a0oe4365be029620b2c@mail.gmail.com> <48A35CFA.4060709@isi.edu> <396556a20808131525i20dabf06w7a7a11e3468e541a@mail.gmail.com> <48A36104.6000000@isi.edu><396556a20808131605w2ccac3ceo21160401e4545c15@mail.gmail.com> <48A383F0.9030601@isi.edu> <0C53DCFB700D144284A584F54711EC5805AA26E1@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC5805AA26E1@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Adam Langley , tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Ananth, Anantha Ramaiah (ananth) wrote: > >> | >> | int newsocket = accept(...) >> | getsockopt(newsocket, SOL_TCP, &tcpsa, ...) if (TCP_SADATA_REQ & >> | tcpsa.tcpsa_flags) { >> | // The first data from the socket is the client's >> draft-agl handshake >> | decode_tagged_data(newsocket); >> | ... >> | } else { >> | // No special case, >> | continue_as_normal(); >> | } >> >> I'm wondering why an implementation in user space would >> expect to find out anything about a TCP connection that >> hadn't finished handshaking, i.e., the accept call above > > This has been done in some stacks today (like ours). The incoming SYN is > reported to the application and the application can suggest whether or > not to accept the connection. If the application gives a nod, proceed > with the 3 way handshake else send an RST. Does the app have access to the SYN options? If so, that seems outside the scope of what TCP should be exposing to the app. > This is different from a 3 > way handshake happening (which involves the TCB and the associated > baggage creation) and then informing the application and applications > can reject this connection during accept(). Applications wishing to use > this special property would set a socket option indicating the > notification of SYN when the listener is created. > > The advantage is that you don't allocate the memory ahead of time if the > application isn't interested in accepting this connection. It seems to me the app already sufficiently controls this in how/when it issues a accept(). On what basis is it making the rejection at the time of a SYN? (if by IP address, it could have done this via a different listen() call). Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiuAdsACgkQE5f5cImnZruSpQCg0vbiE19/XHuJZAs4vICD8PLV swQAoO0gK+GeCcjlJWSOuB8/6gjlneHY =Hnvo -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Aug 22 10:06:50 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D3933A68E6; Fri, 22 Aug 2008 10:06:50 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99C123A6965 for ; Fri, 22 Aug 2008 10:06:48 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yv4+AEH006CZ for ; Fri, 22 Aug 2008 10:06:47 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id ACB733A68E6 for ; Fri, 22 Aug 2008 10:06:47 -0700 (PDT) Received: from [75.217.250.128] (128.sub-75-217-250.myvzw.com [75.217.250.128]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m7MH5T2b026281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Aug 2008 10:05:32 -0700 (PDT) Message-ID: <48AEF1A0.5040609@isi.edu> Date: Fri, 22 Aug 2008 10:04:32 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <20080813172752.AA7A650846@romeo.rtfm.com> <396556a20808131047q781675a3if23d727ef5ae918f@mail.gmail.com> <20080813181630.A1E6750848@romeo.rtfm.com> <396556a20808131145y1be0fb4saeb7bbf74d078268@mail.gmail.com> <20080813195027.C4C5B50848@romeo.rtfm.com> <396556a20808131307r65a9f6a0oe4365be029620b2c@mail.gmail.com> <48A35CFA.4060709@isi.edu> <396556a20808131525i20dabf06w7a7a11e3468e541a@mail.gmail.com> <48A36104.6000000@isi.edu><396556a20808131605w2ccac3ceo21160401e4545c15@mail.gmail.com> <48A383F0.9030601@isi.edu> <0C53DCFB700D144284A584F54711EC5805AA26E1@xmb-sjc-21c.amer.cisco.com> <48AE01DB.1020303@isi.edu> <0C53DCFB700D144284A584F54711EC5805AF79AC@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC5805AF79AC@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Adam Langley , tcpm@ietf.org Subject: Re: [tcpm] SYN/ACK Payloads, draft 01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Ananth, Anantha Ramaiah (ananth) wrote: > > > >>>> I'm wondering why an implementation in user space would expect to >>>> find out anything about a TCP connection that hadn't finished >>>> handshaking, i.e., the accept call above >>> This has been done in some stacks today (like ours). The >> incoming SYN >>> is reported to the application and the application can >> suggest whether >>> or not to accept the connection. If the application gives a nod, >>> proceed with the 3 way handshake else send an RST. >> Does the app have access to the SYN options? If so, that >> seems outside the scope of what TCP should be exposing to the app. > > Ok, currently we don't pass TCP options upwards, we just pass the 4 > tuple (may be 5 tuple if you include VRF's) to the application. The > application can decide whether to move forward with this connection or > not. This is simply the access control at the application level for the > incoming SYN. That's roughly equivalent to having better resolution of listen() calls, which seems OK. (what's a VRF?) >>> This is different from a 3 >>> way handshake happening (which involves the TCB and the associated >>> baggage creation) and then informing the application and >> applications >>> can reject this connection during accept(). Applications wishing to >>> use this special property would set a socket option indicating the >>> notification of SYN when the listener is created. >>> >>> The advantage is that you don't allocate the memory ahead >> of time if >>> the application isn't interested in accepting this connection. >> It seems to me the app already sufficiently controls this in >> how/when it issues a accept(). On what basis is it making the >> rejection at the time of a SYN? (if by IP address, it could >> have done this via a different >> listen() call). > > 4 or (5 tuple) mainly IP adresses and VRF since dest port and src port > aren't of much help.. you could push the access control below, but if > you want to factor in other application factors which could vary from > application to application (like say # of connections etc.,) then it > seems expedient to do the check at the application level. Consider the > case where TCP is library linked to the application and it could > register a callback to be invoked with the 5 tuple and accept/reject the > connection synchronously which is efficient in terms of resource > utilization, i.e, you drop the SYN once it is determined that it is > "useless" rather than waiting the 3 way handshake to complete. At the > least, it comes across as an optmization, but YMMV. These sound like more sophisticated interfaces to the OS, in terms of how deep to listen for calls, what patterns of ports/addrs to listen for, etc. Although they're not implemented in the OS, they could be. The fact that you're implementing them at the app layer isn't a big issue, and can certainly be easier or a performance win, depending on the system. This doesn't sound like the issue I'm concerned about - i.e., using information that circumvents the TWHS. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiu8aAACgkQE5f5cImnZrvBnQCeLXfhXFIEorj3q4an2jNwDt4E b2gAoNfIwAOSFxc8uS0AC5EI7R5FTAaK =+u5G -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Aug 22 14:30:02 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B50EC28C125; Fri, 22 Aug 2008 14:30:02 -0700 (PDT) X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7559328C106; Fri, 22 Aug 2008 14:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080822213001.7559328C106@core3.amsl.com> Date: Fri, 22 Aug 2008 14:30:01 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-ecnsyn-06.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets Author(s) : S. Floyd, I. Property Filename : draft-ietf-tcpm-ecnsyn-06.txt Pages : 29 Date : 2008-08-22 This draft specifies a modification to RFC 3168 to allow TCP SYN/ACK packets to be ECN-Capable. For TCP, RFC 3168 only specifies setting an ECN-Capable codepoint on data packets, and not on SYN and SYN/ACK packets. However, because of the high cost to the TCP transfer of having a SYN/ACK packet dropped, with the resulting retransmit timeout, this document specifies the use of ECN for the SYN/ACK packet itself, when sent in response to a SYN packet with the two ECN flags set in the TCP header, indicating a willingness to use ECN. Setting TCP SYN/ACK packets as ECN-Capable can be of great benefit to the TCP connection, avoiding the severe penalty of a retransmit timeout for a connection that has not yet started placing a load on the network. The sender of the SYN/ACK packet must respond to a report of an ECN-marked SYN/ACK packet by reducing its initial congestion window from two, three, or four segments to one segment, thereby reducing the subsequent load from that connection on the network. This document updates RFC 3168. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-ecnsyn-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tcpm-ecnsyn-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-08-22142950.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --NextPart-- From tcpm-bounces@ietf.org Fri Aug 22 21:02:07 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA7EF3A68B4; Fri, 22 Aug 2008 21:02:07 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3008F3A6843 for ; Fri, 22 Aug 2008 21:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.548 X-Spam-Level: X-Spam-Status: No, score=-1.548 tagged_above=-999 required=5 tests=[AWL=0.429, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZQp5QP2NjFV for ; Fri, 22 Aug 2008 21:02:06 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by core3.amsl.com (Postfix) with ESMTP id 5630A3A677C for ; Fri, 22 Aug 2008 21:02:06 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so610424rvf.49 for ; Fri, 22 Aug 2008 21:02:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=YRYAsu4B50oZLZ1JBSZbzlf+Lg36xRf5CaLOMkrhQxU=; b=wkElgaOnJ74A6Npd//jDToaKGI9YOpMIasfYYYJL2khXwy3ifMqllp3ArklOQQIuSC e7Ojl//V700SSDsu5Xt/hmG83g+JrBu6Xo47QD1L/OaWZJOHti64CoiDPl0733x0rMC/ XZY+a9h8NCS3T1f0JkVTT57XdWKyFrboUOqdE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=Ar0rWramBvPEXXBjJrt3kBPRCQLmanarF6Co9lZ/Y1iv3CX3qpcIkdXfJtTULR/ZqI /owEQQiLyDXzBh7+2S2iMOK0Pu6yKl5OFlxsl8lfNuWDNGL87GWhljPJFEy6djsGqjZr 4eSVh0Dwkfe3QXukkEQAXekbogzafgYn5fd+s= Received: by 10.141.66.16 with SMTP id t16mr908192rvk.168.1219464135569; Fri, 22 Aug 2008 21:02:15 -0700 (PDT) Received: by 10.141.37.3 with HTTP; Fri, 22 Aug 2008 21:02:15 -0700 (PDT) Message-ID: <396556a20808222102k7e667443paf89edcd21574366@mail.gmail.com> Date: Fri, 22 Aug 2008 21:02:15 -0700 From: "Adam Langley" To: tcpm@ietf.org In-Reply-To: <20080822213001.7559328C106@core3.amsl.com> MIME-Version: 1.0 Content-Disposition: inline References: <20080822213001.7559328C106@core3.amsl.com> X-Google-Sender-Auth: d73a8a3818b3aa8c Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-ecnsyn-06.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org 2008/8/22 : > Title : Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets > Author(s) : S. Floyd, I. Property > Filename : draft-ietf-tcpm-ecnsyn-06.txt > Pages : 29 > Date : 2008-08-22 "SYN packets that contain known or unknown IP options [MAF05] (Figure 1).)" It appears to be figure 5, at least in the version that Google pulled up. Cheers, -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Aug 23 05:11:40 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A14503A68E4; Sat, 23 Aug 2008 05:11:40 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B41863A67D6 for ; Sat, 23 Aug 2008 05:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CE-92vkXWOuC for ; Sat, 23 Aug 2008 05:11:38 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.104]) by core3.amsl.com (Postfix) with ESMTP id 64D553A6903 for ; Sat, 23 Aug 2008 05:11:37 -0700 (PDT) Received: from mx-av-05.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-06.forthnet.gr (8.14.3/8.14.3) with ESMTP id m7NCBGll028368; Sat, 23 Aug 2008 15:11:16 +0300 Received: from MX-IN-04.forthnet.gr (mx-in-04.forthnet.gr [193.92.150.163]) by mx-av-05.forthnet.gr (8.14.3/8.14.3) with ESMTP id m7NCBFZT021249; Sat, 23 Aug 2008 15:11:16 +0300 Received: from hell.hell.gr (adsl79-179.lsf.forthnet.gr [79.103.206.179]) by MX-IN-04.forthnet.gr (8.14.3/8.14.3) with ESMTP id m7NCBCgv016769; Sat, 23 Aug 2008 15:11:13 +0300 Authentication-Results: MX-IN-04.forthnet.gr smtp.mail=v13@v13.gr; spf=neutral Authentication-Results: MX-IN-04.forthnet.gr header.from=v13@v13.gr; sender-id=neutral From: Stefanos Harhalakis To: Joe Touch Date: Sat, 23 Aug 2008 15:11:09 +0300 User-Agent: KMail/1.9.9 References: <0C53DCFB700D144284A584F54711EC58058C2FD4@xmb-sjc-21c.amer.cisco.com> <200808101507.35830.v13@v13.gr> <489F9A94.9080205@isi.edu> In-Reply-To: <489F9A94.9080205@isi.edu> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808231511.09234.v13@v13.gr> Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] TCP-AO review comments. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Hello again after 12 days, On Monday 11 August 2008, Joe Touch wrote: > | that it supports. Since this isn't possible with limited TCP options > | space and SYN-cookies issues, something different is required > | (versioning). > | > | Do you see another (better) long-term solution? > > Overall, since they keys and parameters need to be configured on a > per-endpoint-pair basis anyway, IMO this sort of handshake ought to > occur in the KMS, not in TCP. TCP's SYN option space is insufficient to > contain multiple authentication fields, AFAICT, in addition to the other > fields currently commonly in use. After rereading the draft and rethinking the conversation, I (finally) agree with you. Indeed everything is as you stated above. Since by definition any handshake will occur out-of-band in KMS, any different behaviour will require another KIND. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Aug 24 11:57:11 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D324F3A6955; Sun, 24 Aug 2008 11:57:11 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC9F43A68F0 for ; Sun, 24 Aug 2008 11:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.437 X-Spam-Level: X-Spam-Status: No, score=0.437 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMHGjKqNJd8U for ; Sun, 24 Aug 2008 11:57:09 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by core3.amsl.com (Postfix) with ESMTP id E01D83A6805 for ; Sun, 24 Aug 2008 11:57:08 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so1112084rvf.49 for ; Sun, 24 Aug 2008 11:56:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=qlUmdaUhdAe+Qi8muPK/THXlaBWWvUyZfmm97EeUn08=; b=nhZs9jVk7LnR1iKYke3Ba9lea6ovTT/5PJSSdTo+xzkJXWqI8kHLMyt10OAsvKqHxd oQkAygZ7kSBP04bZEyelyoI1ftnPiriDM8PWWxAA1ZAcH60v7JkZ4FtFp5pfArxmMo12 1k4n7jPtGP5tYYwSShiivVGFX55/tXK2crdMs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=YDsOHm6/zejGVR8D0E6WxhSa32ttxMUffoJktwj+hgQvDRr+5iBIeNtomwWL0o1OG9 gA0nNZ/78gV2W2CwTqkWXWkDuemPFUC+wsUEIKuaGk1/Fafl0ZWRo3RQb1unp8Klbfuj UPalFXeDkh5RvB97WmvSTBK3IfFe5dAMATvH8= Received: by 10.141.164.13 with SMTP id r13mr1723917rvo.53.1219604183194; Sun, 24 Aug 2008 11:56:23 -0700 (PDT) Received: by 10.141.37.3 with HTTP; Sun, 24 Aug 2008 11:56:23 -0700 (PDT) Message-ID: <396556a20808241156x72a5358fk6bb771f2b7b7c8a7@mail.gmail.com> Date: Sun, 24 Aug 2008 11:56:23 -0700 From: "Adam Langley" To: tcpm@ietf.org In-Reply-To: <20080822213001.7559328C106@core3.amsl.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_62525_14121983.1219604183180" References: <20080822213001.7559328C106@core3.amsl.com> X-Google-Sender-Auth: 5ecb8c60ebcd9c02 Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-ecnsyn-06.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org ------=_Part_62525_14121983.1219604183180 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline 2008/8/22 : > Title : Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets > Author(s) : S. Floyd, I. Property > Filename : draft-ietf-tcpm-ecnsyn-06.txt > Pages : 29 > Date : 2008-08-22 This seems like a very worthwhile change for little cost! Attached is a patch against net-2.6 (Linux development tree) to implement this. I'd be very grateful if someone could review the packet traces and verify the behaviour. All traces are in pcap format. If another format would be more helpful, please ask. For the first two traces, the passive open host sends 8192 bytes to the active side and closes the connection. The active side has a 100ms delay on incoming frames. ecn-synack-ecn.pcap shows the connection with the SYNACK marked. ecn-synack-ce shows the behaviour when the SYNACK is CE marked (with the cwnd reduced to 1 segment etc). The third trace shows an example of not ECN marking retransmitted SYNACKs. Cheers -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org ------=_Part_62525_14121983.1219604183180 Content-Type: application/octet-stream; name=ecn-synack Content-Transfer-Encoding: base64 X-Attachment-Id: f_fka0sgtx0 Content-Disposition: attachment; filename=ecn-synack dGNwOiBFbmFibGUgc2V0dGluZyBFQ04gb24gU1lOL0FDSyBmcmFtZXMKCgotLS0KCiBpbmNsdWRl L25ldC90Y3AuaCAgICAgICAgfCAgICAzICsrLQogbmV0L2lwdjQvdGNwX2lucHV0LmMgICAgIHwg ICAxMCArKysrKysrLS0tCiBuZXQvaXB2NC90Y3BfaXB2NC5jICAgICAgfCAgICA4ICsrKystLS0t CiBuZXQvaXB2NC90Y3BfbWluaXNvY2tzLmMgfCAgICA5ICsrKysrKystLQogbmV0L2lwdjQvdGNw X291dHB1dC5jICAgIHwgICAyNCArKysrKysrKysrKysrKysrKy0tLS0tLS0KIG5ldC9pcHY2L3Rj cF9pcHY2LmMgICAgICB8ICAgMTEgKysrKysrKystLS0KIDYgZmlsZXMgY2hhbmdlZCwgNDUgaW5z ZXJ0aW9ucygrKSwgMjAgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvaW5jbHVkZS9uZXQvdGNw LmggYi9pbmNsdWRlL25ldC90Y3AuaAppbmRleCA4OTgzMzg2Li45N2EwNTRhIDEwMDY0NAotLS0g YS9pbmNsdWRlL25ldC90Y3AuaAorKysgYi9pbmNsdWRlL25ldC90Y3AuaApAQCAtNDI5LDcgKzQy OSw4IEBAIGV4dGVybiBpbnQJCQl0Y3BfY29ubmVjdChzdHJ1Y3Qgc29jayAqc2spOwogCiBleHRl cm4gc3RydWN0IHNrX2J1ZmYgKgkJdGNwX21ha2Vfc3luYWNrKHN0cnVjdCBzb2NrICpzaywKIAkJ CQkJCXN0cnVjdCBkc3RfZW50cnkgKmRzdCwKLQkJCQkJCXN0cnVjdCByZXF1ZXN0X3NvY2sgKnJl cSk7CisJCQkJCQlzdHJ1Y3QgcmVxdWVzdF9zb2NrICpyZXEsCisJCQkJCQljaGFyIGlzX3JldHJh bnNtaXQpOwogCiBleHRlcm4gaW50CQkJdGNwX2Rpc2Nvbm5lY3Qoc3RydWN0IHNvY2sgKnNrLCBp bnQgZmxhZ3MpOwogCmRpZmYgLS1naXQgYS9uZXQvaXB2NC90Y3BfaW5wdXQuYyBiL25ldC9pcHY0 L3RjcF9pbnB1dC5jCmluZGV4IDYzNTE1NmYuLjRkZjIzODIgMTAwNjQ0Ci0tLSBhL25ldC9pcHY0 L3RjcF9pbnB1dC5jCisrKyBiL25ldC9pcHY0L3RjcF9pbnB1dC5jCkBAIC0yMjMsMTAgKzIyMywx NCBAQCBzdGF0aWMgaW5saW5lIHZvaWQgVENQX0VDTl9jaGVja19jZShzdHJ1Y3QgdGNwX3NvY2sg KnRwLCBzdHJ1Y3Qgc2tfYnVmZiAqc2tiKQogCX0KIH0KIAotc3RhdGljIGlubGluZSB2b2lkIFRD UF9FQ05fcmN2X3N5bmFjayhzdHJ1Y3QgdGNwX3NvY2sgKnRwLCBzdHJ1Y3QgdGNwaGRyICp0aCkK K3N0YXRpYyBpbmxpbmUgdm9pZCBUQ1BfRUNOX3Jjdl9zeW5hY2soc3RydWN0IHRjcF9zb2NrICp0 cCwgc3RydWN0IHNrX2J1ZmYgKnNrYikKIHsKLQlpZiAoKHRwLT5lY25fZmxhZ3MgJiBUQ1BfRUNO X09LKSAmJiAoIXRoLT5lY2UgfHwgdGgtPmN3cikpCisJY29uc3Qgc3RydWN0IHRjcGhkciAqdGgg PSB0Y3BfaGRyKHNrYik7CisJaWYgKCh0cC0+ZWNuX2ZsYWdzICYgVENQX0VDTl9PSykgJiYgKCF0 aC0+ZWNlIHx8IHRoLT5jd3IpKSB7CiAJCXRwLT5lY25fZmxhZ3MgJj0gflRDUF9FQ05fT0s7CisJ fSBlbHNlIHsKKwkJVENQX0VDTl9jaGVja19jZSh0cCwgc2tiKTsKKwl9CiB9CiAKIHN0YXRpYyBp bmxpbmUgdm9pZCBUQ1BfRUNOX3Jjdl9zeW4oc3RydWN0IHRjcF9zb2NrICp0cCwgc3RydWN0IHRj cGhkciAqdGgpCkBAIC01MDMwLDcgKzUwMzQsNyBAQCBzdGF0aWMgaW50IHRjcF9yY3Zfc3luc2Vu dF9zdGF0ZV9wcm9jZXNzKHN0cnVjdCBzb2NrICpzaywgc3RydWN0IHNrX2J1ZmYgKnNrYiwKIAkJ ICogICAgc3RhdGUgdG8gRVNUQUJMSVNIRUQuLi4iCiAJCSAqLwogCi0JCVRDUF9FQ05fcmN2X3N5 bmFjayh0cCwgdGgpOworCQlUQ1BfRUNOX3Jjdl9zeW5hY2sodHAsIHNrYik7CiAKIAkJdHAtPnNu ZF93bDEgPSBUQ1BfU0tCX0NCKHNrYiktPnNlcTsKIAkJdGNwX2Fjayhzaywgc2tiLCBGTEFHX1NM T1dQQVRIKTsKZGlmZiAtLWdpdCBhL25ldC9pcHY0L3RjcF9pcHY0LmMgYi9uZXQvaXB2NC90Y3Bf aXB2NC5jCmluZGV4IDQ0YzFlOTMuLmEyZmY2ODAgMTAwNjQ0Ci0tLSBhL25ldC9pcHY0L3RjcF9p cHY0LmMKKysrIGIvbmV0L2lwdjQvdGNwX2lwdjQuYwpAQCAtNzAzLDcgKzcwMyw3IEBAIHN0YXRp YyB2b2lkIHRjcF92NF9yZXFza19zZW5kX2FjayhzdHJ1Y3Qgc29jayAqc2ssIHN0cnVjdCBza19i dWZmICpza2IsCiAgKglzb2NrZXQuCiAgKi8KIHN0YXRpYyBpbnQgX190Y3BfdjRfc2VuZF9zeW5h Y2soc3RydWN0IHNvY2sgKnNrLCBzdHJ1Y3QgcmVxdWVzdF9zb2NrICpyZXEsCi0JCQkJc3RydWN0 IGRzdF9lbnRyeSAqZHN0KQorCQkJCXN0cnVjdCBkc3RfZW50cnkgKmRzdCwgY2hhciBpc19yZXRy YW5zbWl0KQogewogCWNvbnN0IHN0cnVjdCBpbmV0X3JlcXVlc3Rfc29jayAqaXJlcSA9IGluZXRf cnNrKHJlcSk7CiAJaW50IGVyciA9IC0xOwpAQCAtNzEzLDcgKzcxMyw3IEBAIHN0YXRpYyBpbnQg X190Y3BfdjRfc2VuZF9zeW5hY2soc3RydWN0IHNvY2sgKnNrLCBzdHJ1Y3QgcmVxdWVzdF9zb2Nr ICpyZXEsCiAJaWYgKCFkc3QgJiYgKGRzdCA9IGluZXRfY3NrX3JvdXRlX3JlcShzaywgcmVxKSkg PT0gTlVMTCkKIAkJcmV0dXJuIC0xOwogCi0Jc2tiID0gdGNwX21ha2Vfc3luYWNrKHNrLCBkc3Qs IHJlcSk7CisJc2tiID0gdGNwX21ha2Vfc3luYWNrKHNrLCBkc3QsIHJlcSwgaXNfcmV0cmFuc21p dCk7CiAKIAlpZiAoc2tiKSB7CiAJCXN0cnVjdCB0Y3BoZHIgKnRoID0gdGNwX2hkcihza2IpOwpA QCAtNzM2LDcgKzczNiw3IEBAIHN0YXRpYyBpbnQgX190Y3BfdjRfc2VuZF9zeW5hY2soc3RydWN0 IHNvY2sgKnNrLCBzdHJ1Y3QgcmVxdWVzdF9zb2NrICpyZXEsCiAKIHN0YXRpYyBpbnQgdGNwX3Y0 X3NlbmRfc3luYWNrKHN0cnVjdCBzb2NrICpzaywgc3RydWN0IHJlcXVlc3Rfc29jayAqcmVxKQog ewotCXJldHVybiBfX3RjcF92NF9zZW5kX3N5bmFjayhzaywgcmVxLCBOVUxMKTsKKwlyZXR1cm4g X190Y3BfdjRfc2VuZF9zeW5hY2soc2ssIHJlcSwgTlVMTCwgMSk7CiB9CiAKIC8qCkBAIC0xMzAy LDcgKzEzMDIsNyBAQCBpbnQgdGNwX3Y0X2Nvbm5fcmVxdWVzdChzdHJ1Y3Qgc29jayAqc2ssIHN0 cnVjdCBza19idWZmICpza2IpCiAJfQogCXRjcF9yc2socmVxKS0+c250X2lzbiA9IGlzbjsKIAot CWlmIChfX3RjcF92NF9zZW5kX3N5bmFjayhzaywgcmVxLCBkc3QpIHx8IHdhbnRfY29va2llKQor CWlmIChfX3RjcF92NF9zZW5kX3N5bmFjayhzaywgcmVxLCBkc3QsIDApIHx8IHdhbnRfY29va2ll KQogCQlnb3RvIGRyb3BfYW5kX2ZyZWU7CiAKIAlpbmV0X2Nza19yZXFza19xdWV1ZV9oYXNoX2Fk ZChzaywgcmVxLCBUQ1BfVElNRU9VVF9JTklUKTsKZGlmZiAtLWdpdCBhL25ldC9pcHY0L3RjcF9t aW5pc29ja3MuYyBiL25ldC9pcHY0L3RjcF9taW5pc29ja3MuYwppbmRleCBmOTc2ZmM1Li5kYmI3 Nzc0IDEwMDY0NAotLS0gYS9uZXQvaXB2NC90Y3BfbWluaXNvY2tzLmMKKysrIGIvbmV0L2lwdjQv dGNwX21pbmlzb2Nrcy5jCkBAIC00MTUsNyArNDE1LDEzIEBAIHN0cnVjdCBzb2NrICp0Y3BfY3Jl YXRlX29wZW5yZXFfY2hpbGQoc3RydWN0IHNvY2sgKnNrLCBzdHJ1Y3QgcmVxdWVzdF9zb2NrICpy ZXEsCiAJCSAqIGFsZ29yaXRobXMgdGhhdCB3ZSBtdXN0IGhhdmUgdGhlIGZvbGxvd2luZyBiYW5k YWlkIHRvIHRhbGsKIAkJICogZWZmaWNpZW50bHkgdG8gdGhlbS4gIC1EYXZlTQogCQkgKi8KLQkJ bmV3dHAtPnNuZF9jd25kID0gMjsKKwkJVENQX0VDTl9vcGVucmVxX2NoaWxkKG5ld3RwLCByZXEp OworCQlpZiAodW5saWtlbHkodGNwX2hkcihza2IpLT5lY2UpKSB7CisJCQluZXd0cC0+c25kX2N3 bmQgPSAxOworCQkJbmV3dHAtPmVjbl9mbGFncyB8PSBUQ1BfRUNOX1FVRVVFX0NXUjsKKwkJfSBl bHNlIHsKKwkJCW5ld3RwLT5zbmRfY3duZCA9IDI7CisJCX0KIAkJbmV3dHAtPnNuZF9jd25kX2Nu dCA9IDA7CiAJCW5ld3RwLT5ieXRlc19hY2tlZCA9IDA7CiAKQEAgLTQ3OCw3ICs0ODQsNiBAQCBz dHJ1Y3Qgc29jayAqdGNwX2NyZWF0ZV9vcGVucmVxX2NoaWxkKHN0cnVjdCBzb2NrICpzaywgc3Ry dWN0IHJlcXVlc3Rfc29jayAqcmVxLAogCQlpZiAoc2tiLT5sZW4gPj0gVENQX01JTl9SQ1ZNU1Mr bmV3dHAtPnRjcF9oZWFkZXJfbGVuKQogCQkJbmV3aWNzay0+aWNza19hY2subGFzdF9zZWdfc2l6 ZSA9IHNrYi0+bGVuIC0gbmV3dHAtPnRjcF9oZWFkZXJfbGVuOwogCQluZXd0cC0+cnhfb3B0Lm1z c19jbGFtcCA9IHJlcS0+bXNzOwotCQlUQ1BfRUNOX29wZW5yZXFfY2hpbGQobmV3dHAsIHJlcSk7 CiAKIAkJVENQX0lOQ19TVEFUU19CSChzb2NrX25ldChzayksIFRDUF9NSUJfUEFTU0lWRU9QRU5T KTsKIAl9CmRpZmYgLS1naXQgYS9uZXQvaXB2NC90Y3Bfb3V0cHV0LmMgYi9uZXQvaXB2NC90Y3Bf b3V0cHV0LmMKaW5kZXggNzFlZWEwMC4uYmU1ODc2ZSAxMDA2NDQKLS0tIGEvbmV0L2lwdjQvdGNw X291dHB1dC5jCisrKyBiL25ldC9pcHY0L3RjcF9vdXRwdXQuYwpAQCAtMjc2LDExICsyNzYsMTQg QEAgc3RhdGljIHUxNiB0Y3Bfc2VsZWN0X3dpbmRvdyhzdHJ1Y3Qgc29jayAqc2spCiAJcmV0dXJu IG5ld193aW47CiB9CiAKLXN0YXRpYyBpbmxpbmUgdm9pZCBUQ1BfRUNOX3NlbmRfc3luYWNrKHN0 cnVjdCB0Y3Bfc29jayAqdHAsIHN0cnVjdCBza19idWZmICpza2IpCitzdGF0aWMgaW5saW5lIHZv aWQgVENQX0VDTl9zZW5kX3N5bmFjayhzdHJ1Y3Qgc29jayAqc2ssIHN0cnVjdCBza19idWZmICpz a2IpCiB7CiAJVENQX1NLQl9DQihza2IpLT5mbGFncyAmPSB+VENQQ0JfRkxBR19DV1I7Ci0JaWYg KCEodHAtPmVjbl9mbGFncyAmIFRDUF9FQ05fT0spKQorCWlmICghKHRjcF9zayhzayktPmVjbl9m bGFncyAmIFRDUF9FQ05fT0spKSB7CiAJCVRDUF9TS0JfQ0Ioc2tiKS0+ZmxhZ3MgJj0gflRDUENC X0ZMQUdfRUNFOworCX0gZWxzZSB7CisJCUlORVRfRUNOX3htaXQoc2spOworCX0KIH0KIAogc3Rh dGljIGlubGluZSB2b2lkIFRDUF9FQ05fc2VuZF9zeW4oc3RydWN0IHNvY2sgKnNrLCBzdHJ1Y3Qg c2tfYnVmZiAqc2tiKQpAQCAtMjk1LDEwICsyOTgsMTcgQEAgc3RhdGljIGlubGluZSB2b2lkIFRD UF9FQ05fc2VuZF9zeW4oc3RydWN0IHNvY2sgKnNrLCBzdHJ1Y3Qgc2tfYnVmZiAqc2tiKQogfQog CiBzdGF0aWMgX19pbmxpbmVfXyB2b2lkCi1UQ1BfRUNOX21ha2Vfc3luYWNrKHN0cnVjdCByZXF1 ZXN0X3NvY2sgKnJlcSwgc3RydWN0IHRjcGhkciAqdGgpCitUQ1BfRUNOX21ha2Vfc3luYWNrKHN0 cnVjdCBza19idWZmICpza2IsIHN0cnVjdCBzb2NrICpzaywgc3RydWN0IHJlcXVlc3Rfc29jayAq cmVxLAorCQkgICAgc3RydWN0IHRjcGhkciAqdGgsIGNoYXIgaXNfcmV0cmFuc21pdCkKIHsKLQlp ZiAoaW5ldF9yc2socmVxKS0+ZWNuX29rKQorCWlmIChpbmV0X3JzayhyZXEpLT5lY25fb2spIHsK IAkJdGgtPmVjZSA9IDE7CisJCWlmIChsaWtlbHkoIWlzX3JldHJhbnNtaXQpKSB7CisJCQlJTkVU X0VDTl94bWl0KHNrKTsKKwkJfSBlbHNlIHsKKwkJCUlORVRfRUNOX2RvbnR4bWl0KHNrKTsKKwkJ fQorCX0KIH0KIAogc3RhdGljIGlubGluZSB2b2lkIFRDUF9FQ05fc2VuZChzdHJ1Y3Qgc29jayAq c2ssIHN0cnVjdCBza19idWZmICpza2IsCkBAIC0yMjIxLDcgKzIyMzEsNyBAQCBpbnQgdGNwX3Nl bmRfc3luYWNrKHN0cnVjdCBzb2NrICpzaykKIAkJfQogCiAJCVRDUF9TS0JfQ0Ioc2tiKS0+Zmxh Z3MgfD0gVENQQ0JfRkxBR19BQ0s7Ci0JCVRDUF9FQ05fc2VuZF9zeW5hY2sodGNwX3NrKHNrKSwg c2tiKTsKKwkJVENQX0VDTl9zZW5kX3N5bmFjayhzaywgc2tiKTsKIAl9CiAJVENQX1NLQl9DQihz a2IpLT53aGVuID0gdGNwX3RpbWVfc3RhbXA7CiAJcmV0dXJuIHRjcF90cmFuc21pdF9za2Ioc2ss IHNrYiwgMSwgR0ZQX0FUT01JQyk7CkBAIC0yMjMxLDcgKzIyNDEsNyBAQCBpbnQgdGNwX3NlbmRf c3luYWNrKHN0cnVjdCBzb2NrICpzaykKICAqIFByZXBhcmUgYSBTWU4tQUNLLgogICovCiBzdHJ1 Y3Qgc2tfYnVmZiAqdGNwX21ha2Vfc3luYWNrKHN0cnVjdCBzb2NrICpzaywgc3RydWN0IGRzdF9l bnRyeSAqZHN0LAotCQkJCXN0cnVjdCByZXF1ZXN0X3NvY2sgKnJlcSkKKwkJCQlzdHJ1Y3QgcmVx dWVzdF9zb2NrICpyZXEsIGNoYXIgaXNfcmV0cmFuc21pdCkKIHsKIAlzdHJ1Y3QgaW5ldF9yZXF1 ZXN0X3NvY2sgKmlyZXEgPSBpbmV0X3JzayhyZXEpOwogCXN0cnVjdCB0Y3Bfc29jayAqdHAgPSB0 Y3Bfc2soc2spOwpAQCAtMjI3OSw3ICsyMjg5LDcgQEAgc3RydWN0IHNrX2J1ZmYgKnRjcF9tYWtl X3N5bmFjayhzdHJ1Y3Qgc29jayAqc2ssIHN0cnVjdCBkc3RfZW50cnkgKmRzdCwKIAltZW1zZXQo dGgsIDAsIHNpemVvZihzdHJ1Y3QgdGNwaGRyKSk7CiAJdGgtPnN5biA9IDE7CiAJdGgtPmFjayA9 IDE7Ci0JVENQX0VDTl9tYWtlX3N5bmFjayhyZXEsIHRoKTsKKwlUQ1BfRUNOX21ha2Vfc3luYWNr KHNrYiwgc2ssIHJlcSwgdGgsIGlzX3JldHJhbnNtaXQpOwogCXRoLT5zb3VyY2UgPSBpbmV0X3Nr KHNrKS0+c3BvcnQ7CiAJdGgtPmRlc3QgPSBpcmVxLT5ybXRfcG9ydDsKIAkvKiBTZXR0aW5nIG9m IGZsYWdzIGFyZSBzdXBlcmZsdW91cyBoZXJlIGZvciBjYWxsZXJzIChhbmQgRUNFIGlzCmRpZmYg LS1naXQgYS9uZXQvaXB2Ni90Y3BfaXB2Ni5jIGIvbmV0L2lwdjYvdGNwX2lwdjYuYwppbmRleCA1 YjkwYjM2Li4yZGVlNzg3IDEwMDY0NAotLS0gYS9uZXQvaXB2Ni90Y3BfaXB2Ni5jCisrKyBiL25l dC9pcHY2L3RjcF9pcHY2LmMKQEAgLTQ1Nyw3ICs0NTcsOCBAQCBvdXQ6CiB9CiAKIAotc3RhdGlj IGludCB0Y3BfdjZfc2VuZF9zeW5hY2soc3RydWN0IHNvY2sgKnNrLCBzdHJ1Y3QgcmVxdWVzdF9z b2NrICpyZXEpCitzdGF0aWMgaW50IF9fdGNwX3Y2X3NlbmRfc3luYWNrKHN0cnVjdCBzb2NrICpz aywgc3RydWN0IHJlcXVlc3Rfc29jayAqcmVxLAorCQkJCWNoYXIgaXNfcmV0cmFuc21pdCkKIHsK IAlzdHJ1Y3QgaW5ldDZfcmVxdWVzdF9zb2NrICp0cmVxID0gaW5ldDZfcnNrKHJlcSk7CiAJc3Ry dWN0IGlwdjZfcGluZm8gKm5wID0gaW5ldDZfc2soc2spOwpAQCAtNDk0LDcgKzQ5NSw3IEBAIHN0 YXRpYyBpbnQgdGNwX3Y2X3NlbmRfc3luYWNrKHN0cnVjdCBzb2NrICpzaywgc3RydWN0IHJlcXVl c3Rfc29jayAqcmVxKQogCWlmICgoZXJyID0geGZybV9sb29rdXAoJmRzdCwgJmZsLCBzaywgMCkp IDwgMCkKIAkJZ290byBkb25lOwogCi0Jc2tiID0gdGNwX21ha2Vfc3luYWNrKHNrLCBkc3QsIHJl cSk7CisJc2tiID0gdGNwX21ha2Vfc3luYWNrKHNrLCBkc3QsIHJlcSwgaXNfcmV0cmFuc21pdCk7 CiAJaWYgKHNrYikgewogCQlzdHJ1Y3QgdGNwaGRyICp0aCA9IHRjcF9oZHIoc2tiKTsKIApAQCAt NTE0LDYgKzUxNSwxMCBAQCBkb25lOgogCXJldHVybiBlcnI7CiB9CiAKK3N0YXRpYyBpbnQgdGNw X3Y2X3NlbmRfc3luYWNrKHN0cnVjdCBzb2NrICpzaywgc3RydWN0IHJlcXVlc3Rfc29jayAqcmVx KSB7CisJcmV0dXJuIF9fdGNwX3Y2X3NlbmRfc3luYWNrKHNrLCByZXEsIDEpOworfQorCiBzdGF0 aWMgaW5saW5lIHZvaWQgc3luX2Zsb29kX3dhcm5pbmcoc3RydWN0IHNrX2J1ZmYgKnNrYikKIHsK ICNpZmRlZiBDT05GSUdfU1lOX0NPT0tJRVMKQEAgLTEyNjcsNyArMTI3Miw3IEBAIHN0YXRpYyBp bnQgdGNwX3Y2X2Nvbm5fcmVxdWVzdChzdHJ1Y3Qgc29jayAqc2ssIHN0cnVjdCBza19idWZmICpz a2IpCiAKIAlzZWN1cml0eV9pbmV0X2Nvbm5fcmVxdWVzdChzaywgc2tiLCByZXEpOwogCi0JaWYg KHRjcF92Nl9zZW5kX3N5bmFjayhzaywgcmVxKSkKKwlpZiAoX190Y3BfdjZfc2VuZF9zeW5hY2so c2ssIHJlcSwgMCkpCiAJCWdvdG8gZHJvcDsKIAogCWlmICghd2FudF9jb29raWUpIHsK ------=_Part_62525_14121983.1219604183180 Content-Type: application/cap; name=ecn-synack-ecn.pcap Content-Transfer-Encoding: base64 X-Attachment-Id: f_fka0stfx1 Content-Disposition: attachment; filename=ecn-synack-ecn.pcap 1MOyoQIABAAAAAAAAAAAAP//AAABAAAAgoSwSIKYAQBKAAAASgAAAAAWPkRdcQAWPh/JUwgARQAA PNUdQABABu5xwKh6/sCoet3dAQTSUO61awAAAACgwhbQcKUAAAQCCAr//2B2AAAAAAIEBbQBAwMB goSwSNujAQBKAAAASgAAAAAWPh/JUwAWPkRdcQgARQIAPAAAQABABsONwKh63cCoev4E0t0BUjjK 3lDutWygUhag71MAAAQCCAr//2TZ//9gdgIEBbQBAwMBgoSwSK0+AwBCAAAAQgAAAAAWPkRdcQAW Ph/JUwgARQAANNUeQABABu54wKh6/sCoet3dAQTSUO61bFI4yt+AEAtoKV0AAAEBCAr//2Cr//9k 2YKEsEgiXgMA6gUAAOoFAAAAFj4fyVMAFj5EXXEIAEUCBdyuK0AAQAYPwsCoet3AqHr+BNLdAVI4 yt9Q7rVsgBALUNIRAAABAQgK//9k9v//YKt5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CoKEsEhjXgMA 6gUAAOoFAAAAFj4fyVMAFj5EXXEIAEUCBdyuLEAAQAYPwcCoet3AqHr+BNLdAVI40IdQ7rVsgBAL UMxpAAABAQgK//9k9v//YKt5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CoKEsEir/gQAQgAAAEIAAAAA Fj5EXXEAFj4fyVMIAEUAADTVH0AAQAbud8Coev7AqHrd3QEE0lDutWxSONCHgBAREB3TAAABAQgK //9gyP//ZPaChLBIPwAFAOoFAADqBQAAABY+H8lTABY+RF1xCABFAgXcri1AAEAGD8DAqHrdwKh6 /gTS3QFSONYvUO61bIAYC1DGggAAAQEICv//ZRD//2DIeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQqC hLBI0gAFAOoFAADqBQAAABY+H8lTABY+RF1xCABFAgXcri5AAEAGD7/AqHrdwKh6/gTS3QFSONvX UO61bIAQC1DA4QAAAQEICv//ZRH//2DIeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQqChLBI0QIFAEIA AABCAAAAABY+RF1xABY+H8lTCABFAAA01SBAAEAG7nbAqHr+wKh63d0BBNJQ7rVsUjjWL4AQFrgS gwAAAQEICv//YMj//2T2goSwSMEDBQDqBQAA6gUAAAAWPh/JUwAWPkRdcQgARQIF3K4vQABABg++ wKh63cCoev4E0t0BUjjhf1DutWyAEAtQuzkAAAEBCAr//2UR//9gyHkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKgoSwSEUEBQD6AwAA+gMAAAAWPh/JUwAWPkRdcQgARQID7K4wQABABhGtwKh63cCoev4E 0t0BUjjnJ1DutWyAGQtQ+Z0AAAEBCAr//2UR//9gyHkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQqChLBIXZ8GAEIAAABCAAAAABY+RF1xABY+H8lTCABFAAA01SFAAEAG7nXA qHr+wKh63d0BBNJQ7rVsUjjb14AQHGAG/wAAAQEICv//YOL//2UQgoSwSBWnBgBCAAAAQgAAAAAW PkRdcQAWPh/JUwgARQAANNUiQABABu50wKh6/sCoet3dAQTSUO61bFI44X+AECII+60AAAEBCAr/ /2Di//9lEYKEsEi8rwYAQgAAAEIAAAAAFj5EXXEAFj4fyVMIAEUAADTVI0AAQAbuc8Coev7AqHrd 3QEE0lDutWxSOOcngBAnsPBdAAABAQgK//9g4v//ZRGChLBIEsMGAEIAAABCAAAAABY+RF1xABY+ H8lTCABFAAA01SRAAEAG7nLAqHr+wKh63d0BBNJQ7rVsUjjq4IARLVjm+AAAAQEICv//YOX//2UR goSwSB7EBgBCAAAAQgAAAAAWPh/JUwAWPkRdcQgARQAANK4xQABABhVmwKh63cCoev4E0t0BUjjq 4FDutW2AEAtQCOUAAAEBCAr//2Ut//9g5Q== ------=_Part_62525_14121983.1219604183180 Content-Type: application/cap; name=ecn-synack-ce.pcap Content-Transfer-Encoding: base64 X-Attachment-Id: f_fka0t1db2 Content-Disposition: attachment; filename=ecn-synack-ce.pcap 1MOyoQIABAAAAAAAAAAAAP//AAABAAAABIiwSJpTBwBKAAAASgAAAAAWPkRdcQAWPh/JUwgARQAA POZtQABABt0hwKh6/sCoet3dAQTSlc58jgAAAACgwhbQKjUAAAQCCAr//5rjAAAAAAIEBbQBAwMB BIiwSHBeBwBKAAAASgAAAAAWPh/JUwAWPkRdcQgARQMAPAAAQABABsOMwKh63cCoev4E0t0Bl5jE Z5XOfI+gUhagMZkAAAQCCAr//506//+a4wIEBbQBAwMBBIiwSPDwCABCAAAAQgAAAAAWPkRdcQAW Ph/JUwgARQAANOZuQABABt0owKh6/sCoet3dAQTSlc58j5eYxGiAUAtoa2IAAAEBCAr//5sY//+d OgSIsEjlBAkA6gUAAOoFAAAAFj4fyVMAFj5EXXEIAEUCBdxZPEAAQAZkscCoet3AqHr+BNLdAZeY xGiVznyPgJALUBPZAAABAQgK//+dVf//mxh5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CgSIsEjTlgoA QgAAAEIAAAAAFj5EXXEAFj4fyVMIAEUAADTmb0AAQAbdJ8Coev7AqHrd3QEE0pXOfI+XmMoQgBAR EGAcAAABAQgK//+bM///nVUEiLBIeZgKAOoFAADqBQAAABY+H8lTABY+RF1xCABFAgXcWT1AAEAG ZLDAqHrdwKh6/gTS3QGXmMoQlc58j4AQC1AOfAAAAQEICv//nW///5szeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQoEiLBIApkKAOoFAADqBQAAABY+H8lTABY+RF1xCABFAgXcWT5AAEAGZK/AqHrdwKh6 /gTS3QGXmM+4lc58j4AYC1AIzAAAAQEICv//nW///5szeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQoE iLBIASsMAEIAAABCAAAAABY+RF1xABY+H8lTCABFAAA05nBAAEAG3SbAqHr+wKh63d0BBNKVznyP l5jPuIAQFrhUmAAAAQEICv//m03//51vBIiwSLYrDABCAAAAQgAAAAAWPkRdcQAWPh/JUwgARQAA NOZxQABABt0lwKh6/sCoet3dAQTSlc58j5eY1WCAEBxgSUgAAAEBCAr//5tN//+dbwSIsEjELAwA 6gUAAOoFAAAAFj4fyVMAFj5EXXEIAEUCBdxZP0AAQAZkrsCoet3AqHr+BNLdAZeY1WCVznyPgBAL UAL4AAABAQgK//+dif//m015CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CgSIsEhQLQwA6gUAAOoFAAAA Fj4fyVMAFj5EXXEIAEUCBdxZQEAAQAZkrcCoet3AqHr+BNLdAZeY2wiVznyPgBALUP1PAAABAQgK //+dif//m015CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CgSIsEjNLQwA+gMAAPoDAAAAFj4fyVMAFj5E XXEIAEUCA+xZQUAAQAZmnMCoet3AqHr+BNLdAZeY4LCVznyPgBkLUDu0AAABAQgK//+dif//m015 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkK eQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5 CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKeQp5CnkKBIiwSHa/DQBCAAAAQgAAAAAW PkRdcQAWPh/JUwgARQAANOZyQABABt0kwKh6/sCoet3dAQTSlc58j5eY2wiAECIIPcQAAAEBCAr/ /5tn//+diQSIsEg0wA0AQgAAAEIAAAAAFj5EXXEAFj4fyVMIAEUAADTmc0AAQAbdI8Coev7AqHrd 3QEE0pXOfI+XmOCwgBAnsDJ0AAABAQgK//+bZ///nYkEiLBI3soNAEIAAABCAAAAABY+RF1xABY+ H8lTCABFAAA05nRAAEAG3SLAqHr+wKh63d0BBNKVznyPl5jkaYARLVgpEgAAAQEICv//m2f//52J BIiwSFfMDQBCAAAAQgAAAAAWPh/JUwAWPkRdcQgARQAANFlCQABABmpVwKh63cCoev4E0t0Bl5jk aZXOfJCAEAtQSwAAAAEBCAr//52j//+bZw== ------=_Part_62525_14121983.1219604183180 Content-Type: application/cap; name=ecn-synack-backoff.pcap Content-Transfer-Encoding: base64 X-Attachment-Id: f_fka0t7ku3 Content-Disposition: attachment; filename=ecn-synack-backoff.pcap 1MOyoQIABAAAAAAAAAAAAP//AAABAAAAL6yxSGAQDAA2AAAANgAAAAAWPkRdcQD/S85oOwgARQAA KAABAABABjtEAQIDBMCoet0wOQTSAAAAAAAAAABQwiAAGowAAC+ssUgNEgwAOgAAADoAAAAA/0vO aDsAFj5EXXEIAEUCACwAAEAAQAb7PsCoet0BAgMEBNIwObIPsBsAAAABYFIW0KpDAAACBAW0M6yx SOzmAgA6AAAAOgAAAAD/S85oOwAWPkRdcQgARQAALAAAQABABvtAwKh63QECAwQE0jA5sg+wGwAA AAFgUhbQqkMAAAIEBbQ5rLFIpT8JADoAAAA6AAAAAP9Lzmg7ABY+RF1xCABFAAAsAABAAEAG+0DA qHrdAQIDBATSMDmyD7AbAAAAAWBSFtCqQwAAAgQFtA== ------=_Part_62525_14121983.1219604183180 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm ------=_Part_62525_14121983.1219604183180-- From tcpm-bounces@ietf.org Mon Aug 25 12:52:15 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41A523A6989; Mon, 25 Aug 2008 12:52:15 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF4F03A684C for ; Mon, 25 Aug 2008 12:52:13 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZKrVva-FGoL for ; Mon, 25 Aug 2008 12:52:10 -0700 (PDT) Received: from asmtpout017.mac.com (asmtpout017.mac.com [17.148.16.92]) by core3.amsl.com (Postfix) with ESMTP id CC04C3A6803 for ; Mon, 25 Aug 2008 12:52:10 -0700 (PDT) MIME-version: 1.0 Received: from [192.168.1.132] ([70.231.255.183]) by asmtp017.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0K6600FU19TZDW00@asmtp017.mac.com> for tcpm@ietf.org; Mon, 25 Aug 2008 12:51:36 -0700 (PDT) Message-id: From: Sally Floyd To: Adam Langley In-reply-to: <396556a20808222102k7e667443paf89edcd21574366@mail.gmail.com> Date: Mon, 25 Aug 2008 12:51:35 -0700 References: <20080822213001.7559328C106@core3.amsl.com> <396556a20808222102k7e667443paf89edcd21574366@mail.gmail.com> X-Mailer: Apple Mail (2.928.1) Cc: tcpm@ietf.org Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-ecnsyn-06.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Adam - > 2008/8/22 : >> Title : Adding Explicit Congestion Notification >> (ECN) Capability to TCP's SYN/ACK Packets >> Author(s) : S. Floyd, I. Property >> Filename : draft-ietf-tcpm-ecnsyn-06.txt >> Pages : 29 >> Date : 2008-08-22 > > "SYN packets that contain known or unknown IP options [MAF05] > (Figure 1).)" > > It appears to be figure 5, at least in the version that Google > pulled up. I don't know what version Google gave you, but in the version on my web page at "http://www.icir.org/floyd/papers.html#2005", and on the ACM CCR archives, it is indeed Figure 1... - Sally http://www.icir.org/floyd/ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Aug 25 13:00:05 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2622E3A69BF; Mon, 25 Aug 2008 13:00:05 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 771AE3A67B4 for ; Mon, 25 Aug 2008 13:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.77 X-Spam-Level: X-Spam-Status: No, score=-0.77 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ewd3vy87Hp+0 for ; Mon, 25 Aug 2008 13:00:02 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by core3.amsl.com (Postfix) with ESMTP id A4B0B3A69BF for ; Mon, 25 Aug 2008 13:00:02 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so1735732wfd.31 for ; Mon, 25 Aug 2008 12:59:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=ouo1lCI1UujL+pAB6yg6Nfk9CND9hNo+iItYvGH6NC4=; b=knYkvrv5kE+iu4p9BC8doG+jS+r45iwxk9Ah9xruCLd+0qCNb9EXBgRNao9se7Akq5 8C1HXTp5i18oHm+NOhcUfu7N9tUkmAd7RMJZItY1Uj7Af7v2Fimk638EzmRKbsQzjmvI cOo7uym0RS/+InABoW0VlWe5DUlTDINxgJmGs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=ao2dclWSTr0io7Gkscxwy9UXLP97dKhYuGmaFJ4eLV6kVsul1dnizpVZVYooo+GdCF +duZHJELDswMA01VwWuvGqkOOhGACcXroheP8DpF6hINgu7ZuTRjJXlJvfIdygnc8Tss bkfZCV7OwOOUa/ReDwsGuGqVSBn2yAvF0FZXY= Received: by 10.142.53.19 with SMTP id b19mr1673465wfa.167.1219694361469; Mon, 25 Aug 2008 12:59:21 -0700 (PDT) Received: by 10.142.213.20 with HTTP; Mon, 25 Aug 2008 12:59:21 -0700 (PDT) Message-ID: <396556a20808251259l4cd3a2dai534f95545dbad8f5@mail.gmail.com> Date: Mon, 25 Aug 2008 12:59:21 -0700 From: "Adam Langley" To: "Sally Floyd" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <20080822213001.7559328C106@core3.amsl.com> <396556a20808222102k7e667443paf89edcd21574366@mail.gmail.com> X-Google-Sender-Auth: 73185520f9768c39 Cc: tcpm@ietf.org Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-ecnsyn-06.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Mon, Aug 25, 2008 at 12:51 PM, Sally Floyd wrote: > Adam - > >> 2008/8/22 : >>> >>> Title : Adding Explicit Congestion Notification (ECN) >>> Capability to TCP's SYN/ACK Packets >>> Author(s) : S. Floyd, I. Property >>> Filename : draft-ietf-tcpm-ecnsyn-06.txt >>> Pages : 29 >>> Date : 2008-08-22 >> >> "SYN packets that contain known or unknown IP options [MAF05] (Figure >> 1).)" >> >> It appears to be figure 5, at least in the version that Google pulled up. > > I don't know what version Google gave you, but in the > version on my web page at > "http://www.icir.org/floyd/papers.html#2005", > and on the ACM CCR archives, it is indeed Figure 1... It is indeed. A Google search for "Measuring the Evolution of Transport Protocols in the Internet" kicks up http://www.icir.org/floyd/papers/TCPevolution-May2004.pdf where it's figure 5. Obviously that's a previous version of the paper. Cheers AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Aug 26 13:13:49 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0126B3A6BE2; Tue, 26 Aug 2008 13:13:49 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4C7E3A6BE2 for ; Tue, 26 Aug 2008 13:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.397 X-Spam-Level: X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1, SARE_RECV_SPEEDY_AR=0.808] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ri-TzswANbx for ; Tue, 26 Aug 2008 13:13:47 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id E4E133A6B42 for ; Tue, 26 Aug 2008 13:13:45 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 8227D6B65CC; Tue, 26 Aug 2008 17:13:49 -0300 (ART) Received: from notebook.gont.com.ar (201-254-32-53.speedy.com.ar [201.254.32.53] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.13.8) with ESMTP id m7QKDZCd014074; Tue, 26 Aug 2008 17:13:36 -0300 Message-Id: <200808262013.m7QKDZCd014074@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 26 Aug 2008 17:09:13 -0300 To: tcpm@ietf.org From: Fernando Gont Mime-Version: 1.0 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Tue, 26 Aug 2008 17:13:48 -0300 (ART) Cc: tcpm-charis@tools.ietf.org, Joe Touch Subject: [tcpm] ICMP attacks draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Folks, Earlier this year I published a revision of the ICMP attacks draft. This last version is available at: http://tools.ietf.org/id/draft-ietf-tcpm-icmp-attacks-03.txt . This last version of the document aims at removing any instance of language that might seem to suggest implementation of the described counter-measures, rather than simply document them. I'd like to hear whether there are any remaining issues in the draft that I should fix before the document is ready for WGLC. Thanks! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Aug 26 13:18:50 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E7793A6B90; Tue, 26 Aug 2008 13:18:50 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 486B83A68BA for ; Tue, 26 Aug 2008 13:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[AWL=0.681, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RECV_SPEEDY_AR=0.808] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbiJmAmLgq7x for ; Tue, 26 Aug 2008 13:18:48 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 5D88028C224 for ; Tue, 26 Aug 2008 13:18:47 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 16FA56B65D4; Tue, 26 Aug 2008 17:18:48 -0300 (ART) Received: from notebook.gont.com.ar (201-254-32-53.speedy.com.ar [201.254.32.53] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.13.8) with ESMTP id m7QKIaWn015462; Tue, 26 Aug 2008 17:18:37 -0300 Message-Id: <200808262018.m7QKIaWn015462@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 26 Aug 2008 17:11:58 -0300 To: tcpm@ietf.org From: Fernando Gont Mime-Version: 1.0 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Tue, 26 Aug 2008 17:18:47 -0300 (ART) Cc: tcpm-chairs@tools.ietf.org, Joe Touch Subject: [tcpm] ICMP attacks draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Folks, (sorry, there was a typo in one of the addresses) Earlier this year I published a revision of the ICMP attacks draft. This last version is available at: http://tools.ietf.org/id/draft-ietf-tcpm-icmp-attacks-03.txt . This last version of the document aims at removing any instance of language that might seem to suggest implementation of the described counter-measures, rather than simply document them. I'd like to hear whether there are any remaining issues in the draft that I should fix before the document is ready for WGLC. Thanks! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 28 10:37:29 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35CEE3A68EC; Thu, 28 Aug 2008 10:37:29 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BCCD3A68EC for ; Thu, 28 Aug 2008 10:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkVxRCnNJR91 for ; Thu, 28 Aug 2008 10:37:27 -0700 (PDT) Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id 7DE173A685F for ; Thu, 28 Aug 2008 10:37:11 -0700 (PDT) Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id m7SHbDjn012050 for ; Thu, 28 Aug 2008 10:37:13 -0700 Received: from lawyers.icir.org (unknown [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 0261A34785A5 for ; Thu, 28 Aug 2008 13:36:41 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id DECDB87E6FD for ; Thu, 28 Aug 2008 13:37:06 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Down on the Corner MIME-Version: 1.0 Date: Thu, 28 Aug 2008 13:37:06 -0400 Message-Id: <20080828173706.DECDB87E6FD@lawyers.icir.org> Subject: [tcpm] early retransmit---WG version X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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: , Content-Type: multipart/mixed; boundary="===============0527967802==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0527967802== Content-Type: multipart/signed; boundary="--------ma57922-1"; micalg=pgp-sha1; protocol="application/pgp-signature" ----------ma57922-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Folks- I just submitted a WG version of the early retransmit spec. It is being held for manual posting, but you can slurp it from ... http://www.icir.org/mallman/papers/draft-ietf-tcpm-early-rexmt-00.txt The changes are minor in comparison to the last version. We would appreciate any feedback folks have. In particular, we haven't received much about the packet-based version of the scheme so that could use some vetting. Many thanks! allman ----------ma57922-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAki24kIACgkQWyrrWs4yIs6DRQCfVSROD49FknBuAWofMmA/0JTr iRgAoJUaSr8BT7AZzoJhhqqNcCNlaAV5 =CjjU -----END PGP SIGNATURE----- ----------ma57922-1-- --===============0527967802== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============0527967802==-- From tcpm-bounces@ietf.org Thu Aug 28 14:05:00 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1DA83A6915; Thu, 28 Aug 2008 14:05:00 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C5583A6915 for ; Thu, 28 Aug 2008 14:04:59 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IG2+7jYbWzLJ for ; Thu, 28 Aug 2008 14:04:58 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 706F63A68A3 for ; Thu, 28 Aug 2008 14:04:58 -0700 (PDT) Received: from [128.9.176.35] (c1-vpn5.isi.edu [128.9.176.35]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m7SL4UGL004020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Aug 2008 14:04:32 -0700 (PDT) Message-ID: <48B7129E.2030409@isi.edu> Date: Thu, 28 Aug 2008 14:03:26 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: David Borman References: <24D2F5D3-93E7-4B64-BA96-2086F3E5754E@windriver.com> In-Reply-To: <24D2F5D3-93E7-4B64-BA96-2086F3E5754E@windriver.com> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: rrs@cisco.com, tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , mdalal@cisco.com Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, all, Some final suggestions: - --- I believe this document should include an informational reference to IPsec and TCP-AO in the applicability statement: ...Examples of such TCP connections are the ones that tend to be long-lived and where the connection end points can be determined, in cases where no auxiliary anti-spoofing protection mechanisms like TCP MD5 [RFC2385] can be deployed. ^TCP-AO [I-D...], or IPsec [RFC4301] - --- concerns with changing TCP behavior should be noted in the applicability statement, in particular: These mitigations MAY be implemented in other cases. , with consideration for the potential implications noted in Section 10. - --- RFC4953 should be cited as a detailed explanation "The feasibility of this methodology (without mitigations) was first shown in [SITW]." , and is explained in detail in [RFC4953]. (retain the subsequent reference to 4953's discussion of probabilities) - ---- section 1.3 can be omitted, as 4953 covers this issue in detail already, as explained already in section 1.2 If retained, then add TCP-AO and IPsec to TCP MD5 as providing protection in: For applications that can use the TCP MD5 option [RFC2385], such as BGP, that option makes the attacks described in this specification effectively impossible. If retained, please omit "draft" from the following: For further details regarding the attacks and the existing techniques, please refer to draft [RFC4953] - -- section 10 should similarly refer to TCP-MD5 and TCP-AO where it refers to IPsec as providing complete protection, The only way to fully protect a TCP connection from both on and off path attacks is by using either IPSEC-AH [RFC4302] or IPSEC-ESP [RFC4303]. IMO, it would be useful to be consistent here, and thus say: IPsec [RFC4301], TCP MD5 [RFC...], or TCP-AO [I-D...] - --- Section 6 should include the context of the recommendation level of the whole document, e.g.: As described in the above sections, recommendation levels for RST, SYN and Data are tagged as SHOULD, SHOULD and MAY respectively. All of the mitigations are subject to the overall recommendations as indicated in the applicability statement in section Z, notably SHOULD use where TCP is vulnerable to off-path attacks and is not otherwise protected, and MAY elsewhere. Joe David Borman wrote: > > Wes and I would like to start the WG Last Call for: > > Title : Improving TCP's Robustness to Blind In-Window Attacks' > Author(s) : A. Ramaiah, R. Stewart & M. Dalal > Filename : draft-ietf-tcpm-tcpsecure-10.txt > Pages : 27 > Date : July 9, 2008 > Intended Status : Proposed Standard > > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-10.txt > > It is our understanding that all the feedback has been incorporated into > this latest version and that there are no known outstanding issues with > this document. > > Please send feedback to the list, even if it is just a "yes, go ahead > and publish". > > The WGLC will end on Friday, September 5, 2009. > > > David Borman & Wes Eddy, TCPM WG co-chairs > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAki3Ep4ACgkQE5f5cImnZrsS7wCdEKaxvUg3XiHXEUF/KNiwycZ0 LW0AnjkqKJ8jt0LvjYf8oBMGjnDKzzIe =q2Ph -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 28 14:59:13 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E33B28C101; Thu, 28 Aug 2008 14:59:13 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD3D23A69D8 for ; Thu, 28 Aug 2008 14:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.29 X-Spam-Level: X-Spam-Status: No, score=-3.29 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WS4hTkLCqiFL for ; Thu, 28 Aug 2008 14:59:11 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 9C7663A6A24 for ; Thu, 28 Aug 2008 14:59:10 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 95DE06B658A; Thu, 28 Aug 2008 18:59:14 -0300 (ART) Received: from notebook.gont.com.ar (host45.190-139-184.telecom.net.ar [190.139.184.45]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.13.8) with ESMTP id m7SLx23E013917; Thu, 28 Aug 2008 18:59:03 -0300 Message-Id: <200808282159.m7SLx23E013917@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 28 Aug 2008 18:54:59 -0300 To: David Borman , tcpm@ietf.org From: Fernando Gont In-Reply-To: <24D2F5D3-93E7-4B64-BA96-2086F3E5754E@windriver.com> References: <24D2F5D3-93E7-4B64-BA96-2086F3E5754E@windriver.com> Mime-Version: 1.0 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Thu, 28 Aug 2008 18:59:13 -0300 (ART) Cc: rrs@cisco.com, mdalal@cisco.com, "Anantha Ramaiah \(ananth\)" , Joe Touch Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 02:40 p.m. 21/08/2008, David Borman wrote: >http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-10.txt > >It is our understanding that all the feedback has been incorporated >into this latest version and that there are no known outstanding >issues with this document. > >Please send feedback to the list, even if it is just a "yes, go ahead >and publish". It had been raised by Joe already that the draft should include a reference to the port randomization draft: http://www.gont.com.ar/drafts/port-randomization/draft-ietf-tsvwg-port-randomization-01.txt . Considering the type of attacks the tcpsecure draft aims to mitigate, it is clear that port randomization should be taken into account. And given that this is a TSVWG WG item, I think tcpsecure should mention port randomization, and include a reference to the port randomization draft. Thanks! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 28 15:30:18 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E94ED3A6B7F; Thu, 28 Aug 2008 15:30:18 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB6013A6B7F for ; Thu, 28 Aug 2008 15:30:17 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjjdGbZ5npRB for ; Thu, 28 Aug 2008 15:30:17 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 0A3873A6AB0 for ; Thu, 28 Aug 2008 15:30:17 -0700 (PDT) Received: from [128.9.176.35] (c1-vpn5.isi.edu [128.9.176.35]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m7SMTRAe003748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Aug 2008 15:29:29 -0700 (PDT) Message-ID: <48B72687.8090800@isi.edu> Date: Thu, 28 Aug 2008 15:28:23 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Fernando Gont References: <24D2F5D3-93E7-4B64-BA96-2086F3E5754E@windriver.com> <200808282159.m7SLx23E013917@venus.xmundo.net> In-Reply-To: <200808282159.m7SLx23E013917@venus.xmundo.net> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "Anantha Ramaiah \(ananth\)" , rrs@cisco.com, tcpm@ietf.org, David Borman , mdalal@cisco.com Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yes - thanks for catching that Fernando! Joe Fernando Gont wrote: > At 02:40 p.m. 21/08/2008, David Borman wrote: > >> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-10.txt >> >> It is our understanding that all the feedback has been incorporated >> into this latest version and that there are no known outstanding >> issues with this document. >> >> Please send feedback to the list, even if it is just a "yes, go ahead >> and publish". > > It had been raised by Joe already that the draft should include a > reference to the port randomization draft: > http://www.gont.com.ar/drafts/port-randomization/draft-ietf-tsvwg-port-randomization-01.txt > . Considering the type of attacks the tcpsecure draft aims to mitigate, > it is clear that port randomization should be taken into account. And > given that this is a TSVWG WG item, I think tcpsecure should mention > port randomization, and include a reference to the port randomization > draft. > > Thanks! > > Kind regards, > > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAki3JocACgkQE5f5cImnZrv6sACg3Gex3hjhl0BHWqAC9zh35ns+ e34An0y9qefM6WIy5MN8kVQYGZBtc7cF =r16o -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 28 16:56:26 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71B9E28C1A8; Thu, 28 Aug 2008 16:56:26 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B7403A6ABE for ; Thu, 28 Aug 2008 16:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N36CU46NysPV for ; Thu, 28 Aug 2008 16:56:23 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 65B853A6A2D for ; Thu, 28 Aug 2008 16:56:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,289,1217808000"; d="scan'208";a="148680814" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 28 Aug 2008 23:56:26 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m7SNuQWA001521; Thu, 28 Aug 2008 16:56:26 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m7SNuQJP013209; Thu, 28 Aug 2008 23:56:26 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Aug 2008 16:56:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Aug 2008 16:55:12 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5805B5019B@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <200808282159.m7SLx23E013917@venus.xmundo.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt Thread-Index: AckJWVQRMhlGzJSrTICMMI7jYp6tSQADP8tw References: <24D2F5D3-93E7-4B64-BA96-2086F3E5754E@windriver.com> <200808282159.m7SLx23E013917@venus.xmundo.net> From: "Anantha Ramaiah (ananth)" To: "Fernando Gont" , "David Borman" , X-OriginalArrivalTime: 28 Aug 2008 23:56:26.0647 (UTC) FILETIME=[AED96A70:01C90969] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2164; t=1219967786; x=1220831786; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20 |Subject:=20RE=3A=20[tcpm]=20WGLC=3A=20draft-ietf-tcpm-tcps ecure-10.txt |Sender:=20; bh=iiXq5VLCG+jfA3yjbRj5SUFEzOY+CpPHWQfEVCrf3g8=; b=oqt/xwXJfzwcBZXv9nQ9F18VZFELjibUsGr74YX1GWWtLs0vwtrjUiZUuf 2W/uohUxaItJ8JrygxRRzro8QeXNcILgaKQ3FQFpDEeDqP3mh+C6vnJUdJ8c 8qBDf3813y; Authentication-Results: sj-dkim-3; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: rrs@cisco.com, "Mitesh Dalal \(mdalal\)" , Joe Touch Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Fernando, It was mentioned earlier that a reference in the security consideration section to ICMP attacks draft is needed. This was done in the latest version (ver 10). I am not sure about the port randomization though, but I can add it if the WG feels so. IMO, all the recent TCP connection robustness related drafts (port randomization, ICMP attacks etc.,) should have a reference to TCP secure since most of these drafts were inspired by TCP secure! -Anantha > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > Behalf Of Fernando Gont > Sent: Thursday, August 28, 2008 2:55 PM > To: David Borman; tcpm@ietf.org > Cc: rrs@cisco.com; Mitesh Dalal (mdalal); Anantha Ramaiah > (ananth); Joe Touch > Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt > > At 02:40 p.m. 21/08/2008, David Borman wrote: > > >http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-10.txt > > > >It is our understanding that all the feedback has been incorporated > >into this latest version and that there are no known > outstanding issues > >with this document. > > > >Please send feedback to the list, even if it is just a "yes, > go ahead > >and publish". > > It had been raised by Joe already that the draft should > include a reference to the port randomization draft: > http://www.gont.com.ar/drafts/port-randomization/draft-ietf-ts > vwg-port-randomization-01.txt > . Considering the type of attacks the tcpsecure draft aims to > mitigate, it is clear that port randomization should be taken > into account. And given that this is a TSVWG WG item, I think > tcpsecure should mention port randomization, and include a > reference to the port randomization draft. > > Thanks! > > Kind regards, > > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org PGP > Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Aug 29 12:48:45 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACBE128C13E; Fri, 29 Aug 2008 12:48:45 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6E4C28C13E for ; Fri, 29 Aug 2008 12:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.444 X-Spam-Level: X-Spam-Status: No, score=-3.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvtnLdfLr1Dt for ; Fri, 29 Aug 2008 12:48:43 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 4BD1828C13D for ; Fri, 29 Aug 2008 12:48:42 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 172876B661F; Fri, 29 Aug 2008 16:48:49 -0300 (ART) Received: from notebook.gont.com.ar (host62.190-139-184.telecom.net.ar [190.139.184.62]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.13.8) with ESMTP id m7TJmWUS006817; Fri, 29 Aug 2008 16:48:36 -0300 Message-Id: <200808291948.m7TJmWUS006817@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 29 Aug 2008 16:44:21 -0300 To: "Anantha Ramaiah (ananth)" , "David Borman" , From: Fernando Gont In-Reply-To: <0C53DCFB700D144284A584F54711EC5805B5019B@xmb-sjc-21c.amer. cisco.com> References: <24D2F5D3-93E7-4B64-BA96-2086F3E5754E@windriver.com> <200808282159.m7SLx23E013917@venus.xmundo.net> <0C53DCFB700D144284A584F54711EC5805B5019B@xmb-sjc-21c.amer.cisco.com> Mime-Version: 1.0 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Fri, 29 Aug 2008 16:48:48 -0300 (ART) Cc: rrs@cisco.com, "Mitesh Dalal \(mdalal\)" , Joe Touch Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 08:55 p.m. 28/08/2008, Anantha Ramaiah (ananth) wrote: > It was mentioned earlier that a reference in the security >consideration section to ICMP attacks draft is needed. This was done in >the latest version (ver 10). I am not sure about the port randomization >though, but I can add it if the WG feels so. The whole debate of RST attacks had to do with Paul Watson coming to the conclusion that these attacks were much more feasible than previously assumed (e.g., by some presentation that had been made at NANOG). Paul's presentation assumed a global and linear ephemeral-port selection function. IMO, the most obvious and trivial way to mitigate these blind attacks is to randomize the ephemeral port numbers. And this is even more so when there's a BCP-candidate document that has been adopted by a related WG. > IMO, all the recent TCP connection robustness related drafts (port >randomization, ICMP attacks etc.,) should have a reference to TCP secure >since most of these drafts were inspired by TCP secure! I don't quite understand this comment. My motivation for suggesting references to these documents are: * It does not make sense to address the most difficult attack vector for reset attacks if you leave a much more trivial one open (that's the reason for the reference to the ICMP attacks draft). * tcpsecure aims at mitigating blind in-window attacks. With an incremental ephemeral-port selection function, these attacks are not as "blind" as they "should" be. If you randomize ephemeral-ports, then the attack will require many more packets. (this is the reason for the reference to the port randomization draft). That said, the ICMP attack draft does reference tcpsecure. However, it was inspired by the discussions we had while writing the "Security Considerations" section of the soft errors draft. The non-wg -00 version of the port randomization I-D was written by M. Larsen... so I have no idea what inspired him to write that document. Maybe tcpsecure, maybe Paul Watson's presentation.... maybe he had already been working on that. Thanks! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Aug 29 14:40:09 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A63E3A6AA2; Fri, 29 Aug 2008 14:40:09 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DFAD3A6AA2 for ; Fri, 29 Aug 2008 14:40:07 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMeS4YL0iSAv for ; Fri, 29 Aug 2008 14:40:06 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 446E93A68A8 for ; Fri, 29 Aug 2008 14:40:06 -0700 (PDT) Received: from [128.9.160.144] (nib.isi.edu [128.9.160.144]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m7TLdnOf012458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 29 Aug 2008 14:39:51 -0700 (PDT) Message-ID: <48B86C64.6070903@isi.edu> Date: Fri, 29 Aug 2008 14:38:44 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Fernando Gont References: <24D2F5D3-93E7-4B64-BA96-2086F3E5754E@windriver.com> <200808282159.m7SLx23E013917@venus.xmundo.net> <0C53DCFB700D144284A584F54711EC5805B5019B@xmb-sjc-21c.amer.cisco.com> <200808291948.m7TJmWUS006817@venus.xmundo.net> In-Reply-To: <200808291948.m7TJmWUS006817@venus.xmundo.net> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: David Borman , rrs@cisco.com, tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , "Mitesh Dalal \(mdalal\)" Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> IMO, all the recent TCP connection robustness related drafts (port >> randomization, ICMP attacks etc.,) should have a reference to TCP >> secure since most of these drafts were inspired by TCP secure! Above Ananth is claiming that the recent burst of activity in this space is due to his draft, though Watson (CanSec West, March 2004) is the origin of the RST issue in public forums (tcpsecure-00 wasn't out until April 2004). Other solutions in this space were Larsen's port-randomisation-00 in June 2004 (later Larsen and Gont), and Poon's timestamp-00 also in June 2004, though port-randomisation closely parallels Bellovin's ISN randomization in RFC1948 from 1996. (and port randomization may have been deployed before 2004 - does anyone recall?) However, I would be glad to credit Ananth with the large number of 'attacks' on Postel's RFC793 design principle, "be liberal in what you accept from others" from 1981. ;-) Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAki4bGQACgkQE5f5cImnZrs5igCeKhNfbUiHweoYHQTvJDaxn/8L s7QAoMQvLTK91Nxg95tPnccyYwGULhp9 =Ou+1 -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Aug 29 14:50:20 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BAD728C165; Fri, 29 Aug 2008 14:50:20 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6391328C165 for ; Fri, 29 Aug 2008 14:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.496 X-Spam-Level: X-Spam-Status: No, score=-3.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUswXFwvWsDT for ; Fri, 29 Aug 2008 14:50:18 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 6CC7728C153 for ; Fri, 29 Aug 2008 14:50:17 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 1F19E6B65DD; Fri, 29 Aug 2008 18:50:25 -0300 (ART) Received: from notebook.gont.com.ar (host62.190-139-184.telecom.net.ar [190.139.184.62]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.13.8) with ESMTP id m7TLoCJe027998; Fri, 29 Aug 2008 18:50:13 -0300 Message-Id: <200808292150.m7TLoCJe027998@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 29 Aug 2008 18:46:04 -0300 To: Joe Touch From: Fernando Gont In-Reply-To: <48B86C64.6070903@isi.edu> References: <24D2F5D3-93E7-4B64-BA96-2086F3E5754E@windriver.com> <200808282159.m7SLx23E013917@venus.xmundo.net> <0C53DCFB700D144284A584F54711EC5805B5019B@xmb-sjc-21c.amer.cisco.com> <200808291948.m7TJmWUS006817@venus.xmundo.net> <48B86C64.6070903@isi.edu> Mime-Version: 1.0 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Fri, 29 Aug 2008 18:50:24 -0300 (ART) Cc: "Anantha Ramaiah \(ananth\)" , rrs@cisco.com, tcpm@ietf.org, David Borman , "Mitesh Dalal \(mdalal\)" Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 06:38 p.m. 29/08/2008, Joe Touch wrote: >Above Ananth is claiming that the recent burst of activity in this space >is due to his draft, though Watson (CanSec West, March 2004) is the >origin of the RST issue in public forums (tcpsecure-00 wasn't out until >April 2004). Exactly. >Other solutions in this space were Larsen's port-randomisation-00 in >June 2004 (later Larsen and Gont), and Poon's timestamp-00 also in June >2004, though port-randomisation closely parallels Bellovin's ISN >randomization in RFC1948 from 1996. Yes. And Larsen's port-randomisation-00 acknowledges this (and our tsvwg-port-randomization draft keeps the ack to Bellovin). >(and port randomization may have >been deployed before 2004 - does anyone recall?) Yes. It has. At least OpenBSD has shipped with port randomization way before 2004. Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Aug 29 18:45:54 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6064F3A6B1D; Fri, 29 Aug 2008 18:45:54 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD1273A6A49 for ; Fri, 29 Aug 2008 18:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.984 X-Spam-Level: * X-Spam-Status: No, score=1.984 tagged_above=-999 required=5 tests=[AWL=-2.784, BAYES_40=-0.185, J_CHICKENPOX_23=0.6, J_CHICKENPOX_33=0.6, TVD_STOCK1=3.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8+NA+iXtLcq for ; Fri, 29 Aug 2008 18:45:52 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by core3.amsl.com (Postfix) with ESMTP id C9D523A6B2B for ; Fri, 29 Aug 2008 18:45:50 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id k34so637262wah.25 for ; Fri, 29 Aug 2008 18:45:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:x-mailer:date:to:from:subject :mime-version:content-type:message-id; bh=SALo4q75L6GSZ9ehCO2BpvKYJVs5eoO9BK6xU01D27M=; b=ccy6/D5Hxb8IA0Eoa4HwtEJIkwJMcOcyOePYXB3qv5UVw6ZBTwL1uQlmdDbqjaeaaP SNfac3Qd8hnhnHvlZsMOkbJ5FKQX6LZHiCw6JOt7NMH+iH/vEe794GB5HjUlWGDIjccP FSZONFP/3RXcwer/it6OfjDr4n6dK7HOBjnXI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=x-mailer:date:to:from:subject:mime-version:content-type:message-id; b=kuVJ6g5EJjURJcYdXRtmFudpt1HSe/bsyPzNXb6S+KXhOCUQz0ovKvVDJnwILChbtp CVdKL9WL4mGC+aSF8yEzfzlXYVYeu6gl6xFV03dkl07YbldnpPhAsBJ31Hja4GYclHz+ t96YU+clljOXcpuc3j6TQ7uDpvcPPeBBkleJM= Received: by 10.114.235.8 with SMTP id i8mr3258429wah.194.1220060753254; Fri, 29 Aug 2008 18:45:53 -0700 (PDT) Received: from Gregory-T60.gmail.com ( [66.129.224.36]) by mx.google.com with ESMTPS id j28sm4024579waf.18.2008.08.29.18.45.51 (version=SSLv3 cipher=RC4-MD5); Fri, 29 Aug 2008 18:45:52 -0700 (PDT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 29 Aug 2008 18:45:48 -0700 To: tcpm@ietf.org From: "Gregory M. Lebovitz" Mime-Version: 1.0 Message-ID: <48b8a650.1cba720a.6f95.27a7@mx.google.com> Subject: [tcpm] TCP-AO: A position on NAT-T support X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org The question about whether or not TCP-AO should be designed for NAT/NAPT traversal (NAT-T) has been bandied about some on the list. My position: we SHOULD NOT design to support NAT-T. If NAT-T is a requirement for an application, then TCP-AO is the wrong choice for authentication protection. The application will need to be tunneled over IPsec using IKE+ESP. The logic for this position follows. 1. NAT-T Support is an Appropriate Requirement NATs exist. We may not want or like them, but they are there in the network. Applications want to fulfill the simultaneous requirements of being confidential and authenticated AND traversing NATs. The standards must allow for the apps to do both simultaneously. On its own, the requirement is sane and healthy. 2. Not Every Protocol MUST Fill Every Requirement The IETF MUST give every app a way to simultaneously traverse NATs AND be authenticated. However, it does not necessarily follow that every protocol must have a way to simultaneously provide apps with NAT-T and authentication. As long as at least one or more protocols does allow a specific app to accomplish NAT-T + Authentication, we have succeeded. In other words, we need not burden every protocol with every use case. In the case of TCP connections, IKE+ESP can simultaneously provide NAT-T and Authentication, though at a costs of more processing and layering and configuration complexity. 3. Designing for NAT-T in TCP-AO without tunneling MAY be impossible Supporting NAT-T means we design with the expectation that IP's and ports will be changed in flight. However, we do not relax other security requirements like replay protection. We need to solve for both inter-connection replay attacks and intra-connection replay attacks. In order to do this, we need to compute the integrity MAC across something that includes message uniqueness at time "T", and do so in a way that it would be almost impossible for the uniqueness to be duplicated at some other time T-n. Today in AO we are going to use Initial Sequence Numbers combined with Extended Sequence Numbers and a MAC over the 5 tuple to ensure uniqueness of the session. In essence, we use I/ESNs + src/dst IP + proto + src/dst Port as a "connection ID". In order to support NAT-T we must remove src/dst IP + src/dst Port from this calculation, because they may change after NATing. What do we replace it with? After reviewing the few options that do not include tunneling, one concludes that a fairly large (8 octets in ESP's case) unique Connection_ID integer is required to be included in the Option header, covered by the MAC, along with something else connection specific, like ISN. However, due to size constraints on TCP Option header lengths, most agree we cannot afford 8 octets for a Connection_ID field unless we also agree to change the size of the Data Offset field itself in the TCP header. changing TCP header fields is too big a hassle to be practically considered; the cost-benefit analysis makes no sense in this case. 4. Tunneling Works, and a Specification Exists If we can't change the bits in AO to allow for NAT-T directly, then we fall back to creating a tunneling mechanism. In a tunneling mechanism we MAC over the original IPs/Proto/Ports, and then we encapsulate all that into another header that we know will easily get through NATs, like UDP. We negotiate all this using a Key Management Protocol (KMP). This would give us something like APP-in-TCP-in-IP-in-FOO-in-IP. We process the MAC over the inner packet and its 5-tuple, and leave the outer FOO-IP untouched. And it works; NAT won't break things and we get integrity checking that allows us to leverage the 5-tuple for connection identification uniqueness. The downside is that the tunnel adds a processing stack layer above the original solution, and complexity to the overall configuration. The routing community has been averse to adding another stack above the BGP-TCP, given that processing models for BGP-TCP are now so well understood and so highly tuned on networking devices. And it has been averse to the added complexity of the tunneling mechanism. Should we conquer the tunneling aversion, we already have a specified way to do integrity checks with a NAT-T supporting tunneling mechanism: IKE+ESP with NULL-encryption. Since we have a solution to the "create-a-tunnel" problem already, we need not create another one. 5. Summary of Options to support NAT-T - Add Connection_ID field to AO and make the required change to the Data Offset field in the TCP header. There appears to be VERY little appetite for this option. - Tunnel the IP+TCP in something in deployments where you need NAT-T. In this case, employ tunnel and integrity check using IKE+ESP-NULL. 6. Recommendation: Do nothing wrt NAT-T support in TCP-AO. Add a section to TCP-AO spec instructing those needing NAT-T to either tunnel in IKE + ESP-NULL, or re-architect to remove the NAT and use TCP-AO. Thoughts? Gregory +++++++++++++++++++++++ IETF-related email from Gregory M. Lebovitz Juniper Networks g r e go r y d o t i e tf a t g m a i l do t c o m _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm