From mallman@icir.org Wed Jul 1 06:41:56 2009 Return-Path: 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 E8CD23A6F1B for ; Wed, 1 Jul 2009 06:41:56 -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 JELOf7IKBFyQ for ; Wed, 1 Jul 2009 06:41:56 -0700 (PDT) Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id 31AC43A6EED for ; Wed, 1 Jul 2009 06:41:56 -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 n61Df0YZ025556; Wed, 1 Jul 2009 06:41:01 -0700 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 68E8B3B1E7F1; Wed, 1 Jul 2009 09:40:52 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 2B1CD31BF38; Wed, 1 Jul 2009 09:40:53 -0400 (EDT) To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Lights MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma26468-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 01 Jul 2009 09:40:53 -0400 Sender: mallman@icir.org Message-Id: <20090701134053.2B1CD31BF38@lawyers.icir.org> Cc: "k.avrachenkov@sophia.inria.fr" , "tcpm@ietf.org" , jblanton@cs.ohiou.edu Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-early-rexmt-01 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: , X-List-Received-Date: Wed, 01 Jul 2009 13:41:57 -0000 ----------ma26468-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > (1) In the Introduction, paragraph 2, we have latex-style > double single-quotes instead of normal double quotes > > (2) "When using small congestion windows" > should more correctly be > "When the congestion window is small". > > (3) "Small windows can occur" -> > "Small congestion windows can occur" > > (4) "Consider a congestion window (cwnd)" > The document only uses "cwnd" in one other place, in the > Related Work, so probably doesn't need to define an abbreviation > for congestion window here. > > (5) Need to either define SMSS in this document or cite where we > pull the definition of the acronym from. Section 2 possibly > should have a sentence that says we're going to reuse the > set of terminology from the 2581bis draft or something like > that so we don't have to worry about explaining all the state > variables here. OK, I fixed all these things in my working version. Also, I replaced all references to RFC2581 to the bis document since it has been forwarded and seemingly would not block this document. If needed we can revert this change if ER somehow passes 2581bis in the processing. > (6) "good to bad retransmits" -> > "needed to unneeded retransmissions" ??? I used the language from the cited paper ([Pax97]) and am inclined to leave it because I think it is clear. If you want to insist I'll change it because it doesn't seem worth fighting over. > (7) check IDNITS :) Added intended status (experimental). Added a couple missing refs. A bunch of the refs flagged as having no reference do in fact have a reference but the tool doesn't seem to grok [ref1,ref2,ref3] sorts of constructs. RFC3522 is not normative and so I moved it. Updated the NewReno reference to RFC 3782. There is new boilerplate since we submitted -01. Big surprise. This will be fixed in -02, obviously. Many thanks! allman ----------ma26468-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkpLZ2QACgkQWyrrWs4yIs4M5ACgn1r08M8j6n7fTJVTz1jlvxsd vDQAn1/FkbRV3SUiY0m6oBVOT1BrUTpu =iJbW -----END PGP SIGNATURE----- ----------ma26468-1-- From wesley.m.eddy@nasa.gov Wed Jul 1 07:03:11 2009 Return-Path: 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 3D05228C536 for ; Wed, 1 Jul 2009 07:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.572 X-Spam-Level: X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 OuFhMeEDZiGK for ; Wed, 1 Jul 2009 07:03:10 -0700 (PDT) Received: from ndjsnpf03.ndc.nasa.gov (ndjsnpf03.ndc.nasa.gov [198.117.1.123]) by core3.amsl.com (Postfix) with ESMTP id 465B028C55D for ; Wed, 1 Jul 2009 07:03:10 -0700 (PDT) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf03.ndc.nasa.gov (Postfix) with ESMTP id D6F722E0740; Wed, 1 Jul 2009 09:02:58 -0500 (CDT) Received: from ndjshub02.ndc.nasa.gov (ndjshub02.ndc.nasa.gov [198.117.4.161]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n61E2vj8024551; Wed, 1 Jul 2009 09:02:58 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub02.ndc.nasa.gov ([198.117.4.161]) with mapi; Wed, 1 Jul 2009 09:01:55 -0500 From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" To: "mallman@icir.org" Date: Wed, 1 Jul 2009 09:01:53 -0500 Thread-Topic: WGLC on draft-ietf-tcpm-early-rexmt-01 Thread-Index: Acn6UcZ36uy0hJ67QWOnUVZXhGqnBwAAmRpA Message-ID: References: <20090701134053.2B1CD31BF38@lawyers.icir.org> In-Reply-To: <20090701134053.2B1CD31BF38@lawyers.icir.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-07-01_10:2009-06-25, 2009-07-01, 2009-07-01 signatures=0 Cc: "k.avrachenkov@sophia.inria.fr" , "tcpm@ietf.org" , "jblanton@cs.ohiou.edu" Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-early-rexmt-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: , X-List-Received-Date: Wed, 01 Jul 2009 14:03:11 -0000 >-----Original Message----- >From: mallman@icir.org [mailto:mallman@icir.org] >Sent: Wednesday, July 01, 2009 9:41 AM > >> (6) "good to bad retransmits" -> >> "needed to unneeded retransmissions" ??? > >I used the language from the cited paper ([Pax97]) and am inclined to >leave it because I think it is clear. If you want to insist I'll change >it because it doesn't seem worth fighting over. > This works for me; I didn't realize it had been quoted. --------------------------- Wes Eddy Network & Systems Architect Verizon FNS / NASA GRC Office: (216) 433-6682 --------------------------- From fernando@gont.com.ar Wed Jul 1 09:38:52 2009 Return-Path: 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 A06F13A682E for ; Wed, 1 Jul 2009 09:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.767 X-Spam-Level: X-Spam-Status: No, score=-2.767 tagged_above=-999 required=5 tests=[AWL=0.832, 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 wU8s6vjk3doW for ; Wed, 1 Jul 2009 09:38:51 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 6FB193A67F6 for ; Wed, 1 Jul 2009 09:38:50 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id E4F706B661D; Wed, 1 Jul 2009 13:38:19 -0300 (ART) Received: from [192.168.0.134] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n61Gc5HY014698; Wed, 1 Jul 2009 13:38:06 -0300 Message-ID: <4A4B90F5.5060300@gont.com.ar> Date: Wed, 01 Jul 2009 13:38:13 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Joe Touch References: <4A4317ED.1040905@gont.com.ar> <4A48F60A.7020602@gmail.com> <4A49CA1A.6060702@gont.com.ar> <4A4A2A73.0@isi.edu> <4A4A5019.1080004@gont.com.ar> <4A4A5D02.2000402@isi.edu> In-Reply-To: <4A4A5D02.2000402@isi.edu> X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Wed, 01 Jul 2009 13:38:16 -0300 (ART) Cc: Matt Mathis , "tcpm-chairs@tools.ietf.org" , tcpm Extensions WG , Matt Mathis Subject: [tcpm] Handling of malformed options (was: Re: poll for adopting draft-gont-tcp-security) 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: , X-List-Received-Date: Wed, 01 Jul 2009 16:38:52 -0000 Hello, Joe, >>>> This suggests that extending SACK while still using the same option type >>>> is not a good idea, or at least not a backwards-compatible one. >>> ... >>> >>> It may also suggest a bug. >> Where's the bug? The spec says the length field is e.g. 2. If you >> implement the standard, and receive an option with a length field that >> is different than 2, how are you supposed to process the option? If you >> don't know how to process it, it seems sensible to ignore the option. > > OK, since this is supposed to be a security doc, can you explain why you > take a segment with a mis-formed option and ignore it, even when the > length - the field that tells you where the next option starts - is > nonsensical? > > Why don't you drop the segment or send a RST? draft-gont-tcp-security recommends to silently drop the segment, *NOT* to silently ignore the option. >From Section 4.4.1 (page 43) of draft-gont-tcp-security-00: " The SACK-permitted option is composed by an option-kind octet (which must be 4), and an option-length octet which must be 2. Therefore, the following check should be performed on the option: option-length == 2 If the option does not pass this check, the TCP segment carrying the option should be silently dropped." This should be a clear example that this document is not simply turning "current implementations" into "advice". i.e., the advice provided sometimes differs from what many implementations are doing (as in this case). Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From touch@ISI.EDU Wed Jul 1 11:02:06 2009 Return-Path: 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 6C9383A6967 for ; Wed, 1 Jul 2009 11:02:06 -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 c+R0SYXOroya for ; Wed, 1 Jul 2009 11:02:05 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id CA25228C580 for ; Wed, 1 Jul 2009 10:59:29 -0700 (PDT) Received: from [70.213.187.202] (202.sub-70-213-187.myvzw.com [70.213.187.202]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n61HwQs8024652; Wed, 1 Jul 2009 10:58:29 -0700 (PDT) Message-ID: <4A4BA3BF.2020402@isi.edu> Date: Wed, 01 Jul 2009 10:58:23 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Fernando Gont References: <4A4317ED.1040905@gont.com.ar> <4A48F60A.7020602@gmail.com> <4A49CA1A.6060702@gont.com.ar> <4A4A2A73.0@isi.edu> <4A4A5019.1080004@gont.com.ar> <4A4A5D02.2000402@isi.edu> <4A4B90F5.5060300@gont.com.ar> In-Reply-To: <4A4B90F5.5060300@gont.com.ar> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Matt Mathis , "tcpm-chairs@tools.ietf.org" , tcpm Extensions WG , Matt Mathis Subject: Re: [tcpm] Handling of malformed options 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: , X-List-Received-Date: Wed, 01 Jul 2009 18:02:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Gont wrote: > Hello, Joe, > >>>>> This suggests that extending SACK while still using the same option type >>>>> is not a good idea, or at least not a backwards-compatible one. >>>> ... >>>> >>>> It may also suggest a bug. >>> Where's the bug? The spec says the length field is e.g. 2. If you >>> implement the standard, and receive an option with a length field that >>> is different than 2, how are you supposed to process the option? If you >>> don't know how to process it, it seems sensible to ignore the option. >> OK, since this is supposed to be a security doc, can you explain why you >> take a segment with a mis-formed option and ignore it, even when the >> length - the field that tells you where the next option starts - is >> nonsensical? >> >> Why don't you drop the segment or send a RST? > > draft-gont-tcp-security recommends to silently drop the segment, *NOT* > to silently ignore the option. OK, but why not make a more general recommendation for all options in this regard? And why does the doc not indicate that this does differ from what is widely deployed, and discuss that issue? Let's look at one other: 3.6.7 present Ramaiah's suggestions on RST handling, but lacks the advice on which components were already standard (silently dropping RSTs out of window) and the conditions under which Ramaiah's extensions are recommended. I continue to believe the doc needs a scrub on this point. It should be much more clear about the difference between: - recommendations already required by standards - recommendations currently deployed but not standard, and the WG's position on each (recommended, recommended in some deployments, not recommended, or no position) - additional recommendations, and whether they are consistent with or diverge from standards, and whether they have been deployed or differ from deployments If we are going to work with this doc as a starting point, having a dozen people replicating that effort isn't useful. Joe Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpLo74ACgkQE5f5cImnZruiJACgqPImxN2+k7iSFVvwoVHPDdux mFMAoOO9vJLrlwQVmnIdy9O5Pq/RwpRc =YetP -----END PGP SIGNATURE----- From fernando@gont.com.ar Wed Jul 1 12:12:27 2009 Return-Path: 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 448B828C531 for ; Wed, 1 Jul 2009 12:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.851 X-Spam-Level: X-Spam-Status: No, score=-2.851 tagged_above=-999 required=5 tests=[AWL=0.748, 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 BaqPlZWCEDM1 for ; Wed, 1 Jul 2009 12:12:26 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 6D13028C57F for ; Wed, 1 Jul 2009 12:09:50 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id C953D6B6673; Wed, 1 Jul 2009 16:10:12 -0300 (ART) Received: from [192.168.0.138] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n61J9t3Q002499; Wed, 1 Jul 2009 16:09:56 -0300 Message-ID: <4A4BB48C.7070901@gont.com.ar> Date: Wed, 01 Jul 2009 16:10:04 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Joe Touch References: <4A4317ED.1040905@gont.com.ar> <4A48F60A.7020602@gmail.com> <4A49CA1A.6060702@gont.com.ar> <4A4A2A73.0@isi.edu> <4A4A5019.1080004@gont.com.ar> <4A4A5D02.2000402@isi.edu> <4A4B90F5.5060300@gont.com.ar> <4A4BA3BF.2020402@isi.edu> In-Reply-To: <4A4BA3BF.2020402@isi.edu> X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Wed, 01 Jul 2009 16:10:08 -0300 (ART) Cc: Matt Mathis , "tcpm-chairs@tools.ietf.org" , tcpm Extensions WG , Matt Mathis Subject: Re: [tcpm] Handling of malformed options 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: , X-List-Received-Date: Wed, 01 Jul 2009 19:12:27 -0000 Hello, Joe, >>> Why don't you drop the segment or send a RST? >> draft-gont-tcp-security recommends to silently drop the segment, *NOT* >> to silently ignore the option. > > OK, but why not make a more general recommendation for all options in > this regard? Yes, I guess that such a general recommendation would make sense. The reason for which I repeated this recommendation separately for each option is that I wanted the option-specific checks to be within their respective sections. Had I made a general recommendation, it would have been something like "if the option-length doesn't match the expected option length, the corresponding segment should be silently dropped". But then that would require the implementer to go back to the spec to check which value should be checked, etc. Also, for some options there's more than one check that you should perform on the option length (e.g., see SACK). That said, there *is* a Section (3.10) with general recommendations for handling TCP options. So I guess that one could keep the option-specific checks in each of the different sections, but also add a general recommendation in Section 3.10.. I have no problem with that. > And why does the doc not indicate that this does differ > from what is widely deployed, and discuss that issue? It's just missing. As I said, I'm not saying there is not room for improvement. And I agree that this discussion that you are suggesting should be incorporated in the document (i.e., will do). > Let's look at one other: > > 3.6.7 present Ramaiah's suggestions on RST handling, but lacks the > advice on which components were already standard (silently dropping RSTs > out of window) Well, isn't this the case for any TCP segment? In-window checks are a required part of RFC 793 itself. That's why I didn't include it here explicitly. > and the conditions under which Ramaiah's extensions are > recommended. Well, the document is about improving TCP's resiliency/security. Therefore, it is assumed that at least from that pov, you will implement Ramaiah's extensions. Are are you meaning that I should state that IETF-wise, Ramaiah's extensions come with an applicability statement, etc.? > I continue to believe the doc needs a scrub on this point. [...] This may be necessary. However, I think the wg is currently making a more meta-level decision, i.e., whether to adopt draft-gont-tcp-security as a wg item. That said, I have no problem with working on this particular point you've raised. 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 From kojo@cs.helsinki.fi Wed Jul 1 14:23:41 2009 Return-Path: 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 EF4063A6F3B for ; Wed, 1 Jul 2009 14:23: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 2Te00ApnROyW for ; Wed, 1 Jul 2009 14:23:41 -0700 (PDT) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by core3.amsl.com (Postfix) with ESMTP id 1936B3A6B4B for ; Wed, 1 Jul 2009 14:23:40 -0700 (PDT) Received: from melkki.cs.helsinki.fi (melkki.cs.helsinki.fi [128.214.9.98]) (AUTH: PLAIN cs-relay, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Thu, 02 Jul 2009 00:23:48 +0300 id 0008C1F4.4A4BD3E4.00006CFC Received: by melkki.cs.helsinki.fi (Postfix, from userid 3011) id 1CCC02274DD; Thu, 2 Jul 2009 00:23:48 +0300 (EEST) Received: from localhost (localhost [127.0.0.1]) by melkki.cs.helsinki.fi (Postfix) with ESMTP id 0FBC42274DC; Thu, 2 Jul 2009 00:23:48 +0300 (EEST) Date: Thu, 2 Jul 2009 00:23:48 +0300 (EEST) From: Markku Kojo To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" In-Reply-To: Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" Subject: Re: [tcpm] draft IETF 75 agenda 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: , X-List-Received-Date: Wed, 01 Jul 2009 21:23:42 -0000 Hi, TCPM still seems to be scheduled for Friday on the draft agenda from this (Wed) morning. Any feedback from the secreteriat yet? I strongly support your suggestion to be moved to Monday, or any slot other than Friday afternoon. /Markku On Mon, 22 Jun 2009, Eddy, Wesley M. (GRC-MS00)[Verizon] wrote: > FYI, a DRAFT agenda for IETF 75 is published: > http://www.ietf.org/meetings/75/75-Draft-Agenda.pdf > > Note that TCPM is currently put on the agenda for Friday > afternoon, though this seems really undesirable, so I have > a suggestion in that we be moved to the Monday 1520-1720 > slot where there are no other TSV meeting scheduled ... I > think this would be a lot better given the typical skeleton > crew left by Friday afternoons ... > > --------------------------- > Wes Eddy > Network & Systems Architect > Verizon FNS / NASA GRC > Office: (216) 433-6682 > --------------------------- > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From wesley.m.eddy@nasa.gov Wed Jul 1 15:51:57 2009 Return-Path: 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 742613A69F3; Wed, 1 Jul 2009 15:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 MQ86u3gDYgtC; Wed, 1 Jul 2009 15:51:56 -0700 (PDT) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id BA3E83A6802; Wed, 1 Jul 2009 15:51:56 -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 B1F9032802E; Wed, 1 Jul 2009 17:52:18 -0500 (CDT) Received: from ndjshub06.ndc.nasa.gov (ndjshub06.ndc.nasa.gov [198.117.4.165]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n61MqIVJ008557; Wed, 1 Jul 2009 17:52:18 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub06.ndc.nasa.gov ([198.117.4.165]) with mapi; Wed, 1 Jul 2009 17:52:18 -0500 From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" To: "agenda@ietf.org" Date: Wed, 1 Jul 2009 17:52:17 -0500 Thread-Topic: moving TCP to Monday for IETF 75 Thread-Index: Acn6npWl7M+8MHsKROa4RwSJl2lHRg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-07-02_01:2009-06-25, 2009-07-02, 2009-07-01 signatures=0 Cc: "tcpm@ietf.org" Subject: [tcpm] moving TCP to Monday for IETF 75 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: , X-List-Received-Date: Wed, 01 Jul 2009 22:51:57 -0000 Hello Secretariat, For IETF 75, the TCPM meeting is currently on the draft agenda for Friday afternoon. This doesn't work well for several of the WG participants, but many have noted that the Monday afternoon slot where there are no other TSV meetings (1520-1720) would work well, if there's a room available. We asked once before, but is it possible to change times? --------------------------- Wes Eddy Network & Systems Architect Verizon FNS / NASA GRC Office: (216) 433-6682 --------------------------- From root@core3.amsl.com Fri Jul 3 12:15:01 2009 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 57F2F28C2EC; Fri, 3 Jul 2009 12:15:00 -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: <20090703191501.57F2F28C2EC@core3.amsl.com> Date: Fri, 3 Jul 2009 12:15:01 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-05.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: , X-List-Received-Date: Fri, 03 Jul 2009 19:15:01 -0000 --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 : The TCP Authentication Option Author(s) : J. Touch, et al. Filename : draft-ietf-tcpm-tcp-auth-opt-05.txt Pages : 46 Date : 2009-07-03 This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC-2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either static master key tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses its own option identifier, even though used mutually exclusive of TCP MD5 on a given TCP connection. TCP-AO supports IPv6, and is fully compatible with the requirements for the replacement of TCP MD5. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-auth-opt-05.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-tcp-auth-opt-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-03120545.I-D@ietf.org> --NextPart-- From L.Wood@surrey.ac.uk Fri Jul 3 16:11:03 2009 Return-Path: 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 C957E3A6919 for ; Fri, 3 Jul 2009 16:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.213 X-Spam-Level: X-Spam-Status: No, score=-6.213 tagged_above=-999 required=5 tests=[AWL=0.387, 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 XNXyDUtkv7XZ for ; Fri, 3 Jul 2009 16:11:02 -0700 (PDT) Received: from mail115.messagelabs.com (mail115.messagelabs.com [195.245.231.179]) by core3.amsl.com (Postfix) with SMTP id D05963A683F for ; Fri, 3 Jul 2009 16:11:01 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-12.tower-115.messagelabs.com!1246662684!63122377!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [131.227.102.140] Received: (qmail 14449 invoked from network); 3 Jul 2009 23:11:24 -0000 Received: from ads40.surrey.ac.uk (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-12.tower-115.messagelabs.com with SMTP; 3 Jul 2009 23:11:24 -0000 Received: from ads31.surrey.ac.uk ([131.227.120.131]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Sat, 4 Jul 2009 00:11:24 +0100 Received: from [192.168.1.209] ([86.3.114.249]) by ads31.surrey.ac.uk over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sat, 4 Jul 2009 00:11:23 +0100 Message-Id: From: Lloyd Wood To: Joe Touch In-Reply-To: <4A4A5A23.1010009@isi.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 4 Jul 2009 00:11:23 +0100 References: <4A4317ED.1040905@gont.com.ar> <4A48F60A.7020602@gmail.com> <4A49CA1A.6060702@gont.com.ar> <4A4A2A73.0@isi.edu> <4A4A3F1F.1060904@isi.edu> <4A4A56F5.30806@gont.com.ar> <4A4A5A23.1010009@isi.edu> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 03 Jul 2009 23:11:23.0636 (UTC) FILETIME=[955F6B40:01C9FC33] Cc: tcpm Extensions WG , Lloyd Wood Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security 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: , X-List-Received-Date: Fri, 03 Jul 2009 23:11:03 -0000 On 30 Jun 2009, at 19:32, Joe Touch wrote: > > I've repeatedly said why I don't want to proceed on this path. It puts > the WG in the position of repeating ourselves on issues we've already > decided. Specific example - ICMP in-window checking. We acknowledge > systems do this, where is it acknowledged? thanks, L. > but do NOT recommend it as a security check. I've said > why in at least 3 different IETF meetings, as have others. Yet this > doc > recommends it. That exceeds advice of the WG. > > If you want this doc to be the basis of work in this WG, why don't > **YOU** start by revising it to at least apply the existing WG > positions > on previously discussed advice? but Joe, you've obviously got more free time... DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/ From touch@ISI.EDU Fri Jul 3 17:51:35 2009 Return-Path: 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 647BE3A693D for ; Fri, 3 Jul 2009 17:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 VIJK-nARBcdQ for ; Fri, 3 Jul 2009 17:51:34 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 684013A6800 for ; Fri, 3 Jul 2009 17:51:34 -0700 (PDT) Received: from [192.168.1.45] (pool-71-105-84-152.lsanca.dsl-w.verizon.net [71.105.84.152]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n640pJpn006348; Fri, 3 Jul 2009 17:51:21 -0700 (PDT) Message-ID: <4A4EA787.4090004@isi.edu> Date: Fri, 03 Jul 2009 17:51:19 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Lloyd Wood References: <4A4317ED.1040905@gont.com.ar> <4A48F60A.7020602@gmail.com> <4A49CA1A.6060702@gont.com.ar> <4A4A2A73.0@isi.edu> <4A4A3F1F.1060904@isi.edu> <4A4A56F5.30806@gont.com.ar> <4A4A5A23.1010009@isi.edu> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm Extensions WG Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security 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: , X-List-Received-Date: Sat, 04 Jul 2009 00:51:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lloyd Wood wrote: > > On 30 Jun 2009, at 19:32, Joe Touch wrote: >> >> I've repeatedly said why I don't want to proceed on this path. It puts >> the WG in the position of repeating ourselves on issues we've already >> decided. Specific example - ICMP in-window checking. We acknowledge >> systems do this, > > where is it acknowledged? In Gont's ID. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpOp4cACgkQE5f5cImnZruE6gCfWgvpvbQxJsYqKdfzqmo+zGwZ L6gAoJ/EYvmN04V18ljbqlmsyN35LVgC =MXmW -----END PGP SIGNATURE----- From L.Wood@surrey.ac.uk Fri Jul 3 22:53:09 2009 Return-Path: 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 C3AA13A67F5 for ; Fri, 3 Jul 2009 22:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.245 X-Spam-Level: X-Spam-Status: No, score=-6.245 tagged_above=-999 required=5 tests=[AWL=0.354, 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 U62HeG0VAzSd for ; Fri, 3 Jul 2009 22:53:08 -0700 (PDT) Received: from mail115.messagelabs.com (mail115.messagelabs.com [195.245.231.179]) by core3.amsl.com (Postfix) with SMTP id 640193A68CC for ; Fri, 3 Jul 2009 22:53:08 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-3.tower-115.messagelabs.com!1246686691!58959963!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [131.227.102.140] Received: (qmail 1505 invoked from network); 4 Jul 2009 05:51:31 -0000 Received: from ads40.surrey.ac.uk (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-3.tower-115.messagelabs.com with SMTP; 4 Jul 2009 05:51:31 -0000 Received: from ads31.surrey.ac.uk ([131.227.120.131]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Sat, 4 Jul 2009 06:51:31 +0100 Received: from [192.168.1.209] ([86.3.114.249]) by ads31.surrey.ac.uk over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sat, 4 Jul 2009 06:51:30 +0100 Message-Id: <528F1AE1-67BC-42EA-AFF7-44A231970342@surrey.ac.uk> From: Lloyd Wood To: Joe Touch In-Reply-To: <4A4EA787.4090004@isi.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 4 Jul 2009 06:51:30 +0100 References: <4A4317ED.1040905@gont.com.ar> <4A48F60A.7020602@gmail.com> <4A49CA1A.6060702@gont.com.ar> <4A4A2A73.0@isi.edu> <4A4A3F1F.1060904@isi.edu> <4A4A56F5.30806@gont.com.ar> <4A4A5A23.1010009@isi.edu> <4A4EA787.4090004@isi.edu> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 04 Jul 2009 05:51:30.0416 (UTC) FILETIME=[7A875700:01C9FC6B] Cc: tcpm Extensions WG , Lloyd Wood Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security 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: , X-List-Received-Date: Sat, 04 Jul 2009 05:53:09 -0000 On 4 Jul 2009, at 01:51, Joe Touch wrote: > Lloyd Wood wrote: >> >> On 30 Jun 2009, at 19:32, Joe Touch wrote: >>> >>> I've repeatedly said why I don't want to proceed on this path. It >>> puts >>> the WG in the position of repeating ourselves on issues we've >>> already >>> decided. Specific example - ICMP in-window checking. We acknowledge >>> systems do this, >> >> where is it acknowledged? > > In Gont's ID. What, in the same individual ID you're spending so much energy suggesting shouldn't even exist, and which you're dismissing as implementation advice outside of the scope of the IETF and have otherwise been trying to prevent being adopted as a WG draft? How can this be the WG repeating itself on a decided issue, if the WG has not yet acknowledged this in a WG document in the first place? Obviously, it would be entirely unreasonable for someone to argue against this document's adoption as a WG item while simultaneously using this same document as an example of acknowledgement of decided WG issues not written anywhere else, for that would be... well, hypocrisy. L. "Publishing recommendations without validating them isn't wasting time."? DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/ From touch@ISI.EDU Fri Jul 3 23:09:15 2009 Return-Path: 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 D25893A6931 for ; Fri, 3 Jul 2009 23:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 jqYLsZmPUQb9 for ; Fri, 3 Jul 2009 23:09:15 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 6DB823A6B8E for ; Fri, 3 Jul 2009 23:09:06 -0700 (PDT) Received: from [192.168.1.45] (pool-71-105-84-152.lsanca.dsl-w.verizon.net [71.105.84.152]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n64684VT029550; Fri, 3 Jul 2009 23:08:05 -0700 (PDT) Message-ID: <4A4EF1C4.50305@isi.edu> Date: Fri, 03 Jul 2009 23:08:04 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Lloyd Wood References: <4A4317ED.1040905@gont.com.ar> <4A48F60A.7020602@gmail.com> <4A49CA1A.6060702@gont.com.ar> <4A4A2A73.0@isi.edu> <4A4A3F1F.1060904@isi.edu> <4A4A56F5.30806@gont.com.ar> <4A4A5A23.1010009@isi.edu> <4A4EA787.4090004@isi.edu> <528F1AE1-67BC-42EA-AFF7-44A231970342@surrey.ac.uk> In-Reply-To: <528F1AE1-67BC-42EA-AFF7-44A231970342@surrey.ac.uk> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm Extensions WG Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security 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: , X-List-Received-Date: Sat, 04 Jul 2009 06:09:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lloyd Wood wrote: > On 4 Jul 2009, at 01:51, Joe Touch wrote: >> Lloyd Wood wrote: >>> >>> On 30 Jun 2009, at 19:32, Joe Touch wrote: >>>> >>>> I've repeatedly said why I don't want to proceed on this path. It puts >>>> the WG in the position of repeating ourselves on issues we've already >>>> decided. Specific example - ICMP in-window checking. We acknowledge >>>> systems do this, >>> >>> where is it acknowledged? >> >> In Gont's ID. > > What, in the same individual ID you're spending so much energy suggesting > shouldn't even exist, and which you're dismissing as implementation advice > outside of the scope of the IETF and have otherwise been trying to prevent > being adopted as a WG draft? draft-ietf-tcpm-icmp-attacks, not this one. > How can this be the WG repeating itself on a decided issue, if the WG > has not > yet acknowledged this in a WG document in the first place? The WG acknowledged the icmp-attacks ID, not this one. > Obviously, it would be entirely unreasonable for someone to argue against > this document's adoption as a WG item while simultaneously using this same > document as an example of acknowledgement of decided WG issues not written > anywhere else, for that would be... well, hypocrisy. If this document contained only information of decided WG issues, including WG consensus on those issues, you would be correct. I have pointed out several cases where that is not the case - and that has been (and remains) my concern. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpO8cMACgkQE5f5cImnZru6LACgmnwHac9lRXPC41U4dW4j/xZo Fe8AoJGyeHw+XvYx/ii5EvG5rCUKrkyH =31TT -----END PGP SIGNATURE----- From fernando@gont.com.ar Fri Jul 3 23:54:42 2009 Return-Path: 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 442903A67F5 for ; Fri, 3 Jul 2009 23:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.919 X-Spam-Level: X-Spam-Status: No, score=-2.919 tagged_above=-999 required=5 tests=[AWL=0.680, 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 fvfs8H4C8BLF for ; Fri, 3 Jul 2009 23:54:41 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 53DC63A65A6 for ; Fri, 3 Jul 2009 23:53:55 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 041006B6747; Sat, 4 Jul 2009 03:52:23 -0300 (ART) Received: from [192.168.0.156] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n646q0SZ002813; Sat, 4 Jul 2009 03:52:00 -0300 Message-ID: <4A4EDFEB.4030008@gont.com.ar> Date: Sat, 04 Jul 2009 03:51:55 -0100 From: Fernando Gont User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Joe Touch References: <4A4317ED.1040905@gont.com.ar> <4A48F60A.7020602@gmail.com> <4A49CA1A.6060702@gont.com.ar> <4A4A2A73.0@isi.edu> <4A4A3F1F.1060904@isi.edu> <4A4A56F5.30806@gont.com.ar> <4A4A5A23.1010009@isi.edu> <4A4EA787.4090004@isi.edu> <528F1AE1-67BC-42EA-AFF7-44A231970342@surrey.ac.uk> <4A4EF1C4.50305@isi.edu> In-Reply-To: <4A4EF1C4.50305@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Sat, 04 Jul 2009 03:52:21 -0300 (ART) Cc: tcpm Extensions WG , Lloyd Wood Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security 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: , X-List-Received-Date: Sat, 04 Jul 2009 06:54:42 -0000 Joe Touch wrote: > If this document contained only information of decided WG issues, > including WG consensus on those issues, you would be correct. A very large part of draft-gont-tcp-security is about stuff that has never been discussed by this wg, but that you dismiss with arguments such as "who TCP needs not be implemented in a secure way", etc. Also, draft-gont-tcp-security is based on the idea of giving advice for implementing TCP as good resiliency as possible. And one might argue that this is a different context as that of draft-ietf-icmp-attacks, which I guess that was meant for the general case ("general case" probably being that case in which we are happy to be vulnerable to obvious and trivial attacks, I guess). > I have pointed out several cases where that is not the case - and > that has been (and remains) my concern. The only case for which you raised this is for the ICMP attacks stuff. Will you support draft-gont-tcp-security if, say, I were to remove the entire ICMP section, or replace it with a summary of what's in draft-ietf-icmp-attacks? As for the ICMP stuff itself: there have been arguments against checking ICMPs to be "in window". However, I don't seem to recall people arguing against the idea of "hard errors should be processes as soft errors when received for connections in any of the synchronized states" (*this* is what has been implemented in virtually all stacks for more than 20 years as the main counter-measure for icmp-based reset attacks). Has anybody argued against ignoring ICMP source quenches meant for TCP connections? (this is the main countermeasure for source quench attacks, and what has been implemented in most stacks). The "in-window" check is useful as a mitigation technique for the PMTU counter-measure -- however, the one described in the I-D is mainly based on the idea of "check for progress on the connection", which I believe parallels the idea in PLPMTUD. -- and I don't recall people arguing against that idea, either. Also, see the reviewers in the Acks of the I-D.. that's people from most of the major TCP implementations. And the ideas in the I-D are the running code we have and we use. However, we are so full of ourselves that we tell implementers that the code they have implemented, which has been running the Internet for the last 20 years or so, is "buggy", backed on how we think the code should be (despite it doesn't run in that way, and in some cases has not done it that way for ages (if it ever did)). Want to now what the industry did in response? -- The have ignored our consensus. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando@gont.com.ar Sat Jul 4 00:08:13 2009 Return-Path: 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 DC4D03A6877 for ; Sat, 4 Jul 2009 00:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.975 X-Spam-Level: X-Spam-Status: No, score=-2.975 tagged_above=-999 required=5 tests=[AWL=0.624, 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 1eCkW60GK8HZ for ; Sat, 4 Jul 2009 00:08:13 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id B46833A65A6 for ; Sat, 4 Jul 2009 00:08:11 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 24E876B66F4; Sat, 4 Jul 2009 04:07:33 -0300 (ART) Received: from [192.168.0.156] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n6477HFm023225; Sat, 4 Jul 2009 04:07:17 -0300 Message-ID: <4A4EE380.7000309@gont.com.ar> Date: Sat, 04 Jul 2009 04:07:12 -0100 From: Fernando Gont User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Joe Touch References: <4A4317ED.1040905@gont.com.ar> <4A48F60A.7020602@gmail.com> <4A49CA1A.6060702@gont.com.ar> <4A4A2A73.0@isi.edu> <4A4A3F1F.1060904@isi.edu> <4A4A56F5.30806@gont.com.ar> <4A4A5A23.1010009@isi.edu> <4A4EA787.4090004@isi.edu> <528F1AE1-67BC-42EA-AFF7-44A231970342@surrey.ac.uk> <4A4EF1C4.50305@isi.edu> In-Reply-To: <4A4EF1C4.50305@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Sat, 04 Jul 2009 04:07:31 -0300 (ART) Cc: tcpm Extensions WG , Lloyd Wood Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security 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: , X-List-Received-Date: Sat, 04 Jul 2009 07:08:13 -0000 Joe Touch wrote: >> Obviously, it would be entirely unreasonable for someone to argue against >> this document's adoption as a WG item while simultaneously using this same >> document as an example of acknowledgement of decided WG issues not written >> anywhere else, for that would be... well, hypocrisy. > > If this document contained only information of decided WG issues, > including WG consensus on those issues, you would be correct. I have > pointed out several cases where that is not the case - and that has been > (and remains) my concern. On April 13 (http://www.ietf.org/mail-archive/web/tcpm/current/msg04501.html) you said: "Implementation advice is outside the scope of the IETF. It's not even operational, IMO.". i.e., you argued that we should *dismiss* this I-D (draft-gont-tcp-security). So...if your opinion has now changed, and the only problem you have with this I-D is the section on "ICMP processing", would you support draft-gont-tcp-security (or at least not object its adoption as a wg item) were I to, e.g., remove the section on ICMP processing, replace it with a summary of what's in draft-ietf-icmp-attacks, or e.g., note that the provided advice is only for TCP implementations that desire good resiliency? Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From touch@ISI.EDU Sat Jul 4 09:20:05 2009 Return-Path: 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 3DC763A69B7 for ; Sat, 4 Jul 2009 09:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 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 EhZ+ZZyPBFXO for ; Sat, 4 Jul 2009 09:20:04 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 17C953A68D5 for ; Sat, 4 Jul 2009 09:20:04 -0700 (PDT) Received: from [192.168.1.45] (pool-71-105-84-152.lsanca.dsl-w.verizon.net [71.105.84.152]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n64GK6Xm005223; Sat, 4 Jul 2009 09:20:08 -0700 (PDT) Message-ID: <4A4F8136.2040004@isi.edu> Date: Sat, 04 Jul 2009 09:20:06 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Fernando Gont References: <4A4317ED.1040905@gont.com.ar> <4A48F60A.7020602@gmail.com> <4A49CA1A.6060702@gont.com.ar> <4A4A2A73.0@isi.edu> <4A4A3F1F.1060904@isi.edu> <4A4A56F5.30806@gont.com.ar> <4A4A5A23.1010009@isi.edu> <4A4EA787.4090004@isi.edu> <528F1AE1-67BC-42EA-AFF7-44A231970342@surrey.ac.uk> <4A4EF1C4.50305@isi.edu> <4A4EDFEB.4030008@gont.com.ar> In-Reply-To: <4A4EDFEB.4030008@gont.com.ar> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm Extensions WG , Lloyd Wood Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security 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: , X-List-Received-Date: Sat, 04 Jul 2009 16:20:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Gont wrote: ... > ... > Has anybody > argued against ignoring ICMP source quenches meant for TCP connections? Source quenches were supposed to be deprecated a while back, but never made it into a doc. > The "in-window" check is useful as a > mitigation technique for the PMTU counter-measure -- however, the one > described in the I-D is mainly based on the idea of "check for progress > on the connection", which I believe parallels the idea in PLPMTUD. -- > and I don't recall people arguing against that idea, either. Ignoring certain ICMPs when the connection is continuing to make progress might be reasonable. However, this has *nothing* to do with checking the in-window of the ICMP payload, which is inappropriate. As I and others have pointed out many times, routers are not required to send ICMPs in a timely basis, so there's no reason that an out-of-window ICMP should be treated any differently from an in-window one. > Also, see the reviewers in the Acks of the I-D.. that's people from most > of the major TCP implementations. And the ideas in the I-D are the > running code we have and we use. However, we are so full of ourselves > that we tell implementers that the code they have implemented, which has > been running the Internet for the last 20 years or so, is "buggy", OK, this is the sort of argument that holds no water. Convince us that something is useful and correct. Pleaase cease claiming that implementations define standards. ... > Want to now what the industry did in response? -- The have ignored our > consensus. We need to continue to pull in the direction of standards, regardless of what implementers do. If you care that much about the implementations, then change them. It'd be more productive than simply documenting what has been implemented instead. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpPgTYACgkQE5f5cImnZrtItACff2IahTUi4HniiXXfSGZo14Ld qgYAoJip2LIYpYvLUwF3ZfTODNlF+e79 =5o96 -----END PGP SIGNATURE----- From touch@ISI.EDU Sat Jul 4 09:24:22 2009 Return-Path: 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 B5CEE3A69D3 for ; Sat, 4 Jul 2009 09:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 I2d2uTpBGTGc for ; Sat, 4 Jul 2009 09:24:21 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id D64243A68D5 for ; Sat, 4 Jul 2009 09:24:21 -0700 (PDT) Received: from [192.168.1.45] (pool-71-105-84-152.lsanca.dsl-w.verizon.net [71.105.84.152]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n64GOZoJ005863; Sat, 4 Jul 2009 09:24:37 -0700 (PDT) Message-ID: <4A4F8243.4080406@isi.edu> Date: Sat, 04 Jul 2009 09:24:35 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Fernando Gont References: <4A4317ED.1040905@gont.com.ar> <4A48F60A.7020602@gmail.com> <4A49CA1A.6060702@gont.com.ar> <4A4A2A73.0@isi.edu> <4A4A3F1F.1060904@isi.edu> <4A4A56F5.30806@gont.com.ar> <4A4A5A23.1010009@isi.edu> <4A4EA787.4090004@isi.edu> <528F1AE1-67BC-42EA-AFF7-44A231970342@surrey.ac.uk> <4A4EF1C4.50305@isi.edu> <4A4EE380.7000309@gont.com.ar> In-Reply-To: <4A4EE380.7000309@gont.com.ar> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm Extensions WG , Lloyd Wood Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security 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: , X-List-Received-Date: Sat, 04 Jul 2009 16:24:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Gont wrote: > Joe Touch wrote: > >>> Obviously, it would be entirely unreasonable for someone to argue >>> against >>> this document's adoption as a WG item while simultaneously using this >>> same >>> document as an example of acknowledgement of decided WG issues not >>> written >>> anywhere else, for that would be... well, hypocrisy. >> >> If this document contained only information of decided WG issues, >> including WG consensus on those issues, you would be correct. I have >> pointed out several cases where that is not the case - and that has been >> (and remains) my concern. > > On April 13 > (http://www.ietf.org/mail-archive/web/tcpm/current/msg04501.html) you > said: "Implementation advice is outside the scope of the IETF. It's not > even operational, IMO.". i.e., you argued that we should *dismiss* this > I-D (draft-gont-tcp-security). That's correct, but please re-read what I wrote above. The doc does not contain only info the WG has consensus on. > So...if your opinion has now changed, and the only problem you have with > this I-D is the section on "ICMP processing", would you support > draft-gont-tcp-security (or at least not object its adoption as a wg > item) were I to, e.g., remove the section on ICMP processing, replace it > with a summary of what's in draft-ietf-icmp-attacks, or e.g., note that > the provided advice is only for TCP implementations that desire good > resiliency? It may be useful to explain how to efficiently implement reordering and reassembly, but not in an RFC. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEUEARECAAYFAkpPgkMACgkQE5f5cImnZrv+2gCYquNRkPnTVu8qBKDPeh4esMKB 2gCfWBKmax95BOFpERwDkAuV3bymn/w= =WRBZ -----END PGP SIGNATURE----- From L.Wood@surrey.ac.uk Sat Jul 4 10:40:12 2009 Return-Path: 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 DB1813A69D3 for ; Sat, 4 Jul 2009 10:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.272 X-Spam-Level: X-Spam-Status: No, score=-6.272 tagged_above=-999 required=5 tests=[AWL=0.327, 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 rIriS2rpwASf for ; Sat, 4 Jul 2009 10:40:11 -0700 (PDT) Received: from mail83.messagelabs.com (mail83.messagelabs.com [195.245.231.83]) by core3.amsl.com (Postfix) with SMTP id C166B3A67B6 for ; Sat, 4 Jul 2009 10:40:10 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-8.tower-83.messagelabs.com!1246729233!49795529!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [131.227.102.140] Received: (qmail 22810 invoked from network); 4 Jul 2009 17:40:34 -0000 Received: from ads40.surrey.ac.uk (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-8.tower-83.messagelabs.com with SMTP; 4 Jul 2009 17:40:34 -0000 Received: from ads31.surrey.ac.uk ([131.227.120.131]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Sat, 4 Jul 2009 18:40:33 +0100 Received: from [192.168.1.209] ([86.3.114.249]) by ads31.surrey.ac.uk over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sat, 4 Jul 2009 18:40:33 +0100 Message-Id: <3CF80CBC-71B9-4EBB-8BEC-F41B73609B2F@surrey.ac.uk> From: Lloyd Wood To: Joe Touch In-Reply-To: <4A4F8136.2040004@isi.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 4 Jul 2009 18:40:32 +0100 References: <4A4317ED.1040905@gont.com.ar> <4A48F60A.7020602@gmail.com> <4A49CA1A.6060702@gont.com.ar> <4A4A2A73.0@isi.edu> <4A4A3F1F.1060904@isi.edu> <4A4A56F5.30806@gont.com.ar> <4A4A5A23.1010009@isi.edu> <4A4EA787.4090004@isi.edu> <528F1AE1-67BC-42EA-AFF7-44A231970342@surrey.ac.uk> <4A4EF1C4.50305@isi.edu> <4A4EDFEB.4030008@gont.com.ar> <4A4F8136.2040004@isi.edu> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 04 Jul 2009 17:40:33.0256 (UTC) FILETIME=[88098E80:01C9FCCE] Cc: tcpm Extensions WG , Fernando Gont , Lloyd Wood Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security 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: , X-List-Received-Date: Sat, 04 Jul 2009 17:40:12 -0000 >> OK, this is the sort of argument that holds no water. Convince us >> that > something is useful and correct. Pleaase cease claiming that > implementations define standards. It's rough consensus and running code, Joe. (Who died and made you king?) >> Want to now what the industry did in response? -- The have ignored >> our >> consensus. > > We need to continue to pull in the direction of standards, > regardless of > what implementers do. Well then, head on back to the happy perfect world of OSI, which implementers ignored. > If you care that much about the implementations, > then change them. It'd be more productive than simply documenting what > has been implemented instead. Implementation experience is an important input to developing and refining an IETF standard. The IETF standard can't be defined wholly on paper theoretically de jure, or wholly in implementations de facto. There's a meeting in the middle - hence consensus and code. I know the M in TCP stands for minor, but really - why are we even bringing up standards arguments, when an informational doc would suffice? L. DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/ From touch@ISI.EDU Sat Jul 4 12:27:03 2009 Return-Path: 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 44FD23A6A8B for ; Sat, 4 Jul 2009 12:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 W+U-r1SgOUcF for ; Sat, 4 Jul 2009 12:27:01 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id EF3F73A6960 for ; Sat, 4 Jul 2009 12:27:00 -0700 (PDT) Received: from [192.168.1.45] (pool-71-105-84-152.lsanca.dsl-w.verizon.net [71.105.84.152]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n64JR6gK014186; Sat, 4 Jul 2009 12:27:08 -0700 (PDT) Message-ID: <4A4FAD0A.5010502@isi.edu> Date: Sat, 04 Jul 2009 12:27:06 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Lloyd Wood References: <4A4317ED.1040905@gont.com.ar> <4A48F60A.7020602@gmail.com> <4A49CA1A.6060702@gont.com.ar> <4A4A2A73.0@isi.edu> <4A4A3F1F.1060904@isi.edu> <4A4A56F5.30806@gont.com.ar> <4A4A5A23.1010009@isi.edu> <4A4EA787.4090004@isi.edu> <528F1AE1-67BC-42EA-AFF7-44A231970342@surrey.ac.uk> <4A4EF1C4.50305@isi.edu> <4A4EDFEB.4030008@gont.com.ar> <4A4F8136.2040004@isi.edu> <3CF80CBC-71B9-4EBB-8BEC-F41B73609B2F@surrey.ac.uk> In-Reply-To: <3CF80CBC-71B9-4EBB-8BEC-F41B73609B2F@surrey.ac.uk> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm Extensions WG , Fernando Gont Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security 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: , X-List-Received-Date: Sat, 04 Jul 2009 19:27:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lloyd Wood wrote: > >>> OK, this is the sort of argument that holds no water. Convince us that >> something is useful and correct. Pleaase cease claiming that >> implementations define standards. > > It's rough consensus and running code, Joe. It's rough consensus AND running code, Lloyd. Running code isn't enough. Lots of running code doesn't define consensus. >> If you care that much about the implementations, >> then change them. It'd be more productive than simply documenting what >> has been implemented instead. > > Implementation experience is an important input to developing and > refining an IETF standard. > > The IETF standard can't be defined wholly on paper theoretically de > jure, or wholly > in implementations de facto. There's a meeting in the middle - hence > consensus and code. Please review sec 9.1 of the TAO of the IETF. The running code is to prove that the standards are viable. It's the two together that are meaningful. I.e., standards AND running code, not running code THEN standards based on them. > I know the M in TCP stands for minor, but really - why are we even > bringing up standards arguments, when an informational doc would suffice? draft-gont-tcp-security reads like BCP, and recommends changes that would require it to be standards-track. Is informational the intended direction? Or BCP? Or changes to standards? Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpPrQoACgkQE5f5cImnZrvAmwCfUF5UX/F/714ijJRR86n8ucDW t7EAnRaLA8vnkl8mNNwsbZ/GOYYZPbaw =y69D -----END PGP SIGNATURE----- From L.Wood@surrey.ac.uk Sat Jul 4 13:36:37 2009 Return-Path: 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 58BE93A6804 for ; Sat, 4 Jul 2009 13:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.295 X-Spam-Level: X-Spam-Status: No, score=-6.295 tagged_above=-999 required=5 tests=[AWL=0.304, 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 rMsvksmYh9Wn for ; Sat, 4 Jul 2009 13:36:36 -0700 (PDT) Received: from mail82.messagelabs.com (mail82.messagelabs.com [195.245.231.67]) by core3.amsl.com (Postfix) with SMTP id 92E293A67D9 for ; Sat, 4 Jul 2009 13:36:35 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-12.tower-82.messagelabs.com!1246739818!67838168!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [131.227.102.140] Received: (qmail 20098 invoked from network); 4 Jul 2009 20:36:58 -0000 Received: from ads40.surrey.ac.uk (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-12.tower-82.messagelabs.com with SMTP; 4 Jul 2009 20:36:58 -0000 Received: from ads31.surrey.ac.uk ([131.227.120.131]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Sat, 4 Jul 2009 21:36:58 +0100 Received: from [192.168.1.209] ([86.3.114.249]) by ads31.surrey.ac.uk over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sat, 4 Jul 2009 21:36:57 +0100 Message-Id: <6DA8D914-3A76-415C-9DD3-2AFD8AE648F5@surrey.ac.uk> From: Lloyd Wood To: Joe Touch In-Reply-To: <4A4FAD0A.5010502@isi.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 4 Jul 2009 21:36:57 +0100 References: <4A4317ED.1040905@gont.com.ar> <4A48F60A.7020602@gmail.com> <4A49CA1A.6060702@gont.com.ar> <4A4A2A73.0@isi.edu> <4A4A3F1F.1060904@isi.edu> <4A4A56F5.30806@gont.com.ar> <4A4A5A23.1010009@isi.edu> <4A4EA787.4090004@isi.edu> <528F1AE1-67BC-42EA-AFF7-44A231970342@surrey.ac.uk> <4A4EF1C4.50305@isi.edu> <4A4EDFEB.4030008@gont.com.ar> <4A4F8136.2040004@isi.edu> <3CF80CBC-71B9-4EBB-8BEC-F41B73609B2F@surrey.ac.uk> <4A4FAD0A.5010502@isi.edu> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 04 Jul 2009 20:36:57.0680 (UTC) FILETIME=[2CD87D00:01C9FCE7] Cc: tcpm Extensions WG , Fernando Gont , Lloyd Wood Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security 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: , X-List-Received-Date: Sat, 04 Jul 2009 20:36:37 -0000 On 4 Jul 2009, at 20:27, Joe Touch wrote: > >>> If you care that much about the implementations, >>> then change them. It'd be more productive than simply documenting >>> what >>> has been implemented instead. >> >> Implementation experience is an important input to developing and >> refining an IETF standard. >> >> The IETF standard can't be defined wholly on paper theoretically de >> jure, or wholly in implementations de facto. There's a meeting in >> the middle - hence >> consensus and code. > > Please review sec 9.1 of the TAO of the IETF. You might want to reread that. From section 9.1 of the Tao of the IETF: 'One of the oft-quoted tenets of the IETF is "running code wins"' > The running code is to > prove that the standards are viable. No. 'One of the oft-quoted tenets of the IETF is "running code wins"' The code is rather the _whole point_ of the exercise. No implementations, no point. > It's the two together that are > meaningful. I.e., standards AND running code, not running code THEN > standards based on them. and not, as your 'change the implementations' line at top suggests, standards THEN running code. It's a collaborative feedback loop, not a one way process from document to code carried down the mountain to the poor saps at the bottom. Documenting what is implemented and used widely matters more than standards that aren't implemented. Running code wins. >> I know the M in TCP stands for minor, but really - why are we even >> bringing up standards arguments, when an informational doc would >> suffice? > > draft-gont-tcp-security reads like BCP, and recommends changes that > would require it to be standards-track. It recommends changes only to what was previously documented, which has long been superseded by implementations. Not to reality. (I suggest informational as a workaround, so that the standards wonks can continue to believe all is right in their world.) Running code wins. (If TCPM doesn't take on this work, then TCPM is irrelevant, and the IETF likely abdicates any authority it had on TCP. Still, there's always adding new stuff to SCTP, eh?) L. DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/ From touch@ISI.EDU Sat Jul 4 14:01:10 2009 Return-Path: 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 5ACFB3A6821 for ; Sat, 4 Jul 2009 14:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 e0rZw5WJNf-H for ; Sat, 4 Jul 2009 14:01:09 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 43CE43A67C1 for ; Sat, 4 Jul 2009 14:01:09 -0700 (PDT) Received: from [192.168.1.45] (pool-71-105-84-152.lsanca.dsl-w.verizon.net [71.105.84.152]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n64L13Sh001979; Sat, 4 Jul 2009 14:01:05 -0700 (PDT) Message-ID: <4A4FC30F.2050709@isi.edu> Date: Sat, 04 Jul 2009 14:01:03 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Lloyd Wood References: <4A4317ED.1040905@gont.com.ar> <4A48F60A.7020602@gmail.com> <4A49CA1A.6060702@gont.com.ar> <4A4A2A73.0@isi.edu> <4A4A3F1F.1060904@isi.edu> <4A4A56F5.30806@gont.com.ar> <4A4A5A23.1010009@isi.edu> <4A4EA787.4090004@isi.edu> <528F1AE1-67BC-42EA-AFF7-44A231970342@surrey.ac.uk> <4A4EF1C4.50305@isi.edu> <4A4EDFEB.4030008@gont.com.ar> <4A4F8136.2040004@isi.edu> <3CF80CBC-71B9-4EBB-8BEC-F41B73609B2F@surrey.ac.uk> <4A4FAD0A.5010502@isi.edu> <6DA8D914-3A76-415C-9DD3-2AFD8AE648F5@surrey.ac.uk> In-Reply-To: <6DA8D914-3A76-415C-9DD3-2AFD8AE648F5@surrey.ac.uk> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm Extensions WG , Fernando Gont Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security 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: , X-List-Received-Date: Sat, 04 Jul 2009 21:01:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lloyd Wood wrote: > On 4 Jul 2009, at 20:27, Joe Touch wrote: >> >>>> If you care that much about the implementations, >>>> then change them. It'd be more productive than simply documenting what >>>> has been implemented instead. >>> >>> Implementation experience is an important input to developing and >>> refining an IETF standard. >>> >>> The IETF standard can't be defined wholly on paper theoretically de >>> jure, or wholly in implementations de facto. There's a meeting in the >>> middle - hence >>> consensus and code. >> >> Please review sec 9.1 of the TAO of the IETF. > > You might want to reread that. From section 9.1 of the Tao of the IETF: > > 'One of the oft-quoted tenets of the IETF is "running code wins"' You need to quote the entire passage: Implement -- Write programs that use the current Internet standards. The standards aren't worth much unless they are available to Internet users. Implement even the "minor" standards, since they will become less minor if they appear in more software. Report any problems you find with the standards to the appropriate Working Group so that the standard can be clarified in later revisions. One of the oft-quoted tenets of the IETF is "running code wins", so you can help support the standards you want to become more widespread by creating more running code. I.e., to support the standards, make running code. Notice it doesn't say doing things the other way around. ... > (If TCPM doesn't take on this work, then TCPM is irrelevant, and the > IETF likely abdicates any authority it had on TCP. Still, there's > always adding new stuff to SCTP, eh?) You're basically claiming that RFC2525 was a waste of time. I disagree. The WG needs to decide what we want (consensus - which means my voice counts as much as yours or Fernando's), and decide what position we should take. No, I don't think TCPM's charter is to run around trying to standardize or, worse, document without taking a stand, every place where implementation differs from standard. In 1999 we had a backbone and decided between deployey* bugs (per 2525) and things we wanted to change that weren't deployed (e.g., the TOS bit, which was changed in RFC2873). All I'm asking is that we do the same now, not just claim that deployed code is the basis of an appropriate position. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpPww8ACgkQE5f5cImnZru6DwCgtu6VGxEKaYcziyeU+oYAI0HD idkAoK88uotddLqHUigHlaRVU0NwzEDB =4bLD -----END PGP SIGNATURE----- From L.Wood@surrey.ac.uk Sat Jul 4 15:44:56 2009 Return-Path: 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 5C3CE3A6A61 for ; Sat, 4 Jul 2009 15:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.316 X-Spam-Level: X-Spam-Status: No, score=-6.316 tagged_above=-999 required=5 tests=[AWL=0.283, 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 2M7Ei8tCWLDk for ; Sat, 4 Jul 2009 15:44:55 -0700 (PDT) Received: from mail114.messagelabs.com (mail114.messagelabs.com [195.245.231.163]) by core3.amsl.com (Postfix) with SMTP id 7E5703A68B6 for ; Sat, 4 Jul 2009 15:44:54 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-7.tower-114.messagelabs.com!1246747503!63926470!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [131.227.102.140] Received: (qmail 16503 invoked from network); 4 Jul 2009 22:45:03 -0000 Received: from ads40.surrey.ac.uk (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-7.tower-114.messagelabs.com with SMTP; 4 Jul 2009 22:45:03 -0000 Received: from ads31.surrey.ac.uk ([131.227.120.131]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Sat, 4 Jul 2009 23:45:03 +0100 Received: from [192.168.1.209] ([86.3.114.249]) by ads31.surrey.ac.uk over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sat, 4 Jul 2009 23:45:03 +0100 Message-Id: From: Lloyd Wood To: Joe Touch In-Reply-To: <4A4FC30F.2050709@isi.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 4 Jul 2009 23:45:01 +0100 References: <4A4317ED.1040905@gont.com.ar> <4A48F60A.7020602@gmail.com> <4A49CA1A.6060702@gont.com.ar> <4A4A2A73.0@isi.edu> <4A4A3F1F.1060904@isi.edu> <4A4A56F5.30806@gont.com.ar> <4A4A5A23.1010009@isi.edu> <4A4EA787.4090004@isi.edu> <528F1AE1-67BC-42EA-AFF7-44A231970342@surrey.ac.uk> <4A4EF1C4.50305@isi.edu> <4A4EDFEB.4030008@gont.com.ar> <4A4F8136.2040004@isi.edu> <3CF80CBC-71B9-4EBB-8BEC-F41B73609B2F@surrey.ac.uk> <4A4FAD0A.5010502@isi.edu> <6DA8D914-3A76-415C-9DD3-2AFD8AE648F5@surrey.ac.uk> <4A4FC30F.2050709@isi.edu> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 04 Jul 2009 22:45:03.0291 (UTC) FILETIME=[11D3A8B0:01C9FCF9] Cc: tcpm Extensions WG , Fernando Gont , Lloyd Wood Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security 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: , X-List-Received-Date: Sat, 04 Jul 2009 22:44:56 -0000 On 4 Jul 2009, at 22:01, Joe Touch wrote: > Lloyd Wood wrote: >> On 4 Jul 2009, at 20:27, Joe Touch wrote: >>> >>>>> If you care that much about the implementations, >>>>> then change them. It'd be more productive than simply >>>>> documenting what >>>>> has been implemented instead. >>>> >>>> Implementation experience is an important input to developing and >>>> refining an IETF standard. >>>> >>>> The IETF standard can't be defined wholly on paper theoretically de >>>> jure, or wholly in implementations de facto. There's a meeting in >>>> the >>>> middle - hence >>>> consensus and code. >>> >>> Please review sec 9.1 of the TAO of the IETF. >> >> You might want to reread that. From section 9.1 of the Tao of the >> IETF: >> >> 'One of the oft-quoted tenets of the IETF is "running code wins"' > > You need to quote the entire passage: Quoting it at all rather misses the philosophical point that Tao can never be adequately expressed in words, what? [section A.1 barely touches on this paradox.] > Implement -- Write programs that use the current Internet standards. > The > standards aren't worth much unless they are available to Internet > users. > Implement even the "minor" standards, since they will become less > minor > if they appear in more software. Report any problems you find with the > standards to the appropriate Working Group so that the standard can be > clarified in later revisions. One of the oft-quoted tenets of the IETF > is "running code wins", so you can help support the standards you want > to become more widespread by creating more running code. > > I.e., to support the standards, make running code. Notice it doesn't > say > doing things the other way around. It does: "Report any problems you find with the standards to the appropriate Working Group so that the standard can be clarified in later revisions." And those problems are found with the implementations. The standard is not immutable. The standard is not set in stone. The standard can be revised. (Much as the Tao of the IETF is revised.) There's a feedback loop. And, in that loop, running code wins. (There's another argument on how the Tao is written for the inexperienced in the IETF, and how citing it in the first place either indicates inexperience, or that far too much faith is placed in the written word, which is _so_ not Taoist, as noted above. And, of course, the Tao is informational, and thus has no bearing on standards- track docs, so a self-respecting standards wonk wouldn't use it in the first place. Much less quote it. Quoting something that recognises that it can't be encapsulated in words is really missing the point. And, reflecting on the Tao, one can observe that the above paragraph sounds awfully like the evangelism of Stallman's manifestos. Lots of do-this- for-us imperatives. It's laying out the appropriate puritan work ethic to be followed, which is certainly not Taoist. The document's a sham!) >> (If TCPM doesn't take on this work, then TCPM is irrelevant, and the >> IETF likely abdicates any authority it had on TCP. Still, there's >> always adding new stuff to SCTP, eh?) > > You're basically claiming that RFC2525 was a waste of time. I claimed no such thing. (And in 1999, when RFC2525 was published, the IETF was reaching its peak meeting attendance, indicating that it was more relevant as an organisation And TCPM didn't yet exist.) > I disagree. You're disagreeing with a strawman position that you invented for me. RFC2525 is informational, which is an approach that draft-gont could take. The difference here is that we're documenting problems with the written documentation, not with the implementations - i.e. the inverse of 2525. The feedback loop also goes the other way. The aim is to keep documents and code close together. Either can be changed. In this case, changing the documentation to match widespread practice in a mature protocol makes a lot of sense. > The WG needs to decide what we want (consensus - which means my voice > counts as much as yours or Fernando's), rough consensus, not vote counting. I think Fernando's voice, and his experience in working with others to put together this and other documents in the face of consistent opposition from you, speaks far louder than either of our voices. He's far more credible than we are. > and decide what position we > should take. No, I don't think TCPM's charter is to run around > trying to > standardize or, worse, document without taking a stand, every place > where implementation differs from standard. Surprised you didn't quote the charter here. > In 1999 we had a backbone and decided between deployey* bugs (per > 2525) > and things we wanted to change that weren't deployed (e.g., the TOS > bit, > which was changed in RFC2873). All I'm asking Constantly using the imperative tense is not asking. > is that we do the same > now, not just claim that deployed code is the basis of an appropriate > position. Deployed code is, at least, testable science. A piece of a standard without code implementing that piece as specified is merely religious dogma. And yet you prefer the latter position? (RFC2525 didn't touch on the TOS bits. False argument there.) L. DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/ From fernando@gont.com.ar Sun Jul 5 03:30:18 2009 Return-Path: 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 895DB3A6997 for ; Sun, 5 Jul 2009 03:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=0.400, 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 S5aAwcEZLV0e for ; Sun, 5 Jul 2009 03:30:17 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 5CC463A67EF for ; Sun, 5 Jul 2009 03:30:16 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 866186B65EB; Sun, 5 Jul 2009 07:30:39 -0300 (ART) Received: from [192.168.0.151] (148-82-231-201.fibertel.com.ar [201.231.82.148]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n65AUXbZ023583; Sun, 5 Jul 2009 07:30:34 -0300 Message-ID: <4A5080C6.8050002@gont.com.ar> Date: Sun, 05 Jul 2009 07:30:30 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Joe Touch References: <4A4317ED.1040905@gont.com.ar> <4A48F60A.7020602@gmail.com> <4A49CA1A.6060702@gont.com.ar> <4A4A2A73.0@isi.edu> <4A4A3F1F.1060904@isi.edu> <4A4A56F5.30806@gont.com.ar> <4A4A5A23.1010009@isi.edu> <4A4EA787.4090004@isi.edu> <528F1AE1-67BC-42EA-AFF7-44A231970342@surrey.ac.uk> <4A4EF1C4.50305@isi.edu> <4A4EE380.7000309@gont.com.ar> <4A4F8243.4080406@isi.edu> In-Reply-To: <4A4F8243.4080406@isi.edu> X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Sun, 05 Jul 2009 07:30:38 -0300 (ART) Cc: "tcpm-chairs@tools.ietf.org" , tcpm Extensions WG , Lloyd Wood Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security 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: , X-List-Received-Date: Sun, 05 Jul 2009 10:30:18 -0000 Joe Touch wrote: >> So...if your opinion has now changed, and the only problem you have >> with this I-D is the section on "ICMP processing", would you >> support draft-gont-tcp-security (or at least not object its >> adoption as a wg item) were I to, e.g., remove the section on ICMP >> processing, replace it with a summary of what's in >> draft-ietf-icmp-attacks, or e.g., note that the provided advice is >> only for TCP implementations that desire good resiliency? > > It may be useful to explain how to efficiently implement reordering > and reassembly, but not in an RFC. Is this a joke? RFC 816: "MODULARITY AND EFFICIENCY IN PROTOCOL IMPLEMENTATION" RFC 815: "IP DATAGRAM REASSEMBLY ALGORITHMS" (see Section 4) and, RFC 1936: "Implementing the Internet Checksum in Hardware" (of which you are on of the co-authors) You argue against an I-D that gives implementation advice, yet you have co-authored such an I-D? Should we take your opinion seriously? Do you do this intentionally so that we waste cycles in these pointless discussions instead of getting work done? Sorry, but I will not play your game anymore. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From touch@ISI.EDU Sun Jul 5 21:51:36 2009 Return-Path: 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 407603A6B07 for ; Sun, 5 Jul 2009 21:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 0JhDJxHGoNY1 for ; Sun, 5 Jul 2009 21:51:35 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 401213A6C39 for ; Sun, 5 Jul 2009 21:51:35 -0700 (PDT) Received: from [192.168.1.45] (pool-71-105-84-152.lsanca.dsl-w.verizon.net [71.105.84.152]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n664pdV4018764; Sun, 5 Jul 2009 21:51:40 -0700 (PDT) Message-ID: <4A5182DA.7090306@isi.edu> Date: Sun, 05 Jul 2009 21:51:38 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Fernando Gont References: <4A4317ED.1040905@gont.com.ar> <4A48F60A.7020602@gmail.com> <4A49CA1A.6060702@gont.com.ar> <4A4A2A73.0@isi.edu> <4A4A3F1F.1060904@isi.edu> <4A4A56F5.30806@gont.com.ar> <4A4A5A23.1010009@isi.edu> <4A4EA787.4090004@isi.edu> <528F1AE1-67BC-42EA-AFF7-44A231970342@surrey.ac.uk> <4A4EF1C4.50305@isi.edu> <4A4EE380.7000309@gont.com.ar> <4A4F8243.4080406@isi.edu> <4A5080C6.8050002@gont.com.ar> In-Reply-To: <4A5080C6.8050002@gont.com.ar> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm-chairs@tools.ietf.org" , tcpm Extensions WG , Lloyd Wood Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security 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: , X-List-Received-Date: Mon, 06 Jul 2009 04:51:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Gont wrote: > Joe Touch wrote: > >>> So...if your opinion has now changed, and the only problem you have >>> with this I-D is the section on "ICMP processing", would you >>> support draft-gont-tcp-security (or at least not object its >>> adoption as a wg item) were I to, e.g., remove the section on ICMP >>> processing, replace it with a summary of what's in >>> draft-ietf-icmp-attacks, or e.g., note that the provided advice is >>> only for TCP implementations that desire good resiliency? >> It may be useful to explain how to efficiently implement reordering >> and reassembly, but not in an RFC. > > Is this a joke? > > RFC 816: "MODULARITY AND EFFICIENCY IN PROTOCOL IMPLEMENTATION" That's 817, FWIW. > RFC 815: "IP DATAGRAM REASSEMBLY ALGORITHMS" (see Section 4) > > and, > > RFC 1936: "Implementing the Internet Checksum in Hardware" (of which you > are on of the co-authors) > > You argue against an I-D that gives implementation advice, yet you have > co-authored such an I-D? Should we take your opinion seriously? I didn't give advice, I gave an example, as do many RFCs. I don't agree that efficiency is an appropriate focus of an RFC, and no, that doesn't stop them from being written by others. There is a difference which is relevant to some (granted, not all) recommendations in this document. It is important to deciding whether you're describing (informationally) or recommending (BCP-ish). Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpRgtoACgkQE5f5cImnZrtfNwCeL6XSS17VVEyV+/8jTTJxsWrU E/EAn1lw40/a4rCCYTXEZLpGBnY5NM7U =zV7c -----END PGP SIGNATURE----- From touch@ISI.EDU Sun Jul 5 22:06:08 2009 Return-Path: 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 6046228C1A7 for ; Sun, 5 Jul 2009 22:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 6TeiMwda4hya for ; Sun, 5 Jul 2009 22:06:06 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id E9F7A3A6C54 for ; Sun, 5 Jul 2009 22:06:06 -0700 (PDT) Received: from [192.168.1.45] (pool-71-105-84-152.lsanca.dsl-w.verizon.net [71.105.84.152]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n6655xaq021175; Sun, 5 Jul 2009 22:06:01 -0700 (PDT) Message-ID: <4A518637.5040802@isi.edu> Date: Sun, 05 Jul 2009 22:05:59 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Lloyd Wood References: <4A4317ED.1040905@gont.com.ar> <4A48F60A.7020602@gmail.com> <4A49CA1A.6060702@gont.com.ar> <4A4A2A73.0@isi.edu> <4A4A3F1F.1060904@isi.edu> <4A4A56F5.30806@gont.com.ar> <4A4A5A23.1010009@isi.edu> <4A4EA787.4090004@isi.edu> <528F1AE1-67BC-42EA-AFF7-44A231970342@surrey.ac.uk> <4A4EF1C4.50305@isi.edu> <4A4EDFEB.4030008@gont.com.ar> <4A4F8136.2040004@isi.edu> <3CF80CBC-71B9-4EBB-8BEC-F41B73609B2F@surrey.ac.uk> <4A4FAD0A.5010502@isi.edu> <6DA8D914-3A76-415C-9DD3-2AFD8AE648F5@surrey.ac.uk> <4A4FC30F.2050709@isi.edu> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm Extensions WG , Fernando Gont Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security 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: , X-List-Received-Date: Mon, 06 Jul 2009 05:06:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lloyd Wood wrote: > On 4 Jul 2009, at 22:01, Joe Touch wrote: >> Lloyd Wood wrote: >>> On 4 Jul 2009, at 20:27, Joe Touch wrote: >>>> >>>>>> If you care that much about the implementations, >>>>>> then change them. It'd be more productive than simply documenting >>>>>> what >>>>>> has been implemented instead. >>>>> >>>>> Implementation experience is an important input to developing and >>>>> refining an IETF standard. >>>>> >>>>> The IETF standard can't be defined wholly on paper theoretically de >>>>> jure, or wholly in implementations de facto. There's a meeting in the >>>>> middle - hence >>>>> consensus and code. >>>> >>>> Please review sec 9.1 of the TAO of the IETF. >>> >>> You might want to reread that. From section 9.1 of the Tao of the IETF: >>> >>> 'One of the oft-quoted tenets of the IETF is "running code wins"' >> >> You need to quote the entire passage: > > Quoting it at all rather misses the philosophical point that Tao can never > be adequately expressed in words, what? [section A.1 barely touches > on this paradox.] So you complain when I quote it in its entirety, but respond by further quoting it out of context? >> Implement -- Write programs that use the current Internet standards. The >> standards aren't worth much unless they are available to Internet users. >> Implement even the "minor" standards, since they will become less minor >> if they appear in more software. Report any problems you find with the >> standards to the appropriate Working Group so that the standard can be >> clarified in later revisions. One of the oft-quoted tenets of the IETF >> is "running code wins", so you can help support the standards you want >> to become more widespread by creating more running code. >> >> I.e., to support the standards, make running code. Notice it doesn't say >> doing things the other way around. > > It does: "Report any problems you find with the standards to the > appropriate > Working Group so that the standard can be clarified in later revisions." Clarifying a standard is what happens when the standard has an ambiguity. Problems you find can be found in many ways. None of that says "change the standards to match implementations". None of that says that "code wins over standards". > And those problems are found with the implementations. That's one of many ways problems have been found. > The standard is not immutable. The standard is not set in stone. > The standard can be revised. (Much as the Tao of the IETF is > revised.) There's a feedback loop. And, in that loop, > running code wins. Please re-read the paragraph above. It says to write code to support the standards you want to become more widespread, not to write code to support changes to the standard that you want to them justify as evidence that the standard should be changed. ... >>> (If TCPM doesn't take on this work, then TCPM is irrelevant, and the >>> IETF likely abdicates any authority it had on TCP. Still, there's >>> always adding new stuff to SCTP, eh?) >> >> You're basically claiming that RFC2525 was a waste of time. > > I claimed no such thing. (And in 1999, when RFC2525 was published, the IETF > was reaching its peak meeting attendance, indicating that it was more > relevant as an organisation And TCPM didn't yet exist.) > >> I disagree. > > You're disagreeing with a strawman position that you invented for me. > > RFC2525 is informational, which is an approach that draft-gont could take. 2525 doesn't need to be more than informational; it didn't change the standards (it reiterated them, essentially). Straying from the standard means either standards track (to change the standard) or BCP (to explain ways to apply SHOULDs/alternates in the standard to an environment). And 2525 talks about how implementations vary from the standard, not implementation issues that a standard never addresses (nor should it). > The difference here is that we're documenting problems with the written > documentation, not with the implementations - i.e. the inverse of 2525. > The feedback loop also goes the other way. The aim is to keep documents > and code close together. Either can be changed. In this case, changing > the documentation to match widespread practice in a mature > protocol makes a lot of sense. ... >> and decide what position we >> should take. No, I don't think TCPM's charter is to run around trying to >> standardize or, worse, document without taking a stand, every place >> where implementation differs from standard. > > Surprised you didn't quote the charter here. I'll wait for you to show me where in the charter it explains that we're here to document and standardize implementations, rather than to decide what's better for the future of TCP. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpRhjcACgkQE5f5cImnZrug7QCgjNhvaPZECGACEhgJH4xvpFkK T0MAoJ5U++FcYym1sE9gvRwJ2bGAK/0z =/yHf -----END PGP SIGNATURE----- From L.Wood@surrey.ac.uk Sun Jul 5 22:59:30 2009 Return-Path: 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 556BB3A6407 for ; Sun, 5 Jul 2009 22:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.333 X-Spam-Level: X-Spam-Status: No, score=-6.333 tagged_above=-999 required=5 tests=[AWL=0.266, 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 u4q3fA-YZAnL for ; Sun, 5 Jul 2009 22:59:29 -0700 (PDT) Received: from mail82.messagelabs.com (mail82.messagelabs.com [195.245.231.67]) by core3.amsl.com (Postfix) with SMTP id B216E3A67DD for ; Sun, 5 Jul 2009 22:59:28 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-10.tower-82.messagelabs.com!1246859990!67064519!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [131.227.102.140] Received: (qmail 13102 invoked from network); 6 Jul 2009 05:59:50 -0000 Received: from ads40.surrey.ac.uk (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-10.tower-82.messagelabs.com with SMTP; 6 Jul 2009 05:59:50 -0000 Received: from ads31.surrey.ac.uk ([131.227.120.131]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Jul 2009 06:59:50 +0100 Received: from [192.168.1.209] ([86.3.114.249]) by ads31.surrey.ac.uk over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Jul 2009 06:59:49 +0100 Message-Id: From: Lloyd Wood To: Joe Touch In-Reply-To: <4A518637.5040802@isi.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 6 Jul 2009 06:59:48 +0100 References: <4A4317ED.1040905@gont.com.ar> <4A48F60A.7020602@gmail.com> <4A49CA1A.6060702@gont.com.ar> <4A4A2A73.0@isi.edu> <4A4A3F1F.1060904@isi.edu> <4A4A56F5.30806@gont.com.ar> <4A4A5A23.1010009@isi.edu> <4A4EA787.4090004@isi.edu> <528F1AE1-67BC-42EA-AFF7-44A231970342@surrey.ac.uk> <4A4EF1C4.50305@isi.edu> <4A4EDFEB.4030008@gont.com.ar> <4A4F8136.2040004@isi.edu> <3CF80CBC-71B9-4EBB-8BEC-F41B73609B2F@surrey.ac.uk> <4A4FAD0A.5010502@isi.edu> <6DA8D914-3A76-415C-9DD3-2AFD8AE648F5@surrey.ac.uk> <4A4FC30F.2050709@isi.edu> <4A518637.5040802@isi.edu> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 06 Jul 2009 05:59:49.0497 (UTC) FILETIME=[F8D48E90:01C9FDFE] Cc: tcpm Extensions WG , Fernando Gont , Lloyd Wood Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security 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: , X-List-Received-Date: Mon, 06 Jul 2009 05:59:30 -0000 > I'll wait for you to show me where in the charter it explains that > we're > here to document and standardize implementations, rather than to > decide > what's better for the future of TCP. The future of TCP only becomes real when implemented. If you ignore implementations, you have no business "deciding the future of TCP". Implementers detect pomposity, and route around it. L. DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/ From ayourtch@cisco.com Mon Jul 6 09:30:00 2009 Return-Path: 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 9DB1828C2BC for ; Mon, 6 Jul 2009 09:30: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 nb0ZVxh0ikl7 for ; Mon, 6 Jul 2009 09:29:59 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 68ADA3A6B7F for ; Mon, 6 Jul 2009 09:29:59 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n66GTm00011141; Mon, 6 Jul 2009 18:29:48 +0200 (CEST) Received: from kk-son (dhcp-peg3-vl30-144-254-7-191.cisco.com [144.254.7.191]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n66GTlE0026976; Mon, 6 Jul 2009 18:29:48 +0200 (CEST) Date: Mon, 6 Jul 2009 18:31:04 +0200 (CEST) From: Andrew Yourtchenko X-X-Sender: ayourtch@zippy.stdio.be To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: tcpm Extensions WG Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ayourtch@cisco.com List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 16:30:00 -0000 On Wed, 24 Jun 2009, Eddy, Wesley M. (GRC-MS00)[Verizon] wrote: > TCPMers, there was a thread a while ago about working on > draft-gont-tcp-security in this working group that didn't > conclusively give us a feeling one way or other: > http://www.ietf.org/mail-archive/web/tcpm/current/msg04489.html > > Basically, my understanding is that there are at least a > handful of people in the WG that think it should be done > here as a WG item (more likely for Informational rather > than BCP), and there are also some expressed opinions on > why it shouldn't. > > Given the raw size of the document, if the WG intends to > take this document on, then we need some people to clearly > commit to putting cycles into review and contributions to > the document. Since it is quite large, and to my knowledge, > there hasn't been a specific technical review of the content > on this list, but just discussions about if the idea in > general is a good or bad thing, we still need to know if > people are willing to invest their time and energy in this. I think the further development of this document with the balanced approach (cf: 'the requirements' mention and evaluating the mitigations with respect to them) is a useful activity, and as such, would like to commit cycles to it if it gets adopted. thanks, andrew > > Please let us know if there is traction for this in the > near term, and/or we can also discuss it in Stockholm. > > --------------------------- > Wes Eddy > Network & Systems Architect > Verizon FNS / NASA GRC > Office: (216) 433-6682 > --------------------------- > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From wesley.m.eddy@nasa.gov Tue Jul 7 06:30:26 2009 Return-Path: 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 C8CC53A6B68 for ; Tue, 7 Jul 2009 06:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.575 X-Spam-Level: X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 Y3AubpQKU98i for ; Tue, 7 Jul 2009 06:30:26 -0700 (PDT) Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [198.117.0.123]) by core3.amsl.com (Postfix) with ESMTP id 091AD3A69BC for ; Tue, 7 Jul 2009 06:30:26 -0700 (PDT) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id C85D42D8416 for ; Tue, 7 Jul 2009 08:30:40 -0500 (CDT) Received: from ndjshub02.ndc.nasa.gov (ndjshub02.ndc.nasa.gov [198.117.4.161]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n67DUdWB004686 for ; Tue, 7 Jul 2009 08:30:41 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub02.ndc.nasa.gov ([198.117.4.161]) with mapi; Tue, 7 Jul 2009 08:30:38 -0500 From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" To: "tcpm@ietf.org" Date: Tue, 7 Jul 2009 08:30:36 -0500 Thread-Topic: 75th IETF - Final Agenda Thread-Index: Acn+xaHVJmexzvZrTgOmwTIibSjpiAAQVyNw Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-07-07_10:2009-07-03, 2009-07-07, 2009-07-07 signatures=0 Subject: [tcpm] FW: 75th IETF - Final Agenda 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: , X-List-Received-Date: Tue, 07 Jul 2009 13:30:26 -0000 RllJIC0gVENQTSBpcyBub3cgTW9uZGF5IEp1bHkgMjcsIGZyb20gMTc0MC0xOTQwLiAgVGhpcyBp cyBtdWNoDQpiZXR0ZXIgdGhhbiB0aGUgRnJpZGF5IHNsb3QgZm9yIHVzLCBJIHRoaW5rIDopLg0K DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCldlcyBFZGR5DQpOZXR3b3JrICYgU3lzdGVt cyBBcmNoaXRlY3QNClZlcml6b24gRk5TIC8gTkFTQSBHUkMNCk9mZmljZTogKDIxNikgNDMzLTY2 ODINCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj5Gcm9tOiB3Z2NoYWlycy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86d2djaGFpcnMt Ym91bmNlc0BpZXRmLm9yZ10gT24NCj5CZWhhbGYgT2YgSUVURiBBZ2VuZGENCj5TZW50OiBUdWVz ZGF5LCBKdWx5IDA3LCAyMDA5IDE6NDEgQU0NCj5UbzogSUVURiBBbm5vdW5jZW1lbnQgbGlzdA0K PkNjOiBpcnNnQGlzaS5lZHU7IHdnY2hhaXJzQGlldGYub3JnOyBib2ZjaGFpcnNAaWV0Zi5vcmcN Cj5TdWJqZWN0OiA3NXRoIElFVEYgLSBGaW5hbCBBZ2VuZGENCj4NCj5UaGUgRmluYWwgYWdlbmRh IGlzIG5vdyBhdmFpbGFibGUgYXQ6DQo+aHR0cDovL3d3dy5pZXRmLm9yZy9tZWV0aW5ncy83NS8N Cj4NCj5PbmxpbmUgcmVnaXN0cmF0aW9uIGZvciB0aGUgSUVURiBtZWV0aW5nIGlzIGF0Og0KPmh0 dHA6Ly93d3cuaWV0Zi5vcmcvbWVldGluZ3MvNzUvDQo+DQo+DQoNCg== From wesley.m.eddy@nasa.gov Tue Jul 7 17:45:15 2009 Return-Path: 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 C18403A6973 for ; Tue, 7 Jul 2009 17:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.695 X-Spam-Level: X-Spam-Status: No, score=-5.695 tagged_above=-999 required=5 tests=[AWL=-0.858, BAYES_00=-2.599, MISSING_SUBJECT=1.762, 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 7lEEJhrruAyB for ; Tue, 7 Jul 2009 17:45: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 AA7CE3A699F for ; Tue, 7 Jul 2009 17:45:14 -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 B38A0328240 for ; Tue, 7 Jul 2009 19:45:12 -0500 (CDT) Received: from ndjshub06.ndc.nasa.gov (ndjshub06.ndc.nasa.gov [198.117.4.165]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n680jDbF000384 for ; Tue, 7 Jul 2009 19:45:13 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub06.ndc.nasa.gov ([198.117.4.165]) with mapi; Tue, 7 Jul 2009 19:45:12 -0500 From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" To: "tcpm@ietf.org" Date: Tue, 7 Jul 2009 19:45:11 -0500 Thread-Index: AQHJ/2VZmQFnX2LPZ0mwcQVcC5fs6Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-07-08_01:2009-07-03, 2009-07-08, 2009-07-07 signatures=0 Subject: [tcpm] (no subject) 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: , X-List-Received-Date: Wed, 08 Jul 2009 00:45:15 -0000 Here's a draft agenda for the TCPM meeting in Stockholm; please let David a= nd I know if we missed anyone that asked for a slot, or if there are other = people that want slots ... there should be a little bit of room left given = our 2 hour timeslot that was allocated. TCP Maintenance & Minor Extensions Agenda IETF 75 - Stockholm, Sweden =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D Note Well, Agenda Bashing WG Status 10 minutes Current WG Items ---------------- TCP Authentication Option Changes & Status Joe Touch 20 minutes Other Items ----------- draft-gont-tcp-security WG Discussion 15 minutes Make TCP More Robust to Long Connectivity Disruptions Alexander Zimmerman 15 minutes Lowering the Initial RTO Jerry Chu 15 minutes --------------------------- Wes Eddy Network & Systems Architect Verizon FNS / NASA GRC Office: (216) 433-6682 ---------------------------= From wesley.m.eddy@nasa.gov Tue Jul 7 17:47:45 2009 Return-Path: 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 448A73A68E5 for ; Tue, 7 Jul 2009 17:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.542 X-Spam-Level: X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 TuI1NyVvybSF for ; Tue, 7 Jul 2009 17:47:44 -0700 (PDT) Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by core3.amsl.com (Postfix) with ESMTP id 6F3233A6767 for ; Tue, 7 Jul 2009 17:47:44 -0700 (PDT) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id D9AFC108304 for ; Tue, 7 Jul 2009 19:47:24 -0500 (CDT) Received: from ndjshub06.ndc.nasa.gov (ndjshub06.ndc.nasa.gov [198.117.4.165]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n680lPId030287 for ; Tue, 7 Jul 2009 19:47:25 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub06.ndc.nasa.gov ([198.117.4.165]) with mapi; Tue, 7 Jul 2009 19:47:24 -0500 From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" , "tcpm@ietf.org" Date: Tue, 7 Jul 2009 19:46:53 -0500 Thread-Topic: Draft Agenda for IET5 75 TCPM Meeting Thread-Index: AQHJ/2Wo4ns7fLkIHUq70M+DDLGXlQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-07-08_01:2009-07-03, 2009-07-08, 2009-07-07 signatures=0 Subject: [tcpm] Draft Agenda for IET5 75 TCPM Meeting 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: , X-List-Received-Date: Wed, 08 Jul 2009 00:47:45 -0000 Apologies for lack of subject line ... ________________________________________ From: Eddy, Wesley M. (GRC-MS00)[Verizon] Sent: Tuesday, July 07, 2009 8:45 PM To: tcpm@ietf.org Subject: Here's a draft agenda for the TCPM meeting in Stockholm; please let David a= nd I know if we missed anyone that asked for a slot, or if there are other = people that want slots ... there should be a little bit of room left given = our 2 hour timeslot that was allocated. TCP Maintenance & Minor Extensions Agenda IETF 75 - Stockholm, Sweden =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D Note Well, Agenda Bashing WG Status 10 minutes Current WG Items ---------------- TCP Authentication Option Changes & Status Joe Touch 20 minutes Other Items ----------- draft-gont-tcp-security WG Discussion 15 minutes Make TCP More Robust to Long Connectivity Disruptions Alexander Zimmerman 15 minutes Lowering the Initial RTO Jerry Chu 15 minutes --------------------------- Wes Eddy Network & Systems Architect Verizon FNS / NASA GRC Office: (216) 433-6682 ---------------------------= From gregory.ietf@gmail.com Sat Jul 11 16:45:55 2009 Return-Path: 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 AB17D3A6BE5 for ; Sat, 11 Jul 2009 16:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.24 X-Spam-Level: X-Spam-Status: No, score=-2.24 tagged_above=-999 required=5 tests=[AWL=0.358, 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 2-3d1O5tXcfw for ; Sat, 11 Jul 2009 16:45:55 -0700 (PDT) Received: from mail-pz0-f198.google.com (mail-pz0-f198.google.com [209.85.222.198]) by core3.amsl.com (Postfix) with ESMTP id 0486A3A69CA for ; Sat, 11 Jul 2009 16:45:54 -0700 (PDT) Received: by pzk36 with SMTP id 36so1719107pzk.29 for ; Sat, 11 Jul 2009 16:46: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:x-mailer:date:to :from:subject:cc:mime-version:content-type; bh=YQg/AvwExaDlv6vsA4GTZkiMAIz+xOl8rzlBOVjERYk=; b=u4ZkVLTMFFm6arQRxTQ3P3Ea4sEm7LWEDv4LahQMgOgcz/ohp6XataOMY0xhD5JGLD nKuFUkDME8YBDgpX2fBOz+QfOEbeWwUHj6kb2gjDXnsQsIqDzZsn0rrXTj2InvKw2eLT HOn08Y4fzkNRk6wiiep/N6bbH4S0O3Z3oGh2M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:date:to:from:subject:cc:mime-version :content-type; b=PZ136HhXGhHBcYxQyLWJSJEfSeviR2uNcG7kvTWt/DgCitQdKZeLUuNinXvEBE/m3/ 3uOleQUfI1Wh8LwUDxtj1auJbZGekcoLxZ7Y0CU2B+nJ4NgSS55/hWZjw828IJ5Oh22g sABt/a4wGEz5eE9QUnCHxjoSqnrMAYPSePhVc= Received: by 10.142.49.20 with SMTP id w20mr1060357wfw.204.1247355982611; Sat, 11 Jul 2009 16:46:22 -0700 (PDT) Received: from Gregory-T60.gmail.com (c-76-126-96-36.hsd1.ca.comcast.net [76.126.96.36]) by mx.google.com with ESMTPS id 30sm5398578wfa.35.2009.07.11.16.46.21 (version=SSLv3 cipher=RC4-MD5); Sat, 11 Jul 2009 16:46:21 -0700 (PDT) Message-ID: <4a59244d.1e018e0a.446e.1c3e@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 11 Jul 2009 16:46:15 -0700 To: Wesley Eddy , David Borman From: "Gregory M. Lebovitz" Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_6631703==.ALT" Cc: tcpm@ietf.org Subject: [tcpm] spot for crypt 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: , X-List-Received-Date: Sat, 11 Jul 2009 23:45:55 -0000 --=====================_6631703==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Gents, We probably need 5-10 min in Stockholm to review the updated (will come out in next 48 hrs) AO-crypto-helper draft. Suggested text for agenda: * Gregory Lebovitz (10 minutes) "Cryptographic Algorithms, Use, & Implementation Requirments for TCP Authentication Option" draft-lebovitz-ietf-tcpm-tcp-ao-crypto-01 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 --=====================_6631703==.ALT Content-Type: text/html; charset="us-ascii" Gents,
We probably need 5-10 min in Stockholm to review the updated (will come out in next 48 hrs) AO-crypto-helper draft.

Suggested text for agenda:

   * Gregory
Lebovitz                                      
(10 minutes)
            
"Cryptographic Algorithms, Use, & Implementation
            
Requirments for TCP Authentication Option"
               

draft-lebovitz-ietf-tcpm-tcp-ao-crypto-01
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 --=====================_6631703==.ALT-- From gregory.ietf@gmail.com Sat Jul 11 23:56:11 2009 Return-Path: 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 785C53A68E8 for ; Sat, 11 Jul 2009 23:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.712 X-Spam-Level: X-Spam-Status: No, score=-1.712 tagged_above=-999 required=5 tests=[AWL=-0.313, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_37=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 B37eIG4YGI-u for ; Sat, 11 Jul 2009 23:56:10 -0700 (PDT) Received: from mail-pz0-f198.google.com (mail-pz0-f198.google.com [209.85.222.198]) by core3.amsl.com (Postfix) with ESMTP id C07F23A68D7 for ; Sat, 11 Jul 2009 23:56:10 -0700 (PDT) Received: by pzk36 with SMTP id 36so1862002pzk.29 for ; Sat, 11 Jul 2009 23:56: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:x-mailer:date:to :from:subject:cc:mime-version:content-type; bh=OQh/pXrPoET7Psy9EhEsj4r2RCBP8AXFherWjTaNZqk=; b=YlkPnP2Xljft619BAicPeRn+rvSwmspxV0Ksq/IcwVuFkIpZEbvlLJYrCNno3IvaT4 jwUijuaPB0GH3G5FMJpCxR7pnqpv/jYHpKyTGI14WPMIhsb+6cqQv77b4OLhn6rVWnu2 Jb2Xz3qipVs56lPAJvEjaQy/3+TTWmb8VUORs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:date:to:from:subject:cc:mime-version :content-type; b=fzfIJKM2OlIV7PfkSFbmH/AW+zVgQrh3CHvZ/RmAPEeSIUjTjKLAEvXgH37Q328EDi 7/ijoGiJBb/wNJIrr9YwnzuR5VDdpZ9yvyipBCYNpmzQRuwaz3R9Va1P+VHhIuF0l3Ui s2Q37Q+61oZkC753SuXP/STrZS8wyeXVxkgxY= Received: by 10.142.156.2 with SMTP id d2mr948513wfe.299.1247381798532; Sat, 11 Jul 2009 23:56:38 -0700 (PDT) Received: from Gregory-T60.gmail.com (c-76-126-96-36.hsd1.ca.comcast.net [76.126.96.36]) by mx.google.com with ESMTPS id 24sm5916875wff.6.2009.07.11.23.56.36 (version=SSLv3 cipher=RC4-MD5); Sat, 11 Jul 2009 23:56:37 -0700 (PDT) Message-ID: <4a598925.18068e0a.73eb.26d0@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 11 Jul 2009 23:56:32 -0700 To: Eric Rescorla ,Joe Touch , Tim Polk ,Brian Weis , Bill Atwood ,David McGrew From: "Gregory M. Lebovitz" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: David Borman , tcpm@ietf.org, Wesley Eddy Subject: [tcpm] Fwd: New Version Notification for draft-lebovitz-ietf-tcpm-tcp-ao-crypto-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: , X-List-Received-Date: Sun, 12 Jul 2009 06:56:11 -0000 Folks, I just submitted the update for this document. Please have a quick review and provide feedback to me, cc'ing the tcpm@ietf.org list. Wes and David B - the draft is posted, so you can link it in the WG agenda now. Hope it helps, Gregory. >Delivered-To: gregory.ietf@gmail.com >Authentication-Results: mx.google.com; spf=neutral (google.com: >64.170.98.32 is neither permitted nor denied by best guess record >for domain of wwwrun@core3.amsl.com) smtp.mail=wwwrun@core3.amsl.com >From: IETF I-D Submission Tool >To: gregory.ietf@gmail.com >Subject: New Version Notification for > draft-lebovitz-ietf-tcpm-tcp-ao-crypto-01 >Date: Sat, 11 Jul 2009 23:48:20 -0700 (PDT) > > >A new version of I-D, draft-lebovitz-ietf-tcpm-tcp-ao-crypto-01.txt >has been successfuly submitted by Gregory Lebovitz and posted to the >IETF repository. > >Filename: draft-lebovitz-ietf-tcpm-tcp-ao-crypto >Revision: 01 >Title: Cryptographic Algorithms, Use, & Implementation >Requirments for TCP Authentication Option >Creation_date: 2009-07-11 >WG ID: Independent Submission >Number_of_pages: 16 > >Abstract: >The TCP Authentication Option, TCP-AO, relies on security algorithms >to provide authentication between two end-points. There are many >such algorithms available, and two TCP-AO systems cannot interoperate >unless they are using the same algorithm(s). This document specifies >the algorithms and attributes that can be used in TCP-AO's current >manual keying mechanism. > > > > >The IETF Secretariat. +++++++++++++++++++++++ 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 From touch@ISI.EDU Sun Jul 12 08:36:07 2009 Return-Path: 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 4D68728C12E for ; Sun, 12 Jul 2009 08:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[AWL=-0.516, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_37=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 XJWMOZ284O8b for ; Sun, 12 Jul 2009 08:36:06 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 86F6428C128 for ; Sun, 12 Jul 2009 08:36:06 -0700 (PDT) Received: from [192.168.1.45] (pool-71-105-84-152.lsanca.dsl-w.verizon.net [71.105.84.152]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n6CFZY94004157; Sun, 12 Jul 2009 08:35:35 -0700 (PDT) Message-ID: <4A5A02C6.8080809@isi.edu> Date: Sun, 12 Jul 2009 08:35:34 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Gregory M. Lebovitz" References: <4a598925.18068e0a.73eb.26d0@mx.google.com> In-Reply-To: <4a598925.18068e0a.73eb.26d0@mx.google.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Fwd: New Version Notification for draft-lebovitz-ietf-tcpm-tcp-ao-crypto-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: , X-List-Received-Date: Sun, 12 Jul 2009 15:36:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gregory, The document needs to be updated to align with AO-05 as follows: - remove the reference to the TAPD; use Master Key Tuple (MKT) instead - check spelling (TPC vs TCP) - AO uses the term data_block, not conn_block, for KDF input (conn_block could refer to the TCB from RFC 793, so I avoided that term) - the output of the PRF should be called the traffic key, not the connection key; similarly for the input to the MAC alg if a shorter term is needed in this doc, it needs to be defined in this doc (e.g., traff_key), because TCP-AO-05 doesn't define any notation other than "traffic key" - check formatting, esp. the line starting "where FR is always" - the tips for UI are useful, but 'tips' aren't a specification, so SHOULDs need to be removed Joe Gregory M. Lebovitz wrote: > Folks, > I just submitted the update for this document. Please have a quick > review and provide feedback to me, cc'ing the tcpm@ietf.org list. > > Wes and David B - the draft is posted, so you can link it in the WG > agenda now. > > Hope it helps, > Gregory. > >> Delivered-To: gregory.ietf@gmail.com >> Authentication-Results: mx.google.com; spf=neutral (google.com: >> 64.170.98.32 is neither permitted nor denied by best guess record for >> domain of wwwrun@core3.amsl.com) smtp.mail=wwwrun@core3.amsl.com >> From: IETF I-D Submission Tool >> To: gregory.ietf@gmail.com >> Subject: New Version Notification for >> draft-lebovitz-ietf-tcpm-tcp-ao-crypto-01 >> Date: Sat, 11 Jul 2009 23:48:20 -0700 (PDT) >> >> >> A new version of I-D, draft-lebovitz-ietf-tcpm-tcp-ao-crypto-01.txt >> has been successfuly submitted by Gregory Lebovitz and posted to the >> IETF repository. >> >> Filename: draft-lebovitz-ietf-tcpm-tcp-ao-crypto >> Revision: 01 >> Title: Cryptographic Algorithms, Use, & Implementation >> Requirments for TCP Authentication Option >> Creation_date: 2009-07-11 >> WG ID: Independent Submission >> Number_of_pages: 16 >> >> Abstract: >> The TCP Authentication Option, TCP-AO, relies on security algorithms >> to provide authentication between two end-points. There are many >> such algorithms available, and two TCP-AO systems cannot interoperate >> unless they are using the same algorithm(s). This document specifies >> the algorithms and attributes that can be used in TCP-AO's current >> manual keying mechanism. >> >> >> >> >> The IETF Secretariat. > > +++++++++++++++++++++++ > 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpaAsUACgkQE5f5cImnZrvUJwCfTxY6TfCxtTmj9cLeBfQVA/UH 0jkAmwVqxtf3GgRT9KG/OX/zWYT0P0qT =dIB1 -----END PGP SIGNATURE----- From wesley.m.eddy@nasa.gov Mon Jul 13 06:53:38 2009 Return-Path: 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 5589C28C429 for ; Mon, 13 Jul 2009 06:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 O-P+9x0iQfb1 for ; Mon, 13 Jul 2009 06:53:37 -0700 (PDT) Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [198.117.1.122]) by core3.amsl.com (Postfix) with ESMTP id 9C15E28C316 for ; Mon, 13 Jul 2009 06:53:37 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 134D1A8124; Mon, 13 Jul 2009 08:54:01 -0500 (CDT) Received: from ndjshub03.ndc.nasa.gov (ndjshub03.ndc.nasa.gov [198.117.4.162]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n6DDs0Ze011837; Mon, 13 Jul 2009 08:54:01 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub03.ndc.nasa.gov ([198.117.4.162]) with mapi; Mon, 13 Jul 2009 08:54:01 -0500 From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" To: "tcpm@ietf.org" Date: Mon, 13 Jul 2009 08:54:00 -0500 Thread-Topic: draft agenda for TCPM @ IETF 75 Thread-Index: AcoDwV/DNTZgLAdwRHGWyJg4hyMqOg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-07-13_06:2009-07-03, 2009-07-13, 2009-07-13 signatures=0 Subject: [tcpm] draft agenda for TCPM @ IETF 75 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: , X-List-Received-Date: Mon, 13 Jul 2009 13:53:38 -0000 I've uploaded a draft TCPM agenda for IETF 75 at: http://www.ietf.org/proceedings/09jul/agenda/tcpm.txt I don't recall seeing an I-D or mail list thread for the topic Jerry Chu wants to discuss (lowering the initial RTO), so if he can give the mail list a bit of a description of his proposal that would be helpful. --------------------------- Wes Eddy Network & Systems Architect Verizon FNS / NASA GRC Office: (216) 433-6682 --------------------------- From alexander.zimmermann@nets.rwth-aachen.de Mon Jul 13 13:43:14 2009 Return-Path: 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 3882B28C26E for ; Mon, 13 Jul 2009 13:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 IBugWO7+pI56 for ; Mon, 13 Jul 2009 13:43:13 -0700 (PDT) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 42A8C3A6A16 for ; Mon, 13 Jul 2009 13:43:13 -0700 (PDT) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KMQ00H7MMWF6130@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Mon, 13 Jul 2009 22:43:27 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.42,392,1243807200"; d="sig'?scan'208";a="18917839" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Mon, 13 Jul 2009 22:43:26 +0200 Received: from miami.zimmermann.eu.xx ([unknown] [213.219.151.118]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0KMQ009Y7MWESQ00@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Mon, 13 Jul 2009 22:43:27 +0200 (CEST) Message-id: <3A6B38C4-17F7-46CD-B75C-A502FBE08183@nets.rwth-aachen.de> From: Alexander Zimmermann To: tcpm@ietf.org Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-2-775150375 Content-transfer-encoding: 7bit Date: Mon, 13 Jul 2009 22:43:26 +0200 X-Pgp-Agent: GPGMail 1.2.0 (v56) X-Mailer: Apple Mail (2.935.3) Cc: David Borman Subject: [tcpm] New Version Notification for draft-zimmermann-tcp-lcd-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: , X-List-Received-Date: Mon, 13 Jul 2009 20:43:14 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-2-775150375 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Hi folks, I upload a new version of our draft to the IETF repository: http://www.ietf.org/internet-drafts/draft-zimmermann-tcp-lcd-01.txt Comments are more than welcome. I'm looking forward to seeing you in Stockholm. Alex Filename: draft-zimmermann-tcp-lcd Revision: 01 Title: Make TCP more Robust to Long Connectivity Disruptions Creation_date: 2009-07-13 WG ID: Independent Submission Number_of_pages: 16 Abstract: Disruptions in end-to-end path connectivity which last longer than one retransmission timeout cause suboptimal TCP performance. The reason for the performance degradation is that TCP interprets segment loss induced by connectivity disruptions as a sign of congestion, resulting in repeated backoffs of the retransmission timer. This leads in turn to a deferred detection of the re-establishment of the connection since TCP waits until the next retransmission timeout occurs before attempting the retransmission. This document describes how standard ICMP messages can be exploited to disambiguate true congestion loss from non-congestion loss caused by long connectivity disruptions. Moreover, a revert strategy of the retransmission timer is specified that enables a more prompt detection of whether the connectivity to a previously disconnected peer node has been restored or not. The specified algorithm is a TCP sender-only modification that effectively improves TCP performance in presence of connectivity disruptions. --Apple-Mail-2-775150375 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: Signierter Teil der Nachricht content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkpbnG4ACgkQdyiq39b9uS7W9ACg2Rb5NilPqAUjLpjE1jp1O4nT QRMAn2GU9GFtc+ZsCifPqme/EfrJQv/w =uDoz -----END PGP SIGNATURE----- --Apple-Mail-2-775150375-- From touch@ISI.EDU Mon Jul 13 13:58:05 2009 Return-Path: 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 62FB328C36F for ; Mon, 13 Jul 2009 13:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 fFFlP02TtWaO for ; Mon, 13 Jul 2009 13:58:04 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 6E98E28C4BE for ; Mon, 13 Jul 2009 13:58:04 -0700 (PDT) Received: from [75.217.188.140] (140.sub-75-217-188.myvzw.com [75.217.188.140]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n6DKwKWJ003549; Mon, 13 Jul 2009 13:58:22 -0700 (PDT) Message-ID: <4A5B9FEB.6080706@isi.edu> Date: Mon, 13 Jul 2009 13:58:19 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: tcpm Extensions WG X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: [tcpm] possible NAT support for TCP-AO 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: , X-List-Received-Date: Mon, 13 Jul 2009 20:58:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, all, Based on a discussion on a different list with Dan Wing, I'd like to revisit thinking about NATs in the context of the current AO, which uses traffic keys derived from the socket pair and ISN pair. We might be able to now support NATs as follows, e.g.: add the following flags to the MKT: localNAT flag - indicates whether the local IP/port are zeroed before MAC calculation remoteNAT flag - indicates whether the remote IP/port are zeroed before MAC calculation add steps to the incoming/outgoing processing: zero the corresponding IP/port when the flag indicates, both on outgoing and incoming MAC calculation That's basically it. A client behind a NAT would have a MKT with localNAT true, and a server for that client would need to have a MKT with remoteNAT true. This does require careful MKT configuration. Although I wouldn't expect both localNAT and remoteNAT to be true, there isn't a particular reason it needs to be prohibited. Here's the security impact: - no impact to other connections (AFAICT) - SYN/SYN-ACKs limited only as much as the MKT TCP connection ID is, i.e., as a small range or single value rather than wildcard for either address or port - connections are reasonably well-protected once established, much like BTNS (due to use of both ISNs in the traffic keys) - reduced entropy for the traffic keys from a given MKT, since their input could be limited to the ISN pair in the worst case I did NOT include this in TCP-AO-05, but it's simple enough to add if useful. I'd like to ask that we think about this before Stockholm, and discuss it on the list if possible in advance. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpbn+sACgkQE5f5cImnZru8uwCeLaty+1z8+Qnrzg8L3G82SFO0 4WEAoJ00Ww9omlO9ggb58lW064tDMqxl =3Z2o -----END PGP SIGNATURE----- From root@core3.amsl.com Mon Jul 13 15:45:02 2009 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 32B423A6B4E; Mon, 13 Jul 2009 15:45: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: <20090713224502.32B423A6B4E@core3.amsl.com> Date: Mon, 13 Jul 2009 15:45:02 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcpmss-01.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: , X-List-Received-Date: Mon, 13 Jul 2009 22:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : TCP Options and MSS Author(s) : D. Borman Filename : draft-ietf-tcpm-tcpmss-01.txt Pages : 3 Date : 2009-07-13 This memo discusses what value to use with the TCP MSS option. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpmss-01.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-tcpmss-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-13154354.I-D@ietf.org> --NextPart-- From david.borman@windriver.com Mon Jul 13 15:55:45 2009 Return-Path: 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 54E523A694D for ; Mon, 13 Jul 2009 15:55:45 -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 rV0CyK0O0iEH for ; Mon, 13 Jul 2009 15:55:44 -0700 (PDT) Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id AFDFD3A68D5 for ; Mon, 13 Jul 2009 15:55:44 -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 n6DMuFb5005988 for ; Mon, 13 Jul 2009 15:56:15 -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); Mon, 13 Jul 2009 15:56:15 -0700 Received: from [172.25.44.6] ([172.25.44.6]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Jul 2009 15:56:15 -0700 Message-Id: <9FDF7896-0ECC-4FA4-AE6F-3649725A35BE@windriver.com> From: David Borman To: tcpm@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 13 Jul 2009 17:56:13 -0500 X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 13 Jul 2009 22:56:15.0750 (UTC) FILETIME=[205C8260:01CA040D] Subject: [tcpm] TCP MSS draft update 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: , X-List-Received-Date: Mon, 13 Jul 2009 22:55:45 -0000 Hi, I've just posted an update to the TCP MSS draft. I made a mistake and posted a -01 version that didn't have the change, and so I had to follow it with a -02 version that has the actual change. The change was to add a reference to the original e-mail on the TCP Large Windows mailing list where this information was first posted. I believe that was the only change request that came out of the last IETF meeting. It's a pretty simple document and I think it is ready for last call, so please speak up if you disagree. -David From root@core3.amsl.com Mon Jul 13 16:00:01 2009 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4C25B28C0FE; Mon, 13 Jul 2009 16:00:00 -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: <20090713230001.4C25B28C0FE@core3.amsl.com> Date: Mon, 13 Jul 2009 16:00:01 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcpmss-02.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: , X-List-Received-Date: Mon, 13 Jul 2009 23:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : TCP Options and MSS Author(s) : D. Borman Filename : draft-ietf-tcpm-tcpmss-02.txt Pages : 3 Date : 2009-07-13 This memo discusses what value to use with the TCP MSS option. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpmss-02.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-tcpmss-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-13155430.I-D@ietf.org> --NextPart-- From rbonica@juniper.net Mon Jul 13 16:02:02 2009 Return-Path: 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 E5D693A6E62 for ; Mon, 13 Jul 2009 16:02:02 -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 MkIYAcgOAzRd for ; Mon, 13 Jul 2009 16:02:02 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id 1E67C3A6C51 for ; Mon, 13 Jul 2009 16:02:00 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKSlu9A+KPc1ZJlcRIcWPcKE4YHSfItRNT@postini.com; Mon, 13 Jul 2009 16:02:31 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 13 Jul 2009 15:59:46 -0700 Received: from [172.28.134.11] (172.28.134.11) by p-emfe01-wf.jnpr.net (172.28.145.22) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 13 Jul 2009 18:59:45 -0400 Message-ID: <4A5BBC5E.8030600@juniper.net> Date: Mon, 13 Jul 2009 18:59:42 -0400 From: Ron Bonica User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Joe Touch References: <4A5B9FEB.6080706@isi.edu> In-Reply-To: <4A5B9FEB.6080706@isi.edu> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: tcpm Extensions WG Subject: Re: [tcpm] possible NAT support for TCP-AO 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: , X-List-Received-Date: Mon, 13 Jul 2009 23:02:03 -0000 Joe, If TCP-AO were for the exclusive use of BGP, I wouldn't worry so much about NAT. Nobody (to the best of my knowlege) runs BGP across a NAT boundary. If TCP-AO is being designed for non-BGP applications also, the tweaks that Joe describes make perfect sense. They appear to be simple enough and shouldn't take too long to document. Ron Joe Touch wrote: > Hi, all, > > Based on a discussion on a different list with Dan Wing, I'd like to > revisit thinking about NATs in the context of the current AO, which uses > traffic keys derived from the socket pair and ISN pair. We might be able > to now support NATs as follows, e.g.: > > add the following flags to the MKT: > > localNAT flag - indicates whether the local IP/port are > zeroed before MAC calculation > > remoteNAT flag - indicates whether the remote IP/port > are zeroed before MAC calculation > > add steps to the incoming/outgoing processing: > zero the corresponding IP/port when the flag indicates, > both on outgoing and incoming MAC calculation > > That's basically it. A client behind a NAT would have a MKT with > localNAT true, and a server for that client would need to have a MKT > with remoteNAT true. This does require careful MKT configuration. > Although I wouldn't expect both localNAT and remoteNAT to be true, there > isn't a particular reason it needs to be prohibited. > > Here's the security impact: > > - no impact to other connections (AFAICT) > > - SYN/SYN-ACKs limited only as much as the MKT TCP connection > ID is, i.e., as a small range or single value rather than > wildcard for either address or port > > - connections are reasonably well-protected once established, > much like BTNS (due to use of both ISNs in the traffic keys) > > - reduced entropy for the traffic keys from a given MKT, > since their input could be limited to the ISN pair in the > worst case > > I did NOT include this in TCP-AO-05, but it's simple enough to add if > useful. I'd like to ask that we think about this before Stockholm, and > discuss it on the list if possible in advance. > > Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm . From david.borman@windriver.com Mon Jul 13 16:12:02 2009 Return-Path: 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 F1EC028C3BA for ; Mon, 13 Jul 2009 16:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_35=0.6, 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 lLYRpkoFKoQv for ; Mon, 13 Jul 2009 16:12:02 -0700 (PDT) Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id 29A683A69A8 for ; Mon, 13 Jul 2009 16:12:01 -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 n6DNCW2U010831; Mon, 13 Jul 2009 16:12:32 -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); Mon, 13 Jul 2009 16:12:32 -0700 Received: from [172.25.44.6] ([172.25.44.6]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Jul 2009 16:12:32 -0700 Message-Id: <79C12B51-C0CE-47F9-A6EF-F61239D661B0@windriver.com> From: David Borman To: Alexander Zimmermann In-Reply-To: <1E6B7C58-4AE4-4B82-B110-F26D8F76F71B@nets.rwth-aachen.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 13 Jul 2009 18:12:30 -0500 References: <1E6B7C58-4AE4-4B82-B110-F26D8F76F71B@nets.rwth-aachen.de> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 13 Jul 2009 23:12:32.0947 (UTC) FILETIME=[66D0F030:01CA040F] Cc: tcpm@ietf.org Subject: Re: [tcpm] 1323bis - PAWS check's problem with reodering on the reverse path 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: , X-List-Received-Date: Mon, 13 Jul 2009 23:12:03 -0000 I've been thinking about this recently, and I think that while it may be a real issue, it's not one that we need to worry about. I believe that the problem that the change fixes is a more likely scenario, so if you have to choose between the two, that's the one to pick. Also, for this issue that Alexander brings up, the timestamp has to be changing between ACKs. If the timestamp hasn't changed between the re- ordered ACKs, then the "SEG.TSval >= TS.recent" check will succeed. Generally, the TS clock shouldn't be ticking that often, if it is changing with every ACK then it might be going faster than it needs to. So, this issue only occurs when ACKs are re-ordered, *and* the Timestamp clock has ticked between the reordered ACKs. I'm thinking that 1323bis should just note that this situation does exist. What does everyone else think? Shall we leave the text as is and just document this edge case, or do people disagree with me and feel that this is a real problem that needs to be addressed, and is more important than the problems that the original change fixes? -David On Mar 26, 2009, at 6:10 PM, Alexander Zimmermann wrote: > Hi David, hi TCPM Folks, > > in the 1323bis draft the PAWS check has a problem (discarding ACKs) > if reordering is present on the > reverse path and no data is piggybacked. Actually, it's not the PAWS > check itself, it's the modification > of section 3.4: "Which Timestamp to Echo". > > The important parts of the RFC1323 and the draft (in this order) are > > --- > (2) If Last.ACK.sent falls within the range of sequence numbers > of an incoming segment: > > SEG.SEQ <= Last.ACK.sent < SEG.SEQ + SEG.LEN > > then the TSval from the segment is copied to TS.Recent; > otherwise, the TSval is ignored. > > --- > > (2) If: > > SEG.TSval >= TS.recent and SEG.SEQ <= Last.ACK.sent > > then SEG.TSval is copied to TS.Recent; otherwise, it is > ignored. > --- > > The addition of "SEG.TSval >= TS.recent" is not important for us at > moment. As the appendix said, > this check is included for consistency with the PAWS test only. > > The relevant paragraph is the change from "SEG.SEQ <= Last.ACK.sent > < SEG.SEQ + SEG.LEN" to the > reduced form "SEG.SEQ <= Last.ACK.sent". Again, the appendix said > that this change was made > since the original algorithm to control which timestamp is echoed > was incorrect in two regards: > > (1) It failed to update TSrecent for a retransmitted segment that > resulted from a lost ACK. > > (2) It failed if SEG.LEN = 0. > > It's right that the 1323bis algo fix these two problems, however, > it's introduced the new problem mentioned > already above. > > Following situation: > - One-way flow from TCP A to TCP B > - Reordering on the reverse path > > Consequence > - TCP A will discard all ACKs with were delayed > - Harmful in the case ABC (RFC 3465) is off, since we count ACKs for > slow-start and congestion avoidance > > Examples are attached. > > Alex > > > // > // Dipl.-Inform. Alexander Zimmermann > // Department of Computer Science, Informatik 4 > // RWTH Aachen University > // Ahornstr. 55, 52056 Aachen, Germany > // phone: (49-241) 80-21422, fax: (49-241) 80-22220 > // email: zimmermann@cs.rwth-aachen.de > // web: http://www.umic-mesh.net > // > From hkchu@google.com Mon Jul 13 16:18:46 2009 Return-Path: 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 ED87B3A694D for ; Mon, 13 Jul 2009 16:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] 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 I+8pFlFf7x6x for ; Mon, 13 Jul 2009 16:18:46 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id E579D3A6E76 for ; Mon, 13 Jul 2009 16:18:40 -0700 (PDT) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id n6DNJ9nr027783 for ; Tue, 14 Jul 2009 00:19:10 +0100 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1247527150; bh=qW6Kb1npXCDNMUzWnOHF3slIp4c=; h=DomainKey-Signature:MIME-Version:Date:Message-ID:Subject:From:To: Content-Type:Content-Transfer-Encoding:X-System-Of-Record; b=qfYkd qrizQP3YYB8PCn34PTp3NHALq+95OPJ5WK8vn6PNTqn3Tz+WSKXHm0A1VLbSwZociv2 88/T6+4LRbDL2g== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:date:message-id:subject:from:to:content-type: content-transfer-encoding:x-system-of-record; b=sOpENdG1l01215g/4fyFpTXNlGg0oZrAPZ8IAPB5ATds1np8rVXrbWz3wyuo3l1lL L+Vh0c1qxl/Ybbizzszgg== Received: from yxe27 (yxe27.prod.google.com [10.190.2.27]) by wpaz17.hot.corp.google.com with ESMTP id n6DNJ7r9019480 for ; Mon, 13 Jul 2009 16:19:07 -0700 Received: by yxe27 with SMTP id 27so5871580yxe.0 for ; Mon, 13 Jul 2009 16:19:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.34.3 with SMTP id h3mr7915053anh.137.1247527147119; Mon, 13 Jul 2009 16:19:07 -0700 (PDT) Date: Mon, 13 Jul 2009 16:19:07 -0700 Message-ID: From: Jerry Chu To: "tcpm@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-System-Of-Record: true Subject: [tcpm] Tuning TCP parameters for the 21st century 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: , X-List-Received-Date: Mon, 13 Jul 2009 23:18:47 -0000 Sorry I don't have the I-D ready for submission yet (and the deadline has passed anyway) so I'll try to describe what we are up to below. I'll have more data to present in Stockholm. At Google we have embarked on a mission to make the web faster, not just for services provided by Google, but for every web user. We started with TCP because TCP performance has always been a key component of the end2end web performance. There are a number of default TCP parameter settings, that, although conservative, have served us well over the years. We believe the time has come to tune some of the parameters to get more speed out of a much faster Internet than 10-20 years ago. The current list includes: Lowering initRTO Increasing initcwnd Lowering minRTO Lowering delayed ack timer value I'll start with Lowering initRTO. RFC1122 contains the following paragraph: The following values SHOULD be used to initialize the estimation parameters for a new connection: (a) RTT = 0 seconds. (b) RTO = 3 seconds. (The smoothed variance is to be initialized to the value that will result in this RTO). The "3secs SHOULD" is reaffirmed in RFC2988. >From our own measurement of world wide RTT distribution to Google servers we believe 3secs is too conservative, and like to propose it to be reduced to 1sec. Why does it matter? We have seen SYN-ACK retransmission rates upto a few percentage points to some of our servers. We also have indirect data showing the SYN (client side) retransmission to be non-negligible (~1.42% worldwide). At a rate > 1% a large RTO value can have a significant negative impact on the average end2end latency, hence the user experience. This is especially true for short connections, including much of the web traffic. What's the downside? For those users behind a slow (e.g., dialup, wireless) link, the RTT may still go up to > 1 sec. We believe a small amount of supriously retransmitted SYN/SYN-ACK packets should not be a cause for concern (e.g., inducing more congestion,...) In some rare case the TCP performance may be negatively affected by false congestion backoff, resulted from dupacks caused by multiple spuriously retransmitted SYN/SYN-ACK packets. We believe there are techniques to detect and mitigate these cases. I'd like to hear feedback from this list on the feasibility of reducing initRTO. For some other items (e.g., increasing IW/RW...) unfortunately I don't have data ready to share yet but if you have an opinion on them I'd love to hear it too. Thanks, Jerry On Mon, Jul 13, 2009 at 6:54 AM, Eddy, Wesley M. (GRC-MS00)[Verizon] wrote: > > I've uploaded a draft TCPM agenda for IETF 75 at: > http://www.ietf.org/proceedings/09jul/agenda/tcpm.txt > > I don't recall seeing an I-D or mail list thread for > the topic Jerry Chu wants to discuss (lowering the > initial RTO), so if he can give the mail list a bit > of a description of his proposal that would be > helpful. > > --------------------------- > Wes Eddy > Network & Systems Architect > Verizon FNS / NASA GRC > Office: (216) 433-6682 > --------------------------- > From mahesh@cisco.com Mon Jul 13 22:38:22 2009 Return-Path: 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 B990B3A68B9 for ; Mon, 13 Jul 2009 22:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.961 X-Spam-Level: X-Spam-Status: No, score=-4.961 tagged_above=-999 required=5 tests=[AWL=1.638, 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 D6YGAtti6gVd for ; Mon, 13 Jul 2009 22:38:21 -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 CDFD73A67D9 for ; Mon, 13 Jul 2009 22:38:21 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFu2W0qrR7PD/2dsb2JhbAC2XIgjj0sFhAg X-IronPort-AV: E=Sophos;i="4.42,395,1243814400"; d="scan'208";a="213543389" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 14 Jul 2009 05:38:15 +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 n6E5cFHF029498 for ; Mon, 13 Jul 2009 22:38:15 -0700 Received: from [10.21.50.147] ([10.21.50.147]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6E5cFnh022950 for ; Tue, 14 Jul 2009 05:38:15 GMT Message-ID: <4A5C19C7.6040606@cisco.com> Date: Mon, 13 Jul 2009 22:38:15 -0700 From: Mahesh Jethanandani Organization: Cisco Systems Inc. User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=808; t=1247549895; x=1248413895; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mahesh@cisco.com; z=From:=20Mahesh=20Jethanandani=20 |Subject:=20New=20I-D=20posted=3A=20draft-ananth-tcpm-persi st |Sender:=20; bh=0WznrtCX3fZdQYxLj+ThpRTHbnwbCwZEJs7PQRE0hIM=; b=OxGEiGI0LDrnGTAH6SGcsj99AuQNTESERgotSay9rQJwhPd/MRXX9gbpn5 oyUx9MKB3sMJqemIiTtubP53I001c6BHQAEwtH29oAr17fGY5M8PPDpMc6Nl z+GwmIPHrZ; Authentication-Results: sj-dkim-3; header.From=mahesh@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [tcpm] New I-D posted: draft-ananth-tcpm-persist 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: , X-List-Received-Date: Tue, 14 Jul 2009 05:38:22 -0000 A revised version of the draft has been posted and can be viewed here. http://www.ietf.org/internet-drafts/draft-ananth-tcpm-persist-01.txt Filename: draft-ananth-tcpm-persist Revision: 01 Title: Clarification of sender behaviour in persist condition. Creation_date: 2009-07-10 WG ID: Independent Submission Number_of_pages: 11 Abstract: This document attempts to clarify the notion of the Zero Window Probes (ZWP) described in RFC 1122 [RFC1122]. In particular, it clarifies the actions that can be taken on connections which are experiencing the ZWP condition. The motivation for this document stems from the belief that TCP implementations strictly adhering to the current RFC language have the potential to become vulnerable to Denial of Service (DoS) scenarios. -- mj From erik.nordmark@sun.com Tue Jul 14 02:46:58 2009 Return-Path: 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 ACEA43A6EA1 for ; Tue, 14 Jul 2009 02:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.419 X-Spam-Level: X-Spam-Status: No, score=-5.419 tagged_above=-999 required=5 tests=[AWL=0.627, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 r4je4Ln2Wc7t for ; Tue, 14 Jul 2009 02:46:58 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id D49B23A6E5A for ; Tue, 14 Jul 2009 02:46:57 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6E9kwso000817; Tue, 14 Jul 2009 09:46:58 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n6E9kt9Q360004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Jul 2009 02:46:57 -0700 (PDT) Message-ID: <4A5C540E.9070104@sun.com> Date: Tue, 14 Jul 2009 11:46:54 +0200 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: Jerry Chu References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Tuning TCP parameters for the 21st century 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: , X-List-Received-Date: Tue, 14 Jul 2009 09:46:58 -0000 Jerry Chu wrote: > From our own measurement of world wide RTT distribution to Google servers > we believe 3secs is too conservative, and like to propose it to be reduced > to 1sec. > > Why does it matter? > > We have seen SYN-ACK retransmission rates upto a few percentage points to > some of our servers. We also have indirect data showing the SYN (client > side) retransmission to be non-negligible (~1.42% worldwide). At a rate > > 1% a large RTO value can have a significant negative impact on the average > end2end latency, hence the user experience. This is especially true for > short connections, including much of the web traffic. For short web traffic I'd assume many of the connections go to a server with which the client has recently had a tcp connection. What would be the pros and cons of using the cached rtt measurements from previous connections for the SYN? Erik From touch@ISI.EDU Tue Jul 14 07:16:27 2009 Return-Path: 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 C07CE3A6EB7 for ; Tue, 14 Jul 2009 07:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 zTby7VGStqOF for ; Tue, 14 Jul 2009 07:16:26 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id CCD2B3A67A4 for ; Tue, 14 Jul 2009 07:16:26 -0700 (PDT) Received: from [192.168.1.45] (pool-71-105-84-152.lsanca.dsl-w.verizon.net [71.105.84.152]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n6EEFbOM026131; Tue, 14 Jul 2009 07:15:39 -0700 (PDT) Message-ID: <4A5C9309.8030704@isi.edu> Date: Tue, 14 Jul 2009 07:15:37 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Erik Nordmark References: <4A5C540E.9070104@sun.com> In-Reply-To: <4A5C540E.9070104@sun.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Tuning TCP parameters for the 21st century 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: , X-List-Received-Date: Tue, 14 Jul 2009 14:16:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Erik Nordmark wrote: > Jerry Chu wrote: > >> From our own measurement of world wide RTT distribution to Google servers >> we believe 3secs is too conservative, and like to propose it to be >> reduced >> to 1sec. >> >> Why does it matter? >> >> We have seen SYN-ACK retransmission rates upto a few percentage points to >> some of our servers. We also have indirect data showing the SYN (client >> side) retransmission to be non-negligible (~1.42% worldwide). At a rate > >> 1% a large RTO value can have a significant negative impact on the >> average >> end2end latency, hence the user experience. This is especially true for >> short connections, including much of the web traffic. > > For short web traffic I'd assume many of the connections go to a server > with which the client has recently had a tcp connection. > > What would be the pros and cons of using the cached rtt measurements > from previous connections for the SYN You can use more than cached RTT; the technique and some other cacheable items are described in RFC2140. The pro is more rapid convergence to an accurate RTT; the con is that you're using a potentially invalid RTT, but then that's what you do when you start without knowing the RTT at all anyway. It has also been implemented in Linux; see RFC4614. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpckwkACgkQE5f5cImnZruYrQCgkCe/wm7W4F78Iy9K5gEcMtj5 xekAoMbbvAXZA230zsKCxsdy3toZA+1N =o0dt -----END PGP SIGNATURE----- From hkchu@google.com Tue Jul 14 12:28:32 2009 Return-Path: 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 58BAE3A68C7 for ; Tue, 14 Jul 2009 12:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] 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 kIOBHLXoHMaI for ; Tue, 14 Jul 2009 12:28:31 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 1FD453A6875 for ; Tue, 14 Jul 2009 12:28:30 -0700 (PDT) Received: from spaceape24.eur.corp.google.com (spaceape24.eur.corp.google.com [172.28.16.76]) by smtp-out.google.com with ESMTP id n6EItxxD024180 for ; Tue, 14 Jul 2009 19:56:00 +0100 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1247597760; bh=/gJKyehb9TmRF571HQbqGoWyzQo=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type: Content-Transfer-Encoding:X-System-Of-Record; b=opWaDNOgpzH37aSwca GwvJvnxZMnUu7AoI5jy0r5Vj/a55+yTKVS8BIph1FyruDSa5JPEUKox2T7f1saOJPWu w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=VuMSkZn0LnAImDhOcOIAXLLnkC9dVGlcN3WaeSYxCzVjG7ZgA5IWr9v8Biph2Bz/d NUIwk/MsJrZyeVf/sCRbg== Received: from yxe28 (yxe28.prod.google.com [10.190.2.28]) by spaceape24.eur.corp.google.com with ESMTP id n6EItlxs024257 for ; Tue, 14 Jul 2009 11:55:57 -0700 Received: by yxe28 with SMTP id 28so2280975yxe.10 for ; Tue, 14 Jul 2009 11:55:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.127.2 with SMTP id z2mr8933655anc.75.1247597757158; Tue, 14 Jul 2009 11:55:57 -0700 (PDT) In-Reply-To: <4A5C540E.9070104@sun.com> References: <4A5C540E.9070104@sun.com> Date: Tue, 14 Jul 2009 11:55:57 -0700 Message-ID: From: Jerry Chu To: Erik Nordmark Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Tuning TCP parameters for the 21st century 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: , X-List-Received-Date: Tue, 14 Jul 2009 19:28:32 -0000 Hi Erik, It's good to hear from you! On Tue, Jul 14, 2009 at 2:46 AM, Erik Nordmark wrote= : > Jerry Chu wrote: > >> From our own measurement of world wide RTT distribution to Google server= s >> we believe 3secs is too conservative, and like to propose it to be reduc= ed >> to 1sec. > >> >> >> Why does it matter? >> >> We have seen SYN-ACK retransmission rates upto a few percentage points t= o >> some of our servers. We also have indirect data showing the SYN (client >> side) retransmission to be non-negligible (~1.42% worldwide). At a rate = > >> 1% a large RTO value can have a significant negative impact on the avera= ge >> end2end latency, hence the user experience. This is especially true for >> short connections, including much of the web traffic. > > For short web traffic I'd assume many of the connections go to a server w= ith > which the client has recently had a tcp connection. > > What would be the pros and cons of using the cached rtt measurements from > previous connections for the SYN? Yes this is one of the things we've experiemented with. How effective the c= ache will depend on how much cache hit and the numbers for us were not very good= . Also Linux dst cache has some implementation/performance issues. In order to increase the effectiveness of the cache, we're experiementing w= ith a cache based on /24 (or some other prefix length) rather than individual dest IP addr. Note that most likely whatever scheme that may work for the server side won't work for the client side but we'd like to see the client side (SYN) to speed up as well, hence the proposal to reduce initRTO. Hope to see you at Stockholm! Jerry > > =A0 Erik > From touch@ISI.EDU Tue Jul 14 13:01:57 2009 Return-Path: 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 2B72E3A689E for ; Tue, 14 Jul 2009 13:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 wXjdC3r6EIgo for ; Tue, 14 Jul 2009 13:01:56 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 254903A6868 for ; Tue, 14 Jul 2009 13:01:56 -0700 (PDT) Received: from [75.217.96.194] (194.sub-75-217-96.myvzw.com [75.217.96.194]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n6EK0GBI024820; Tue, 14 Jul 2009 13:00:20 -0700 (PDT) Message-ID: <4A5CE3D0.5000904@isi.edu> Date: Tue, 14 Jul 2009 13:00:16 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Jerry Chu References: <4A5C540E.9070104@sun.com> <4A5C9309.8030704@isi.edu> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Tuning TCP parameters for the 21st century 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: , X-List-Received-Date: Tue, 14 Jul 2009 20:01:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ... >>> >> What would be the pros and cons of using the cached rtt measurements >>> >> from previous connections for the SYN >> > >> > You can use more than cached RTT; the technique and some other cacheable >> > items are described in RFC2140. > > Yes we are very aware of your proposal. I think the most effective one to speed > up short connections is the snd_cwnd reuse, but unfortunately it's also the most > dicey due to cwnd's highly temporal nature. Is this why snd_cwnd reuse was not > implemented per rfc2140? Any insight and suggestion will be much appreciated. We didn't distribute our implementations; the Linux code was developed separately. We did do some tests using predictive SND_CWND learning. There are two parts; one is "how fast would a connection speed up if guessing were perfect", and the other is "how close to that perfect goal can be achieved using basic prediction". Granted, our web server didn't have your traffic, but we found that the impact of SND_CWND was small, and limited to only a small subset of connections. Connections too short don't benefit from a large window. Connections too long have little benefit from increasing startup behavior. (see the tech report at http://www.isi.edu/aln) >> > The pro is more rapid convergence to an accurate RTT; the con is that >> > you're using a potentially invalid RTT, but then that's what you do when >> > you start without knowing the RTT at all anyway. >> > >> > It has also been implemented in Linux; see RFC4614. > > Yes Linux stack maintains a "destination cache" of ssthresh and RTT on > a per dest IP address basis. It doesn't currently use snd_cwnd, probably > out of the same concerned mentioned above? Lack of benefit is also an issue. > Also it is very conservative > hence won't use the cached RTT value unless the timestamp option is > on. > > Also the dst cache is only consulted after 3WHS. So for SYN/SYN-ACK > the initRTO is still set to 3secs (don't know why). If you spin the initRTO down too far, you end up resending the SYN needlessly, no? Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpc49AACgkQE5f5cImnZruF5QCfc5BRj9np2yjizDIqOa+i09bT LsQAoMBPrr2dYErruJc0ED7s2hfCQztE =uouq -----END PGP SIGNATURE----- From hkchu@google.com Tue Jul 14 15:06:22 2009 Return-Path: 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 50F553A6D03 for ; Tue, 14 Jul 2009 15:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] 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 FYFw41OKYCDH for ; Tue, 14 Jul 2009 15:06:21 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 42A783A6F1C for ; Tue, 14 Jul 2009 15:05:41 -0700 (PDT) Received: from zps77.corp.google.com (zps77.corp.google.com [172.25.146.77]) by smtp-out.google.com with ESMTP id n6EJfj4t002598 for ; Tue, 14 Jul 2009 12:41:45 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1247600505; bh=Q4Q1pmXoaZYxnOkNMnSf3nxFdUI=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type: Content-Transfer-Encoding:X-System-Of-Record; b=CmIrfLLp3a20HWfF3N OIwVasYdOwRpK445l1/po8KxY8afw3pC74yTz+fB8FW+5jpqA+jjV5DRi1QzZAaf1sF w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=Fqk2nRHkS79X9Jw9MTfE3oOjYMmn1OIQenNbQTBQ88eXbrnpC87pn9VCO9jsDhadh EjHeCAb1WL9HC23Ni/OZQ== Received: from an-out-0708.google.com (ancc37.prod.google.com [10.100.29.37]) by zps77.corp.google.com with ESMTP id n6EJfcMR028879 for ; Tue, 14 Jul 2009 12:41:43 -0700 Received: by an-out-0708.google.com with SMTP id c37so1737909anc.43 for ; Tue, 14 Jul 2009 12:41:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.152.12 with SMTP id z12mr9016612and.96.1247600502804; Tue, 14 Jul 2009 12:41:42 -0700 (PDT) In-Reply-To: <4A5C9309.8030704@isi.edu> References: <4A5C540E.9070104@sun.com> <4A5C9309.8030704@isi.edu> Date: Tue, 14 Jul 2009 12:41:42 -0700 Message-ID: From: Jerry Chu To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-System-Of-Record: true Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Tuning TCP parameters for the 21st century 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: , X-List-Received-Date: Tue, 14 Jul 2009 22:06:22 -0000 On Tue, Jul 14, 2009 at 7:15 AM, Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Erik Nordmark wrote: >> Jerry Chu wrote: >> >>> From our own measurement of world wide RTT distribution to Google servers >>> we believe 3secs is too conservative, and like to propose it to be >>> reduced >>> to 1sec. >>> >>> Why does it matter? >>> >>> We have seen SYN-ACK retransmission rates upto a few percentage points to >>> some of our servers. We also have indirect data showing the SYN (client >>> side) retransmission to be non-negligible (~1.42% worldwide). At a rate > >>> 1% a large RTO value can have a significant negative impact on the >>> average >>> end2end latency, hence the user experience. This is especially true for >>> short connections, including much of the web traffic. >> >> For short web traffic I'd assume many of the connections go to a server >> with which the client has recently had a tcp connection. >> >> What would be the pros and cons of using the cached rtt measurements >> from previous connections for the SYN > > You can use more than cached RTT; the technique and some other cacheable > items are described in RFC2140. Yes we are very aware of your proposal. I think the most effective one to speed up short connections is the snd_cwnd reuse, but unfortunately it's also the most dicey due to cwnd's highly temporal nature. Is this why snd_cwnd reuse was not implemented per rfc2140? Any insight and suggestion will be much appreciated. > > The pro is more rapid convergence to an accurate RTT; the con is that > you're using a potentially invalid RTT, but then that's what you do when > you start without knowing the RTT at all anyway. > > It has also been implemented in Linux; see RFC4614. Yes Linux stack maintains a "destination cache" of ssthresh and RTT on a per dest IP address basis. It doesn't currently use snd_cwnd, probably out of the same concerned mentioned above? Also it is very conservative hence won't use the cached RTT value unless the timestamp option is on. Also the dst cache is only consulted after 3WHS. So for SYN/SYN-ACK the initRTO is still set to 3secs (don't know why). Jerry > > Joe > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkpckwkACgkQE5f5cImnZruYrQCgkCe/wm7W4F78Iy9K5gEcMtj5 > xekAoMbbvAXZA230zsKCxsdy3toZA+1N > =o0dt > -----END PGP SIGNATURE----- > From hkchu@google.com Tue Jul 14 15:32:24 2009 Return-Path: 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 C64823A6ABB for ; Tue, 14 Jul 2009 15:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] 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 T+i0CqEs-436 for ; Tue, 14 Jul 2009 15:32:23 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id B35E83A6868 for ; Tue, 14 Jul 2009 15:32:23 -0700 (PDT) Received: from spaceape12.eur.corp.google.com (spaceape12.eur.corp.google.com [172.28.16.146]) by smtp-out.google.com with ESMTP id n6EMWObt020370 for ; Tue, 14 Jul 2009 15:32:25 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1247610745; bh=ppwdm2Mwavk7hqVcbJvbE0NVOyM=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type: Content-Transfer-Encoding:X-System-Of-Record; b=LeYLrtEUVIP+F6Inf+ 4AjK5yGVxubZoIXcdXDSjy1QMdCqnWRaE14UwRMj5XoveiCI5njFM/2FhFjHo6JqXRG A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=Ye4um/aT0z9R6KxVSnup6bmYdJ6H/E5QrbaDEIqCuEB8YX+L6484SiS4pubpsolEQ WEtlQrgOKsGNKatyHrrYA== Received: from gxk21 (gxk21.prod.google.com [10.202.11.21]) by spaceape12.eur.corp.google.com with ESMTP id n6EMVntS006517 for ; Tue, 14 Jul 2009 15:32:22 -0700 Received: by gxk21 with SMTP id 21so5249871gxk.3 for ; Tue, 14 Jul 2009 15:32:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.95.11 with SMTP id s11mr9378334anb.112.1247610740642; Tue, 14 Jul 2009 15:32:20 -0700 (PDT) In-Reply-To: <4A5CE3D0.5000904@isi.edu> References: <4A5C540E.9070104@sun.com> <4A5C9309.8030704@isi.edu> <4A5CE3D0.5000904@isi.edu> Date: Tue, 14 Jul 2009 15:32:20 -0700 Message-ID: From: Jerry Chu To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-System-Of-Record: true Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Tuning TCP parameters for the 21st century 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: , X-List-Received-Date: Tue, 14 Jul 2009 22:32:24 -0000 On Tue, Jul 14, 2009 at 1:00 PM, Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > ... >>>> >> What would be the pros and cons of using the cached rtt measurements >>>> >> from previous connections for the SYN >>> > >>> > You can use more than cached RTT; the technique and some other cacheable >>> > items are described in RFC2140. >> >> Yes we are very aware of your proposal. I think the most effective one to speed >> up short connections is the snd_cwnd reuse, but unfortunately it's also the most >> dicey due to cwnd's highly temporal nature. Is this why snd_cwnd reuse was not >> implemented per rfc2140? Any insight and suggestion will be much appreciated. > > We didn't distribute our implementations; the Linux code was developed > separately. We did do some tests using predictive SND_CWND learning. > There are two parts; one is "how fast would a connection speed up if > guessing were perfect", and the other is "how close to that perfect goal > can be achieved using basic prediction". > > Granted, our web server didn't have your traffic, but we found that the > impact of SND_CWND was small, and limited to only a small subset of > connections. Connections too short don't benefit from a large window. > Connections too long have little benefit from increasing startup behavior. Hmm, your conclusion seems a bit counter-intuitive - for a typical web object of 5-8 pkts in size, starting with an initcwnd of 6, e.g., from the cache will require only half of the round trips to complete the http transaction compared to initcwnd = 3. > > (see the tech report at http://www.isi.edu/aln) > >>> > The pro is more rapid convergence to an accurate RTT; the con is that >>> > you're using a potentially invalid RTT, but then that's what you do when >>> > you start without knowing the RTT at all anyway. >>> > >>> > It has also been implemented in Linux; see RFC4614. >> >> Yes Linux stack maintains a "destination cache" of ssthresh and RTT on >> a per dest IP address basis. It doesn't currently use snd_cwnd, probably >> out of the same concerned mentioned above? > > Lack of benefit is also an issue. See above. I thought this should be the one that will give the largest beneift (in terms of latency reduction) for the web traffic, if done (i.e., predicted) correctly. > >> Also it is very conservative >> hence won't use the cached RTT value unless the timestamp option is >> on. >> >> Also the dst cache is only consulted after 3WHS. So for SYN/SYN-ACK >> the initRTO is still set to 3secs (don't know why). > > If you spin the initRTO down too far, you end up resending the SYN > needlessly, no? Correct so there is a fine line to walk. But if > 98% of all TCP connections experience RTT << 1 sec, it just seems too conservative to have a global initRTO == 3secs just to avoid spurious retransmission in the < 2% category. Jerry > > Joe > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkpc49AACgkQE5f5cImnZruF5QCfc5BRj9np2yjizDIqOa+i09bT > LsQAoMBPrr2dYErruJc0ED7s2hfCQztE > =uouq > -----END PGP SIGNATURE----- > From touch@ISI.EDU Tue Jul 14 16:05:40 2009 Return-Path: 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 530953A67FA for ; Tue, 14 Jul 2009 16:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 8m1NvVo4tpjJ for ; Tue, 14 Jul 2009 16:05:39 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 320BA3A677D for ; Tue, 14 Jul 2009 16:05:39 -0700 (PDT) Received: from [75.217.96.194] (194.sub-75-217-96.myvzw.com [75.217.96.194]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n6EN2gNK006295; Tue, 14 Jul 2009 16:02:48 -0700 (PDT) Message-ID: <4A5D0E8F.1040402@isi.edu> Date: Tue, 14 Jul 2009 16:02:39 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Jerry Chu References: <4A5C540E.9070104@sun.com> <4A5C9309.8030704@isi.edu> <4A5CE3D0.5000904@isi.edu> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Tuning TCP parameters for the 21st century 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: , X-List-Received-Date: Tue, 14 Jul 2009 23:05:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > On Tue, Jul 14, 2009 at 1:00 PM, Joe Touch wrote: ... >> > Granted, our web server didn't have your traffic, but we found that the >> > impact of SND_CWND was small, and limited to only a small subset of >> > connections. Connections too short don't benefit from a large window. >> > Connections too long have little benefit from increasing startup behavior. > > Hmm, your conclusion seems a bit counter-intuitive - for a typical web object > of 5-8 pkts in size, starting with an initcwnd of 6, e.g., from the cache will > require only half of the round trips to complete the http transaction compared > to initcwnd = 3. First, you get to send 4K or 4 packets (whichever is smaller) at the start of a connection anyway. Second, RTT is only a fraction of the overall delays experienced by a message. Finally, connections already eat 2 RTTs before you do anything to get a response, due to the SYN handshake followed by the request-response of HTTP. You might be eating a single RTT off of a 3-4 RTT exchange. Your RTTs may go down by 30-50%, but since they're not 100% of your delay, you end up benefitting only around 20% or so. Larger messages benefit as you open the window to burst the whole thing out. Here's a back of the envelope: # packets was RTTs: is RTTs: benefit 4 2 2 0% 10 3 2 33% 19 4 2 50% 32 5 2 60% 52 6 2 67% 82 7 2 71% Note though that at some point your SND_CWND will be opened only as far as the path allows, at which point sending more packets just takes more RTTs, so you start to lose. 90% of our max CWNDs were below 9K, which means we only saw benefits in the 20-30% range (i.e., the first two rows above). Sure, if you see CWNDs much larger, you might benefit from reusing old values... >> > (see the tech report at http://www.isi.edu/aln) >> > >>>>> >>> > The pro is more rapid convergence to an accurate RTT; the con is that >>>>> >>> > you're using a potentially invalid RTT, but then that's what you do when >>>>> >>> > you start without knowing the RTT at all anyway. >>>>> >>> > >>>>> >>> > It has also been implemented in Linux; see RFC4614. >>> >> >>> >> Yes Linux stack maintains a "destination cache" of ssthresh and RTT on >>> >> a per dest IP address basis. It doesn't currently use snd_cwnd, probably >>> >> out of the same concerned mentioned above? >> > >> > Lack of benefit is also an issue. > > See above. I thought this should be the one that will give the largest beneift > (in terms of latency reduction) for the web traffic, if done (i.e., > predicted) correctly. It would if most connections's max CWND was larger than 10, and if most connections sent more than 20 packets, but neither was the case for us. >>> >> Also it is very conservative >>> >> hence won't use the cached RTT value unless the timestamp option is >>> >> on. >>> >> >>> >> Also the dst cache is only consulted after 3WHS. So for SYN/SYN-ACK >>> >> the initRTO is still set to 3secs (don't know why). >> > >> > If you spin the initRTO down too far, you end up resending the SYN >> > needlessly, no? > > Correct so there is a fine line to walk. But if > 98% of all TCP connections > experience RTT << 1 sec, it just seems too conservative to have a global > initRTO == 3secs just to avoid spurious retransmission in the < 2% category. It doesn't matter much if 99.99% of connections wouldn't benefit from having the initRTO go off earlier anyway. That's the tradeoff. Don't know if it helps your case, though. Joe >> > Joe >> > >> > -----BEGIN PGP SIGNATURE----- >> > Version: GnuPG v1.4.9 (MingW32) >> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> > >> > iEYEARECAAYFAkpc49AACgkQE5f5cImnZruF5QCfc5BRj9np2yjizDIqOa+i09bT >> > LsQAoMBPrr2dYErruJc0ED7s2hfCQztE >> > =uouq >> > -----END PGP SIGNATURE----- >> > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpdDo4ACgkQE5f5cImnZrs3fwCfaOB3Ki+FKf1rrJP3kKfdxV2X D68AoKxBh/3C0Bh3MVZ8AniBoen9vuX/ =X+Od -----END PGP SIGNATURE----- From michael.scharf@ikr.uni-stuttgart.de Wed Jul 15 02:35:00 2009 Return-Path: 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 8F9473A67DD for ; Wed, 15 Jul 2009 02:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 7mCbQiyQ3eTR for ; Wed, 15 Jul 2009 02:34:59 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by core3.amsl.com (Postfix) with ESMTP id 809423A68B9 for ; Wed, 15 Jul 2009 02:34:59 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id D59B643A03; Wed, 15 Jul 2009 11:15:17 +0200 (CEST) Received: from ikr.uni-stuttgart.de (cnode02 [10.21.20.2]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with SMTP id BD8FABC07E; Wed, 15 Jul 2009 11:15:17 +0200 (CEST) Received: by ikr.uni-stuttgart.de (sSMTP sendmail emulation); Wed, 15 Jul 2009 11:15:17 +0200 Date: Wed, 15 Jul 2009 11:15:17 +0200 From: Michael Scharf To: Joe Touch Message-ID: <20090715091517.GA4763@ikr.uni-stuttgart.de> References: <4A5C540E.9070104@sun.com> <4A5C9309.8030704@isi.edu> <4A5CE3D0.5000904@isi.edu> <4A5D0E8F.1040402@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <4A5D0E8F.1040402@isi.edu> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Tuning TCP parameters for the 21st century 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: , X-List-Received-Date: Wed, 15 Jul 2009 09:35:00 -0000 On Tue, 14 Jul 2009 at 16:02:39, Joe Touch wrote: > Larger messages benefit as you open the window to burst the whole thing > out. Here's a back of the envelope: > > # packets was RTTs: is RTTs: benefit > 4 2 2 0% > 10 3 2 33% > 19 4 2 50% > 32 5 2 60% > 52 6 2 67% > 82 7 2 71% > > Note though that at some point your SND_CWND will be opened only as far > as the path allows, at which point sending more packets just takes more > RTTs, so you start to lose. 90% of our max CWNDs were below 9K, which > means we only saw benefits in the 20-30% range (i.e., the first two rows > above). Sure, if you see CWNDs much larger, you might benefit from > reusing old values... A large initial SND_CWND might not result in such a large benefit if the receiver still announces a small receive window (e. g., the Linux stack initially announces a receive window of about 6K only). This issue is documented in an (expired) ID: http://tools.ietf.org/html/draft-scharf-tcpm-flow-control-quick-start-00 An example for a limitation by the receive window can also be seen on slide 19 of http://www.ietf.org/proceedings/08nov/slides/iccrg-2.pdf Note that, at least in case of Linux, it is possible to mitigate this limitation by an ugly hack: The sender could ignore the announced receive window during the first RTT of the Slow-Start and optimistically send more data. As the receiver exponentially opens the receive window, the received packets are always within the current receive window - if the receiver does not run out of memory. But of course this hack violates RFC 793. BTW: My experiments with different fast startup schemes (with and without rate pacing) also show that the absolute benefit of a faster startup is small for many typical Internet workloads. Yet, applications that frequently transfer mid-sized amounts of data can indeed benefit. And since only few applications actually use a large initial SND_CWND, the risk of a moderate increase of the initial window appears to be rather small. As also mentioned in my ICCRG presentation, the "Jump-Start" idea of M. Allman et al. seems to have a quite reasonable performance in many scenarios. Unfortunately, I cannot back these statements by large-scale experimental data so far. But if someone wanted to perform some experiments, e. g., with the "Jump-Start" scheme, I could provide corresponding Linux kernel patches. Michael From touch@ISI.EDU Wed Jul 15 07:34:43 2009 Return-Path: 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 396A73A6B43 for ; Wed, 15 Jul 2009 07:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, 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 iP-43NWSsj7q for ; Wed, 15 Jul 2009 07:34:42 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 751DE3A6947 for ; Wed, 15 Jul 2009 07:34:42 -0700 (PDT) Received: from [192.168.1.45] (pool-71-105-84-152.lsanca.dsl-w.verizon.net [71.105.84.152]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n6FEP32T002143; Wed, 15 Jul 2009 07:25:05 -0700 (PDT) Message-ID: <4A5DE6BC.3090904@isi.edu> Date: Wed, 15 Jul 2009 07:25:00 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Jerry Chu References: <4A5C540E.9070104@sun.com> <4A5C9309.8030704@isi.edu> <4A5CE3D0.5000904@isi.edu> <4A5D0E8F.1040402@isi.edu> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Tuning TCP parameters for the 21st century 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: , X-List-Received-Date: Wed, 15 Jul 2009 14:34:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jerry Chu wrote: ... >> We're taking one more look at T/TCP as well (probably need to start a different >> mail thread on T/TCP too). T/TCP is deprecated due to a fairly large security issue that has not been solved, AFAIK. It'd be useful to have a solution to that issue before proceeding with it as an approach. ... >> The SYN/SYN-ACK retransmission rate we measured turned out to be >> 1% >> in many cases (a bit surprising to us) hence the benefit. That points to some other problem going on. As a packet loss rate, that's quite high and causes problems elsewhere in TCP. It would be useful to understand where the drops are and why. Retransmitting SYNs to a busy endpoint whose queue is overflowing doesn't help things, e.g. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpd5rwACgkQE5f5cImnZrslfgCfVmHxe6fxfD7nCq/S5mn8S0Bt mwMAnRZPyVGbsvU9x6G1M+hbbR0AnCGn =Kghy -----END PGP SIGNATURE----- From michawe@ulrik.uio.no Wed Jul 15 08:58:19 2009 Return-Path: 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 6AADA3A69B3 for ; Wed, 15 Jul 2009 08:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.862 X-Spam-Level: X-Spam-Status: No, score=-5.862 tagged_above=-999 required=5 tests=[AWL=0.737, 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 sFr391GopENo for ; Wed, 15 Jul 2009 08:58:18 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [129.240.10.57]) by core3.amsl.com (Postfix) with ESMTP id F32453A6947 for ; Wed, 15 Jul 2009 08:58:17 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.47]) by mail-out1.uio.no with esmtp (Exim 4.69) (envelope-from ) id 1MR6rz-0003cI-BP for tcpm@ietf.org; Wed, 15 Jul 2009 17:58:11 +0200 Received: from w3prod-wm01.uio.no ([129.240.4.214] helo=webmail.uio.no) by mail-mx6.uio.no with esmtpsa (TLSv1:AES256-SHA:256) user michawe (Exim 4.69) (envelope-from ) id 1MR6ry-0007bj-Qo for tcpm@ietf.org; Wed, 15 Jul 2009 17:58:11 +0200 Received: from 84.48.218.182 (SquirrelMail authenticated user michawe) by webmail.uio.no with HTTP; Wed, 15 Jul 2009 17:58:10 +0200 Message-ID: <7261633966bb7a55cebd4ce313069082.squirrel@webmail.uio.no> In-Reply-To: <4A5DE6BC.3090904@isi.edu> References: <4A5C540E.9070104@sun.com> <4A5C9309.8030704@isi.edu> <4A5CE3D0.5000904@isi.edu> <4A5D0E8F.1040402@isi.edu> <4A5DE6BC.3090904@isi.edu> Date: Wed, 15 Jul 2009 17:58:10 +0200 From: michawe@ifi.uio.no To: tcpm@ietf.org User-Agent: SquirrelMail/1.4.19 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 3 sum rcpts/h 4 sum msgs/h 3 total rcpts 1912 max rcpts/h 33 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=_URIID_) X-UiO-Scanned: 788A1A8D130E05ACB6420073C0E099FCB5FF40C6 X-UiO-SPAM-Test: remote_host: 129.240.4.214 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 87 total 1503087 max/h 678 blacklist 0 greylist 0 ratelimit 0 Subject: Re: [tcpm] Tuning TCP parameters for the 21st century 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: , X-List-Received-Date: Wed, 15 Jul 2009 15:58:19 -0000 >>> The SYN/SYN-ACK retransmission rate we measured turned out to be >> 1% >>> in many cases (a bit surprising to us) hence the benefit. > > That points to some other problem going on. As a packet loss rate, > that's quite high and causes problems elsewhere in TCP. It would be It doesn't have to be a packet loss rate, maybe it was a per-connection measurement. We also found this to occur for > 0.5% of connections in our own measurement study: Dragana Damjanovic, Philipp Gschwandtner, Michael Welzl: "Why is this Web Page coming up so slow? Investigating the Loss of SYN Packets", IFIP/TC6 NETWORKING 2009, 11-15 May 2009, Aachen, Germany. http://www.welzl.at/research/publications/networking2009.pdf > useful to understand where the drops are and why. Retransmitting SYNs to > a busy endpoint whose queue is overflowing doesn't help things, e.g. I understand that now, too (thanks to Lachlan who explained it to me), and hence apologize for having been ignorant to this rather obvious issue in the above paper. - but what about retransmitting SYN/ACKs faster? Since the other side already sent a SYN, it probably isn't overloaded. Cheers, Michael From touch@ISI.EDU Wed Jul 15 09:21:17 2009 Return-Path: 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 DBD613A6947 for ; Wed, 15 Jul 2009 09:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 RhhM9lFgUuGb for ; Wed, 15 Jul 2009 09:21:16 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id E6F333A684E for ; Wed, 15 Jul 2009 09:21:16 -0700 (PDT) Received: from [75.213.22.4] (4.sub-75-213-22.myvzw.com [75.213.22.4]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n6FGJRpI028289; Wed, 15 Jul 2009 09:19:29 -0700 (PDT) Message-ID: <4A5E018C.8030604@isi.edu> Date: Wed, 15 Jul 2009 09:19:24 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: michawe@ifi.uio.no References: <4A5C540E.9070104@sun.com> <4A5C9309.8030704@isi.edu> <4A5CE3D0.5000904@isi.edu> <4A5D0E8F.1040402@isi.edu> <4A5DE6BC.3090904@isi.edu> <7261633966bb7a55cebd4ce313069082.squirrel@webmail.uio.no> In-Reply-To: <7261633966bb7a55cebd4ce313069082.squirrel@webmail.uio.no> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Tuning TCP parameters for the 21st century 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: , X-List-Received-Date: Wed, 15 Jul 2009 16:21:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 michawe@ifi.uio.no wrote: ... >> useful to understand where the drops are and why. Retransmitting SYNs to >> a busy endpoint whose queue is overflowing doesn't help things, e.g. > > I understand that now, too (thanks to Lachlan who > explained it to me), and hence apologize for having > been ignorant to this rather obvious issue in the > above paper. > > - but what about retransmitting SYN/ACKs faster? > Since the other side already sent a SYN, it probably > isn't overloaded That presumes the other side already sent a SYN and it's been received, and that the SYN/ACK is what's getting lost/delayed/retransmitted. If not, that won't help. First find where things are going wrong empirically ;-) Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpeAYwACgkQE5f5cImnZrs5gACgxI1iab37MoBAEz1VD3OVfbY8 p/kAoMDJH+/+jpuD4n3K2D8SlUnCR0dF =QMGk -----END PGP SIGNATURE----- From hkchu@google.com Wed Jul 15 09:51:11 2009 Return-Path: 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 810EF3A6BFF for ; Wed, 15 Jul 2009 09:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] 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 GpyJBRJ-zuTv for ; Wed, 15 Jul 2009 09:51:10 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 5825D3A6BD8 for ; Wed, 15 Jul 2009 09:51:10 -0700 (PDT) Received: from zps18.corp.google.com (zps18.corp.google.com [172.25.146.18]) by smtp-out.google.com with ESMTP id n6F0hkAp003842 for ; Tue, 14 Jul 2009 17:43:46 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1247618626; bh=RjV4UW4S+PM5YE0/YJyIGh+exOY=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type: Content-Transfer-Encoding:X-System-Of-Record; b=Pggexrtp6CRroZc3BC TLM7NlrF72x8gbLm34Z30dhAm6H1nuvdRVyKALy8RA2cNKjmWswe6QXOASQ5yH1zzqY g== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=Y+J2m+fyT/zbyN9WMeCuH0dnxf/tu3R6u9kusuEfXfQdx+jjTEUjtLeFtiL8jUU3B 9zMANdXNoySwH02wPBAOg== Received: from yxe40 (yxe40.prod.google.com [10.190.2.40]) by zps18.corp.google.com with ESMTP id n6F0hirp024394 for ; Tue, 14 Jul 2009 17:43:44 -0700 Received: by yxe40 with SMTP id 40so245763yxe.21 for ; Tue, 14 Jul 2009 17:43:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.32.13 with SMTP id f13mr9539883anf.36.1247618623936; Tue, 14 Jul 2009 17:43:43 -0700 (PDT) In-Reply-To: <4A5D0E8F.1040402@isi.edu> References: <4A5C540E.9070104@sun.com> <4A5C9309.8030704@isi.edu> <4A5CE3D0.5000904@isi.edu> <4A5D0E8F.1040402@isi.edu> Date: Tue, 14 Jul 2009 17:43:43 -0700 Message-ID: From: Jerry Chu To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Tuning TCP parameters for the 21st century 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: , X-List-Received-Date: Wed, 15 Jul 2009 16:51:11 -0000 On Tue, Jul 14, 2009 at 4:02 PM, Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > >> On Tue, Jul 14, 2009 at 1:00 PM, Joe Touch wrote: > ... >>> > Granted, our web server didn't have your traffic, but we found that t= he >>> > impact of SND_CWND was small, and limited to only a small subset of >>> > connections. Connections too short don't benefit from a large window. >>> > Connections too long have little benefit from increasing startup beha= vior. >> >> Hmm, your conclusion seems a bit counter-intuitive - for a typical web o= bject >> of 5-8 pkts in size, starting with an initcwnd of 6, e.g., from the cach= e will >> require only half of the round trips to complete the http transaction co= mpared >> to initcwnd =3D 3. > > First, you get to send 4K or 4 packets (whichever is smaller) at the > start of a connection anyway. Second, RTT is only a fraction of the > overall delays experienced by a message. Sure and we are looking at other layers (especially HTTP) for performance optimization as well. >Finally, connections already > eat 2 RTTs before you do anything to get a response, due to the SYN We're taking one more look at T/TCP as well (probably need to start a diffe= rent mail thread on T/TCP too). > handshake followed by the request-response of HTTP. You might be eating > a single RTT off of a 3-4 RTT exchange. Your RTTs may go down by 30-50%, > but since they're not 100% of your delay, you end up benefitting only > around 20% or so. > > Larger messages benefit as you open the window to burst the whole thing > out. Here's a back of the envelope: > > # packets =A0 =A0 =A0 was RTTs: =A0 =A0 =A0 is RTTs: =A0 =A0 =A0 =A0benef= it > =A0 =A0 =A0 =A04 =A0 =A0 =A0 2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 0% > =A0 =A0 =A0 =A010 =A0 =A0 =A03 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 33% > =A0 =A0 =A0 =A019 =A0 =A0 =A04 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 50% > =A0 =A0 =A0 =A032 =A0 =A0 =A05 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 60% > =A0 =A0 =A0 =A052 =A0 =A0 =A06 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 67% > =A0 =A0 =A0 =A082 =A0 =A0 =A07 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 71% > > Note though that at some point your SND_CWND will be opened only as far > as the path allows, at which point sending more packets just takes more > RTTs, so you start to lose. 90% of our max CWNDs were below 9K, which > means we only saw benefits in the 20-30% range (i.e., the first two rows > above). Sure, if you see CWNDs much larger, you might benefit from > reusing old values... Correct. We are trying to pilot our cache code and will find out our snd_cw= nd distribution, and how much it helps (or hurts if it triggers more pkt drops= ). > >>> > (see the tech report at http://www.isi.edu/aln) >>> > >>>>>> >>> > The pro is more rapid convergence to an accurate RTT; the con = is that >>>>>> >>> > you're using a potentially invalid RTT, but then that's what y= ou do when >>>>>> >>> > you start without knowing the RTT at all anyway. >>>>>> >>> > >>>>>> >>> > It has also been implemented in Linux; see RFC4614. >>>> >> >>>> >> Yes Linux stack maintains a "destination cache" of ssthresh and RTT= on >>>> >> a per dest IP address basis. It doesn't currently use snd_cwnd, pro= bably >>>> >> out of the same concerned mentioned above? >>> > >>> > Lack of benefit is also an issue. >> >> See above. I thought this should be the one that will give the largest b= eneift >> (in terms of latency reduction) for the web traffic, if done (i.e., >> predicted) correctly. > > It would if most connections's max CWND was larger than 10, and if most > connections sent more than 20 packets, but neither was the case for us. > >>>> >> Also it is very conservative >>>> >> hence won't use the cached RTT value unless the timestamp option is >>>> >> on. >>>> >> >>>> >> Also the dst cache is only consulted after 3WHS. So for SYN/SYN-ACK >>>> >> the initRTO is still set to 3secs (don't know why). >>> > >>> > If you spin the initRTO down too far, you end up resending the SYN >>> > needlessly, no? >> >> Correct so there is a fine line to walk. But if > 98% of all TCP connect= ions >> experience RTT << 1 sec, it just seems too conservative to have a global >> initRTO =3D=3D 3secs just to avoid spurious retransmission in the < 2% c= ategory. > > It doesn't matter much if 99.99% of connections wouldn't benefit from > having the initRTO go off earlier anyway. That's the tradeoff. Don't > know if it helps your case, though. The SYN/SYN-ACK retransmission rate we measured turned out to be >> 1% in many cases (a bit surprising to us) hence the benefit. Jerry > > Joe > >>> > Joe >>> > >>> > -----BEGIN PGP SIGNATURE----- >>> > Version: GnuPG v1.4.9 (MingW32) >>> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >>> > >>> > iEYEARECAAYFAkpc49AACgkQE5f5cImnZruF5QCfc5BRj9np2yjizDIqOa+i09bT >>> > LsQAoMBPrr2dYErruJc0ED7s2hfCQztE >>> > =3Duouq >>> > -----END PGP SIGNATURE----- >>> > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkpdDo4ACgkQE5f5cImnZrs3fwCfaOB3Ki+FKf1rrJP3kKfdxV2X > D68AoKxBh/3C0Bh3MVZ8AniBoen9vuX/ > =3DX+Od > -----END PGP SIGNATURE----- > From rpaulo@gmail.com Wed Jul 15 11:00:50 2009 Return-Path: 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 306A93A6BD8 for ; Wed, 15 Jul 2009 11:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_RECV_IP_082154=1.666] 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 QvOBSA+xn-S2 for ; Wed, 15 Jul 2009 11:00:49 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id 3FC023A6A6C for ; Wed, 15 Jul 2009 11:00:49 -0700 (PDT) Received: by ewy26 with SMTP id 26so4240998ewy.37 for ; Wed, 15 Jul 2009 10:59:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=ggs62jtzLdVFYkFlMjyLlGiol9egtYQNMJ6FuJFFFRA=; b=ecfVNXGGRYJcVbjPt1Ryjx4x3KKGcqYCvpR0Z4R9e9aDmf0izDjLWNfCmwMC9YDQc1 vWvDhdUP6+k+RqboZfIpqbXNlfbKHrr/H/ChO6OcGOMBrsVRyFvjqSBBX7A++JDY2T78 mWrW6S3zYuNV5FKgkkDaGO0lZx+KT+6UNuiTA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=bx2VupTLsNHxKj0TJiRFKe0G78rv2oUHAlKM5LhXtMxFkHg6VgF7EZDFEWjzDcO87Y SPcv2y5pd//wajNn5cX5p3MHVBLkpwblSWJQP9AjKhbZoK2DXpWEI5BWZGlehJ27FDK0 H/+vRtvwcPLtU9fQ/s9UAJyjlCnHdPZYD3+eE= Received: by 10.210.65.16 with SMTP id n16mr9616117eba.87.1247680787323; Wed, 15 Jul 2009 10:59:47 -0700 (PDT) Received: from epsilon.lan (bl6-159-228.dsl.telepac.pt [82.155.159.228]) by mx.google.com with ESMTPS id 5sm913294eyf.18.2009.07.15.10.59.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 15 Jul 2009 10:59:46 -0700 (PDT) Message-Id: From: Rui Paulo To: Joe Touch In-Reply-To: <4A5C9309.8030704@isi.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 15 Jul 2009 18:59:44 +0100 References: <4A5C540E.9070104@sun.com> <4A5C9309.8030704@isi.edu> X-Mailer: Apple Mail (2.935.3) Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Tuning TCP parameters for the 21st century 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: , X-List-Received-Date: Wed, 15 Jul 2009 18:00:50 -0000 On 14 Jul 2009, at 15:15, Joe Touch wrote: > It has also been implemented in Linux; see RFC4614. And FreeBSD, BTW. -- Rui Paulo From dwing@cisco.com Wed Jul 15 13:44:49 2009 Return-Path: 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 9C6CB28C0FA for ; Wed, 15 Jul 2009 13:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.482 X-Spam-Level: X-Spam-Status: No, score=-6.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 k09B43akkMIc for ; Wed, 15 Jul 2009 13:44:48 -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 917DA28C0F9 for ; Wed, 15 Jul 2009 13:44:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,406,1243814400"; d="scan'208";a="186456584" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 15 Jul 2009 20:44:10 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n6FKi9sI014474; Wed, 15 Jul 2009 13:44:09 -0700 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6FKi9qU027671; Wed, 15 Jul 2009 20:44:09 GMT From: "Dan Wing" To: , "'Eddy, Wesley M. \(GRC-MS00\)[Verizon]'" References: Date: Wed, 15 Jul 2009 13:44:09 -0700 Message-ID: <12fc01ca058d$01176b00$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acn+VxQfSK2YCQ5pQnWlLpzDfwi+3gHNdtoA DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2380; t=1247690650; x=1248554650; 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]=20poll=20for=20adopting=20draft- gont-tcp-security |Sender:=20; bh=CK/qIOzEnjbC1O0dpg0Xh6sqwioE8u8emR3mxFbleBE=; b=O7mVA1cLiR87DrYI9FqMtR3emODseLypVZ4s6LcF8kSShUT4ptFqBcMNKR RWdEXy9M9enVJBVy1KLwNZA987Frcb5Xqw02vKQA1t1OO4sz/5dOkkDaP7Y3 cLWC4PquM4; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: 'tcpm Extensions WG' Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security 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: , X-List-Received-Date: Wed, 15 Jul 2009 20:44:49 -0000 > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > Behalf Of Andrew Yourtchenko > Sent: Monday, July 06, 2009 9:31 AM > To: Eddy, Wesley M. (GRC-MS00)[Verizon] > Cc: tcpm Extensions WG > Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security > > > > On Wed, 24 Jun 2009, Eddy, Wesley M. (GRC-MS00)[Verizon] wrote: > > > TCPMers, there was a thread a while ago about working on > > draft-gont-tcp-security in this working group that didn't > > conclusively give us a feeling one way or other: > > http://www.ietf.org/mail-archive/web/tcpm/current/msg04489.html > > > > Basically, my understanding is that there are at least a > > handful of people in the WG that think it should be done > > here as a WG item (more likely for Informational rather > > than BCP), and there are also some expressed opinions on > > why it shouldn't. > > > > Given the raw size of the document, if the WG intends to > > take this document on, then we need some people to clearly > > commit to putting cycles into review and contributions to > > the document. Since it is quite large, and to my knowledge, > > there hasn't been a specific technical review of the content > > on this list, but just discussions about if the idea in > > general is a good or bad thing, we still need to know if > > people are willing to invest their time and energy in this. > > I think the further development of this document with the balanced > approach (cf: 'the requirements' mention and evaluating the > mitigations > with respect to them) is a useful activity, and as such, > would like to > commit cycles to it if it gets adopted. Agreed. And I will contribute cycles as well. -d > thanks, > andrew > > > > > Please let us know if there is traction for this in the > > near term, and/or we can also discuss it in Stockholm. > > > > --------------------------- > > Wes Eddy > > Network & Systems Architect > > Verizon FNS / NASA GRC > > Office: (216) 433-6682 > > --------------------------- > > > > _______________________________________________ > > 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 hkchu@google.com Wed Jul 15 15:27:10 2009 Return-Path: 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 B163C3A6F75 for ; Wed, 15 Jul 2009 15:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] 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 Ye9FriBLuKBq for ; Wed, 15 Jul 2009 15:27:09 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 175843A6BDD for ; Wed, 15 Jul 2009 15:27:08 -0700 (PDT) Received: from zps35.corp.google.com (zps35.corp.google.com [172.25.146.35]) by smtp-out.google.com with ESMTP id n6FLKJxT001970 for ; Wed, 15 Jul 2009 22:20:19 +0100 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1247692820; bh=o2SC50saBC+Ma3OHDFozIMYL1cM=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type: Content-Transfer-Encoding:X-System-Of-Record; b=kifwu5IJyDQvGS6DCX cr9V47Q3IBgh8vSw9LCByNr6YvmRqibdtn/iA6PQwPc/B8unPSUwMi0/TFmMDXsGWxq Q== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=Bxk/vD1ynk2w8/BdrRvUXGK6TswPTC5Ytw/qSbxru5vx/6bFN1rpAi/dX264FZlwg 9iEw0cp1n3d2lUAOtw2ng== Received: from an-out-0708.google.com (andd14.prod.google.com [10.100.30.14]) by zps35.corp.google.com with ESMTP id n6FLKFda019257 for ; Wed, 15 Jul 2009 14:20:16 -0700 Received: by an-out-0708.google.com with SMTP id d14so1950341and.13 for ; Wed, 15 Jul 2009 14:20:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.152.12 with SMTP id z12mr10719223and.96.1247692815404; Wed, 15 Jul 2009 14:20:15 -0700 (PDT) In-Reply-To: <4A5DE6BC.3090904@isi.edu> References: <4A5C540E.9070104@sun.com> <4A5C9309.8030704@isi.edu> <4A5CE3D0.5000904@isi.edu> <4A5D0E8F.1040402@isi.edu> <4A5DE6BC.3090904@isi.edu> Date: Wed, 15 Jul 2009 14:20:15 -0700 Message-ID: From: Jerry Chu To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-System-Of-Record: true Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Tuning TCP parameters for the 21st century 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: , X-List-Received-Date: Wed, 15 Jul 2009 22:27:10 -0000 On Wed, Jul 15, 2009 at 7:25 AM, Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Jerry Chu wrote: > ... >>> We're taking one more look at T/TCP as well (probably need to start a different >>> mail thread on T/TCP too). > > T/TCP is deprecated due to a fairly large security issue that has not > been solved, AFAIK. It'd be useful to have a solution to that issue > before proceeding with it as an approach. Understood. On the high level it seems to me a nonce/cookie exchanged over one reqular TCP connection (w/ 3WHS) upfront will always be required but should be sufficient to cover later T/TCP sessions and address the security concern? (Oh perhaps the cookie can be passed around by attackers to mount a DDOS attack?) > ... >>> The SYN/SYN-ACK retransmission rate we measured turned out to be >> 1% >>> in many cases (a bit surprising to us) hence the benefit. > > That points to some other problem going on. As a packet loss rate, > that's quite high and causes problems elsewhere in TCP. It would be > useful to understand where the drops are and why. Retransmitting SYNs to > a busy endpoint whose queue is overflowing doesn't help things, e.g. One set of our data show our TCP pkt rexmit rate ranges from 0.8% - 2.4% globally. Even at 1% drop rate 3secs is a noticeable bump for the average latency. Jerry > > Joe > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkpd5rwACgkQE5f5cImnZrslfgCfVmHxe6fxfD7nCq/S5mn8S0Bt > mwMAnRZPyVGbsvU9x6G1M+hbbR0AnCGn > =Kghy > -----END PGP SIGNATURE----- > From hkchu@google.com Wed Jul 15 15:34:45 2009 Return-Path: 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 339DD3A6F79 for ; Wed, 15 Jul 2009 15:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] 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 l2IM78JoEC9p for ; Wed, 15 Jul 2009 15:34:44 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id F28233A6F4A for ; Wed, 15 Jul 2009 15:34:17 -0700 (PDT) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id n6FMYMpQ026738 for ; Wed, 15 Jul 2009 23:34:22 +0100 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1247697262; bh=Q0zbP1O35YHKLD3//k/5iNvBQqU=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type: Content-Transfer-Encoding:X-System-Of-Record; b=NXPwR7PMX28YyxLCyF Id/lEF6z2zhDpyJ4SZLYbSKE7qFPfKxnlcTd9sDvVBvFzc5j1lVHoIny2b4JhUIzqbX w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=f+9MtCYZmU+84FisXad0vAEYXtl/huHp9beg9JBip6GYr5i4JRPv9pRYPoEKtHFSO EPN+C53SLZD1anRhzr2hA== Received: from an-out-0708.google.com (anab38.prod.google.com [10.100.53.38]) by wpaz13.hot.corp.google.com with ESMTP id n6FMYJLv021274 for ; Wed, 15 Jul 2009 15:34:19 -0700 Received: by an-out-0708.google.com with SMTP id b38so2510378ana.33 for ; Wed, 15 Jul 2009 15:34:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.3.6 with SMTP id 6mr11105946anc.33.1247697259416; Wed, 15 Jul 2009 15:34:19 -0700 (PDT) In-Reply-To: <20090715091517.GA4763@ikr.uni-stuttgart.de> References: <4A5C540E.9070104@sun.com> <4A5C9309.8030704@isi.edu> <4A5CE3D0.5000904@isi.edu> <4A5D0E8F.1040402@isi.edu> <20090715091517.GA4763@ikr.uni-stuttgart.de> Date: Wed, 15 Jul 2009 15:34:19 -0700 Message-ID: From: Jerry Chu To: Michael Scharf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] Tuning TCP parameters for the 21st century 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: , X-List-Received-Date: Wed, 15 Jul 2009 22:34:45 -0000 On Wed, Jul 15, 2009 at 2:15 AM, Michael Scharf wrote: > On Tue, 14 Jul 2009 at 16:02:39, Joe Touch wrote: >> Larger messages benefit as you open the window to burst the whole thing >> out. Here's a back of the envelope: >> >> # packets =A0 =A0 was RTTs: =A0 =A0 =A0 is RTTs: =A0 =A0 =A0 =A0benefit >> =A0 =A0 =A0 4 =A0 =A0 =A0 2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 0% >> =A0 =A0 =A0 10 =A0 =A0 =A03 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 33% >> =A0 =A0 =A0 19 =A0 =A0 =A04 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 50% >> =A0 =A0 =A0 32 =A0 =A0 =A05 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 60% >> =A0 =A0 =A0 52 =A0 =A0 =A06 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 67% >> =A0 =A0 =A0 82 =A0 =A0 =A07 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 71% >> >> Note though that at some point your SND_CWND will be opened only as far >> as the path allows, at which point sending more packets just takes more >> RTTs, so you start to lose. 90% of our max CWNDs were below 9K, which >> means we only saw benefits in the 20-30% range (i.e., the first two rows >> above). Sure, if you see CWNDs much larger, you might benefit from >> reusing old values... > > A large initial SND_CWND might not result in such a large benefit if > the receiver still announces a small receive window (e. g., the Linux > stack initially announces a receive window of about 6K only). This > issue is documented in an (expired) ID: > > =A0http://tools.ietf.org/html/draft-scharf-tcpm-flow-control-quick-start-= 00 Yes I remember Linux stack also "slow starts" the receive window. The good news is that for us the receiver is on the client side dominated b= y the Windows stack, which is probably not sophisticated enough to do this. (Need double check.) > > An example for a limitation by the receive window can also be seen on > slide 19 of > > =A0http://www.ietf.org/proceedings/08nov/slides/iccrg-2.pdf > > Note that, at least in case of Linux, it is possible to mitigate this > limitation by an ugly hack: The sender could ignore the announced > receive window during the first RTT of the Slow-Start and > optimistically send more data. As the receiver exponentially opens the > receive window, the received packets are always within the current > receive window - if the receiver does not run out of memory. But of > course this hack violates RFC 793. > > BTW: My experiments with different fast startup schemes (with and > without rate pacing) also show that the absolute benefit of a faster > startup is small for many typical Internet workloads. Yet, > applications that frequently transfer mid-sized amounts of data can > indeed benefit. And since only few applications actually use a large > initial SND_CWND, the risk of a moderate increase of the initial > window appears to be rather small. As also mentioned in my ICCRG > presentation, the "Jump-Start" idea of M. Allman et al. seems to have > a quite reasonable performance in many scenarios. Thanks for the pointers! This seems very relevant to our on-going struggle with TCP slow start :-). > > Unfortunately, I cannot back these statements by large-scale > experimental data so far. But if someone wanted to perform some > experiments, e. g., with the "Jump-Start" scheme, I could provide > corresponding Linux kernel patches. We're planning for some experiement in this area too. Will let you know how it goes. Jerry > > Michael > From touch@ISI.EDU Wed Jul 15 16:51:54 2009 Return-Path: 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 58CDA28C15D for ; Wed, 15 Jul 2009 16:51:54 -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 iQN9tqo+I33n for ; Wed, 15 Jul 2009 16:51:53 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 9706D3A68A2 for ; Wed, 15 Jul 2009 16:51:53 -0700 (PDT) Received: from [128.9.176.37] (c1-vpn7.isi.edu [128.9.176.37]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n6FNotOI018250; Wed, 15 Jul 2009 16:51:00 -0700 (PDT) Message-ID: <4A5E6B5E.3030706@isi.edu> Date: Wed, 15 Jul 2009 16:50:54 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Jerry Chu References: <4A5C540E.9070104@sun.com> <4A5C9309.8030704@isi.edu> <4A5CE3D0.5000904@isi.edu> <4A5D0E8F.1040402@isi.edu> <4A5DE6BC.3090904@isi.edu> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Tuning TCP parameters for the 21st century 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: , X-List-Received-Date: Wed, 15 Jul 2009 23:51:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jerry Chu wrote: > On Wed, Jul 15, 2009 at 7:25 AM, Joe Touch wrote: > > > Jerry Chu wrote: > ... >>>>> We're taking one more look at T/TCP as well (probably need to start a different >>>>> mail thread on T/TCP too). > T/TCP is deprecated due to a fairly large security issue that has not > been solved, AFAIK. It'd be useful to have a solution to that issue > before proceeding with it as an approach. > >> Understood. On the high level it seems to me a nonce/cookie exchanged >> over one reqular TCP connection (w/ 3WHS) upfront will always be required >> but should be sufficient to cover later T/TCP sessions and address the security >> concern? (Oh perhaps the cookie can be passed around by attackers to mount >> a DDOS attack?) Yeah - that's the problem. See http://www.mid-way.org/doc/ttcp-sec.txt Nonces are addressed in Sec 5, and there doesn't appear to be a solution. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpea14ACgkQE5f5cImnZrsBjwCfQG8mGxrOws5VsM7GKOhkLsqB QPoAoKGaYSQ12mS9z4Rb99az8+4JdIA6 =GLzC -----END PGP SIGNATURE----- From michawe@ifi.uio.no Thu Jul 16 01:39:25 2009 Return-Path: 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 38C163A6A17 for ; Thu, 16 Jul 2009 01:39: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 CkyYgJkw3IQ1 for ; Thu, 16 Jul 2009 01:39:24 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [129.240.10.58]) by core3.amsl.com (Postfix) with ESMTP id 6DF4C28C150 for ; Thu, 16 Jul 2009 01:39:06 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out2.uio.no with esmtp (Exim 4.69) (envelope-from ) id 1MRMV7-0006G6-Kt for tcpm@ietf.org; Thu, 16 Jul 2009 10:39:37 +0200 Received: from div-8021x-dhcp050.uio.no ([193.157.176.59]) by mail-mx3.uio.no with esmtp (Exim 4.69) (envelope-from ) id 1MRMV7-0000PD-AG for tcpm@ietf.org; Thu, 16 Jul 2009 10:39:37 +0200 From: Michael Welzl To: tcpm@ietf.org In-Reply-To: <4A5E018C.8030604@isi.edu> References: <4A5C540E.9070104@sun.com> <4A5C9309.8030704@isi.edu> <4A5CE3D0.5000904@isi.edu> <4A5D0E8F.1040402@isi.edu> <4A5DE6BC.3090904@isi.edu> <7261633966bb7a55cebd4ce313069082.squirrel@webmail.uio.no> <4A5E018C.8030604@isi.edu> Content-Type: text/plain Date: Thu, 16 Jul 2009 10:39:49 +0200 Message-Id: <1247733589.4184.56.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-10.fc7) Content-Transfer-Encoding: 7bit X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 1 sum msgs/h 1 total rcpts 1922 max rcpts/h 33 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=0.0, required=5.0, autolearn=disabled, none, uiobl=NO, uiouri=_URIID_) X-UiO-Scanned: D2667986F0AD802F0AC51879019E3ED1B500ED21 X-UiO-SPAM-Test: remote_host: 193.157.176.59 spam_score: 0 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 470 max/h 15 blacklist 0 greylist 0 ratelimit 0 Subject: Re: [tcpm] Tuning TCP parameters for the 21st century 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: , X-List-Received-Date: Thu, 16 Jul 2009 08:39:25 -0000 > > - but what about retransmitting SYN/ACKs faster? > > Since the other side already sent a SYN, it probably > > isn't overloaded > > That presumes the other side already sent a SYN and it's been received, > and that the SYN/ACK is what's getting lost/delayed/retransmitted. If > not, that won't help. Right - > First find where things are going wrong empirically ;-) We've done that. See, for example, fig. 2 (a) of http://www.welzl.at/research/publications/networking2009.pdf (page 7 of the pdf) Since our goal in this paper was to document general failures of connection setup, we did not strictly split our results into the case of lost SYNs or lost SYN/ACKs in it. Section 3 (end of page 3 / beginning of page 4) explains how lost SYN/ACKs were incorporated in our measurements. This paper is based on data produced by a student. The data are more thoroughly documented in his (alas, German) bachelor thesis. This document is here: http://www.welzl.at/research/tools/syn-retransmit/benjamin_kaser_bak1.pdf and the most relevant information is table 2 on page 47. (Table 1 is similar, just for SYNs, not SYN/ACKs). If you look at it, with or without German knowledge you will be able to see the connection to table 1 in the paper, where we exchanged columns with lines and omitted some details - apparently just the crucial ones :-( Anyway, the listed measurements are just the same, and hence you can read the details in the paper if you're interested in how we obtained our data. Table 2 on page 47 of the bachelor thesis has several details about duplicate SYN/ACKs that we've seen, e.g. classified by eventually successful and unsuccessful connections. As a quick summary, in 3432744 connection attempts, we have seen 56586 duplicate SYN/ACKs in total (this is a cumulative number, i.e. 4 SYN/ACKs are counted as 3). Counting only the occurrence of duplicate SYN/ACKs, we saw them for 0,55% of the 3432744 connection attempts. In general, the difference between duplicate SYN/ACK occurrences and duplicate SYN occurrences is negligible in our measurements. As I just looked at the data again, I noticed a mistake: in the paper, we wrote that the problem only happens for around 0.5% of the connections, but this is really only from the SYN table, not the SYN/ACK table in the bachelor thesis. The SYN/ACK table covers the same measurement sets. Hence, in total, it seems that we also saw > 1% lost SYNs *or* SYN/ACKs, which exactly matches what Jerry Chu said. BTW I maintain a small website about the whole thing: http://www.welzl.at/research/tools/syn-retransmit/index.html Cheers, Michael From hkchu@google.com Thu Jul 16 11:24:27 2009 Return-Path: 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 365DD3A6DB5 for ; Thu, 16 Jul 2009 11:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] 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+uwVXm4Ql79 for ; Thu, 16 Jul 2009 11:24:26 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 158913A6DAC for ; Thu, 16 Jul 2009 11:24:25 -0700 (PDT) Received: from zps18.corp.google.com (zps18.corp.google.com [172.25.146.18]) by smtp-out.google.com with ESMTP id n6GIOuUA011113 for ; Thu, 16 Jul 2009 19:24:57 +0100 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1247768697; bh=GnLmjGGNi+nlukpW5CLi5mhWLaQ=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type: Content-Transfer-Encoding:X-System-Of-Record; b=uTwREJQwV7mqBHbhYa QqgJLWmYSWzPohxFQ2JUd2cwMIIBwZ9H3XnUSiI1GOWTf2JBh+uuGD9LR06lTMPnQJ0 g== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=xgBtxH4GvKT9CGF/HOXfHIun2rGGFegJaNvjDxJC2rpjqosEjAenQqln2UOc1qNKr EQu/LB0BoicIvlEiSNGFw== Received: from an-out-0708.google.com (anab38.prod.google.com [10.100.53.38]) by zps18.corp.google.com with ESMTP id n6GIOrAY010544 for ; Thu, 16 Jul 2009 11:24:54 -0700 Received: by an-out-0708.google.com with SMTP id b38so148695ana.9 for ; Thu, 16 Jul 2009 11:24:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.239.4 with SMTP id m4mr107070anh.76.1247768693640; Thu, 16 Jul 2009 11:24:53 -0700 (PDT) In-Reply-To: <200907160909.n6G9972U023073@kac.cnri.dit.ie> References: <200907160909.n6G9972U023073@kac.cnri.dit.ie> Date: Thu, 16 Jul 2009 11:24:53 -0700 Message-ID: From: Jerry Chu To: David Malone Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Tuning TCP parameters for the 21st century 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: , X-List-Received-Date: Thu, 16 Jul 2009 18:24:27 -0000 On Thu, Jul 16, 2009 at 2:09 AM, David Malone wrote: >> We have seen SYN-ACK retransmission rates upto a few percentage points t= o >> some of our servers. > > Note, that I've seen Google reported to have unusually SYN-ACK > retransmission rates in this paper: > > =A0 =A0 =A0 =A0http://www.springerlink.com/content/t033171209815745/ > > Are Google already doing something unusual with their SYN-ACK > retransmissions? I can't access the above link so don't know what the unusual SYN-ACK retransmission rate is. We are experiementing with using RTT history on a handful of servers as mentioned before. Otherwise our SYN-ACK retransmit rate seems pretty much on par with the general pkt retransmit rate, and can go up to a few percentage in regions like India, China... Jerry > > =A0 =A0 =A0 =A0David. > From hkchu@google.com Thu Jul 16 19:35:58 2009 Return-Path: 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 522613A6BFB for ; Thu, 16 Jul 2009 19:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] 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 QYOgQ8E1zTOh for ; Thu, 16 Jul 2009 19:35:57 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 535363A6E12 for ; Thu, 16 Jul 2009 19:35:56 -0700 (PDT) Received: from spaceape24.eur.corp.google.com (spaceape24.eur.corp.google.com [172.28.16.76]) by smtp-out.google.com with ESMTP id n6H2aQcd022090 for ; Thu, 16 Jul 2009 19:36:27 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1247798188; bh=1mTquiY9b5vz66Uq5P4SOVULspg=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type: Content-Transfer-Encoding:X-System-Of-Record; b=jrQzg8LDyVgg5HWiGo nAWqyQwXCQ/SG0CG1vv8+Lr1of5iN32GHdrIF6obVK2zHCDbEtGcgUxtyJT+lBozMdO w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=LnZP5afD7xD69v6r7Bq5GW6ik24C3o1KZfPbv4yKv9IlUCSGcPSjThYC//OrUfQ91 m41LQDbOpHXy+Qnrd3s6A== Received: from yxe42 (yxe42.prod.google.com [10.190.2.42]) by spaceape24.eur.corp.google.com with ESMTP id n6H2aN6I015393 for ; Thu, 16 Jul 2009 19:36:24 -0700 Received: by yxe42 with SMTP id 42so973007yxe.13 for ; Thu, 16 Jul 2009 19:36:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.96.12 with SMTP id t12mr840204anb.4.1247798183710; Thu, 16 Jul 2009 19:36:23 -0700 (PDT) In-Reply-To: <1247733589.4184.56.camel@localhost.localdomain> References: <4A5CE3D0.5000904@isi.edu> <4A5D0E8F.1040402@isi.edu> <4A5DE6BC.3090904@isi.edu> <7261633966bb7a55cebd4ce313069082.squirrel@webmail.uio.no> <4A5E018C.8030604@isi.edu> <1247733589.4184.56.camel@localhost.localdomain> Date: Thu, 16 Jul 2009 19:36:23 -0700 Message-ID: From: Jerry Chu To: Michael Welzl Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: tcpm@ietf.org Subject: Re: [tcpm] Tuning TCP parameters for the 21st century 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: , X-List-Received-Date: Fri, 17 Jul 2009 02:35:58 -0000 On Thu, Jul 16, 2009 at 1:39 AM, Michael Welzl wrote: >> > - but what about retransmitting SYN/ACKs faster? >> > Since the other side already sent a SYN, it probably >> > isn't overloaded >> >> That presumes the other side already sent a SYN and it's been received, >> and that the SYN/ACK is what's getting lost/delayed/retransmitted. =A0If >> not, that won't help. > > Right - > > >> First find where things are going wrong empirically ;-) > > We've done that. See, for example, fig. 2 (a) of > http://www.welzl.at/research/publications/networking2009.pdf > (page 7 of the pdf) > > Since our goal in this paper was to document general failures > of connection setup, we did not strictly split our results > into the case of lost SYNs or lost SYN/ACKs in it. > Section 3 (end of page 3 / beginning of page 4) explains > how lost SYN/ACKs were incorporated in our measurements. > > > This paper is based on data produced by a student. The > data are more thoroughly documented in his (alas, German) > bachelor thesis. This document is here: > http://www.welzl.at/research/tools/syn-retransmit/benjamin_kaser_bak1.pdf > and the most relevant information is table 2 on page 47. > (Table 1 is similar, just for SYNs, not SYN/ACKs). > > If you look at it, with or without German knowledge > you will be able to see the connection to table 1 in > the paper, where we exchanged columns with lines and > omitted some details - apparently just the crucial > ones =A0:-( =A0 =A0Anyway, the listed measurements are just > the same, and hence you can read the details in the > paper if you're interested in how we obtained our > data. > > Table 2 on page 47 of the bachelor thesis has several > details about duplicate SYN/ACKs that we've seen, > e.g. classified by eventually successful and unsuccessful > connections. As a quick summary, in 3432744 connection > attempts, we have seen 56586 duplicate SYN/ACKs in total > (this is a cumulative number, i.e. 4 SYN/ACKs are counted > as 3). Counting only the occurrence of duplicate SYN/ACKs, > we saw them for 0,55% of the 3432744 connection attempts. > In general, the difference between duplicate SYN/ACK > occurrences and duplicate SYN occurrences is negligible > in our measurements. > > As I just looked at the data again, I noticed a mistake: > in the paper, we wrote that the problem only happens for > around 0.5% of the connections, but this is really only > from the SYN table, not the SYN/ACK table in the bachelor > thesis. The SYN/ACK table covers the same measurement sets. > Hence, in total, it seems that we also saw > 1% lost SYNs > *or* SYN/ACKs, which exactly matches what Jerry Chu said. > > BTW I maintain a small website about the whole thing: > http://www.welzl.at/research/tools/syn-retransmit/index.html Our overall pkt retransmission rate often goes over 1%. I was wondering if SYN/SYN-ACK pkts are less likely to be dropped by some routers due to their smaller size so we collected traces and computed SYN-ACK retransmissions rate on some servers. We confirmed it to be consistent with the overall pkt drop rate, i.e., > 1% often. FYI, Jerry > > Cheers, > Michael > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From michawe@ifi.uio.no Thu Jul 16 23:30:44 2009 Return-Path: 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 0618D3A6C92 for ; Thu, 16 Jul 2009 23:30:44 -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 YbShFCqgPMjR for ; Thu, 16 Jul 2009 23:30:43 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [129.240.10.58]) by core3.amsl.com (Postfix) with ESMTP id 2A01F3A68BE for ; Thu, 16 Jul 2009 23:30:43 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out2.uio.no with esmtp (Exim 4.69) (envelope-from ) id 1MRgxl-0002PU-Dc for tcpm@ietf.org; Fri, 17 Jul 2009 08:30:33 +0200 Received: from div-8021x-dhcp050.uio.no ([193.157.176.59]) by mail-mx2.uio.no with esmtp (Exim 4.69) (envelope-from ) id 1MRgxl-0001Rt-0y for tcpm@ietf.org; Fri, 17 Jul 2009 08:30:33 +0200 From: Michael Welzl To: tcpm@ietf.org In-Reply-To: References: <4A5CE3D0.5000904@isi.edu> <4A5D0E8F.1040402@isi.edu> <4A5DE6BC.3090904@isi.edu> <7261633966bb7a55cebd4ce313069082.squirrel@webmail.uio.no> <4A5E018C.8030604@isi.edu> <1247733589.4184.56.camel@localhost.localdomain> Content-Type: text/plain Date: Fri, 17 Jul 2009 08:30:45 +0200 Message-Id: <1247812245.4167.1.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-10.fc7) Content-Transfer-Encoding: 7bit X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 3 sum msgs/h 3 total rcpts 1975 max rcpts/h 33 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=0.0, required=5.0, autolearn=disabled, none, uiobl=NO, uiouri=_URIID_) X-UiO-Scanned: 06026CA03F46E0341512D16DF4A6058FACF6EE9E X-UiO-SPAM-Test: remote_host: 193.157.176.59 spam_score: 0 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 492 max/h 15 blacklist 0 greylist 0 ratelimit 0 Subject: Re: [tcpm] Tuning TCP parameters for the 21st century 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: , X-List-Received-Date: Fri, 17 Jul 2009 06:30:44 -0000 So, after some data have been mentioned, can we get back to this question: On Thu, 2009-07-16 at 19:36 -0700, Jerry Chu wrote: > On Thu, Jul 16, 2009 at 1:39 AM, Michael Welzl wrote: > >> > - but what about retransmitting SYN/ACKs faster? > >> > Since the other side already sent a SYN, it probably > >> > isn't overloaded ? Cheers, Michael From gregory.ietf@gmail.com Wed Jul 22 18:59:31 2009 Return-Path: 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 B530B3A6B86 for ; Wed, 22 Jul 2009 18:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.188, 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 QEsjOCNrtxcW for ; Wed, 22 Jul 2009 18:59:30 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by core3.amsl.com (Postfix) with ESMTP id DABE73A693F for ; Wed, 22 Jul 2009 18:59:30 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id v27so81074wah.5 for ; Wed, 22 Jul 2009 18:59: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:x-mailer :x-priority:date:to:from:subject:cc:mime-version:content-type; bh=U14YaYhJwHmntjtTaDyx9skzwM//9m8tNFn6A8PzevE=; b=kZ/04c6OR5Eaxj7AdBdAZgP0Vifl8Aqrha/dszAkY6lAgiFGTNI8bZPnpqzHC1M9Cx DLDOUgZATTCOuijCYtR5ZaPeBiRyr7Ao7p6E54YTRHPdlvGNDIuFKGu09TdR+fg6C2/L rRgJ9KIbVJMr81LAF3LEzkEO9S8SfghPm4O5o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:x-priority:date:to:from:subject:cc:mime-version :content-type; b=I02LRX9tmaMTkC+YRtzNzvkKcCkEjYwTJ80er0z5+uH/GfgX0hoCl345aHnTB2t/Nk AI7QhFJHc6qMVz+SKOTxdJJtme77jBVMRYsaiz6G61oftjFYVmPtYghSQxAJTYirFJUn h/1qsnp3zAlM7siflMzE5VNI61RhrG5dW0UIw= Received: by 10.114.72.12 with SMTP id u12mr1505096waa.28.1248314361941; Wed, 22 Jul 2009 18:59:21 -0700 (PDT) Received: from Gregory-T60.gmail.com (natint3.juniper.net [66.129.224.36]) by mx.google.com with ESMTPS id n33sm2302846wag.21.2009.07.22.18.59.20 (version=SSLv3 cipher=RC4-MD5); Wed, 22 Jul 2009 18:59:21 -0700 (PDT) Message-ID: <4a67c3f9.21d7720a.312b.ffffbc9d@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 X-Priority: 1 (Highest) Date: Wed, 22 Jul 2009 18:59:18 -0700 To: Eric Rescorla ,David McGrew , Brian Weis ,Tim Polk From: "Gregory M. Lebovitz" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: tcpm@ietf.org Subject: [tcpm] handling variable length keys with AES-128-CMAC in TCP-AO-crypto 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: , X-List-Received-Date: Thu, 23 Jul 2009 01:59:31 -0000 Team, So, Dave McGrew doesn't like the idea of using the variable length master key in the input portion of AES-128-CMAC, and using some fixed 128 bit blob in the key portion in a key-sizing pre-run, in order to get a 128 bit key from a variable length key in order to feed that back into the AES-128-CMAC a second time to get the traffic key. (i.e. the method currently documented in draft-lebovitz-ietf-tcpm-tcp-ao-crypto-01, and used in rfc 4615) We are trying to handle the case where MK is the *variable length* master key, and sometimes MK < 128 bits, and sometimes MK > 128 bits, and sometimes VK = 128 bits. If we constrain the problem to: - we need to show people what to do if they get variable length keys - we don't want to use any other PRF in the AES-128-CMAC case (i.e. mandating the use of yet another algo like SHA256 increases the burden on implementations, and, for agility reasons we don't want the AES KDF to be built atop SHA1), - the same variable length master key entered on two different implementations MUST produce the same traffic key for any given connection, then, could we solve it like this: - Normative text: AES-128-CMAC needs a 128-bit key. Therefore administrators SHOULD use a suitable key of exactly 128 bits, as represented by a 16 character ASCII string. Implementation UI's SHOULD force the administrators to enter a 128-bit key when selecting AES-128-CMAC as the KDF. UI's SHOULD reject with an error any key not equal in length to 128 bits. If, for whatever reason this is not acceptable for certain environments, implementations MAY consider accepting keys from the UI with lengths not equal to 128bits and using AES-128-CMAC as described in appendix A to create a 128-bit key from a non-128-bit string. - Appendix A (non-Normative): - if the UI will allow strings of length not equal to 128 bits, and - if you get a string > 128-bit or <128-bit, then - if > 128-bit, truncate the string to 128-bits, and use them as the key - if < 128-bit, pad the end of the string with zeros until the string length equals 128-bit, and use that as the key string. I realize this isn't great, but I'm not sure how else to solve the problem that hasn't already been shot down. If neither the method in draft-01 nor the above work for you, then PLEASE send text for something better. Remember, we need to get this done asap, and I'd like to have a scrubbed proposal for the TCPM WG meeting in Stockholm. Thanks, 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 From ekr@networkresonance.com Wed Jul 22 23:32:35 2009 Return-Path: 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 786CB3A6870 for ; Wed, 22 Jul 2009 23:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.234 X-Spam-Level: X-Spam-Status: No, score=-0.234 tagged_above=-999 required=5 tests=[AWL=-0.252, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 VvWuAPpenp0V for ; Wed, 22 Jul 2009 23:32:34 -0700 (PDT) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 9CAEB3A67B8 for ; Wed, 22 Jul 2009 23:32:34 -0700 (PDT) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id B41CC1D1293; Wed, 22 Jul 2009 23:07:08 -0700 (PDT) Date: Wed, 22 Jul 2009 23:07:08 -0700 From: Eric Rescorla To: "Gregory M. Lebovitz" In-Reply-To: <4a67c3f9.21d7720a.312b.ffffbc9d@mx.google.com> References: <4a67c3f9.21d7720a.312b.ffffbc9d@mx.google.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090723060708.B41CC1D1293@kilo.networkresonance.com> Cc: Tim Polk , Eric Rescorla , David McGrew , tcpm@ietf.org Subject: Re: [tcpm] handling variable length keys with AES-128-CMAC in TCP-AO-crypto 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: , X-List-Received-Date: Thu, 23 Jul 2009 06:32:35 -0000 At Wed, 22 Jul 2009 18:59:18 -0700, Gregory M. Lebovitz wrote: > > Team, > So, Dave McGrew doesn't like the idea of using the variable length > master key in the input portion of AES-128-CMAC, and using some fixed > 128 bit blob in the key portion in a key-sizing pre-run, in order to > get a 128 bit key from a variable length key in order to feed that > back into the AES-128-CMAC a second time to get the traffic key. > (i.e. the method currently documented in > draft-lebovitz-ietf-tcpm-tcp-ao-crypto-01, and used in rfc 4615) > > We are trying to handle the case where MK is the *variable length* > master key, and sometimes MK < 128 bits, and sometimes MK > 128 bits, > and sometimes VK = 128 bits. > > If we constrain the problem to: > - we need to show people what to do if they get variable length keys > - we don't want to use any other PRF in the AES-128-CMAC case (i.e. > mandating the use of yet another algo like SHA256 increases the > burden on implementations, and, for agility reasons we don't want the > AES KDF to be built atop SHA1), > - the same variable length master key entered on two different > implementations MUST produce the same traffic key for any given connection, > > then, could we solve it like this: > - Normative text: AES-128-CMAC needs a 128-bit key. Therefore > administrators SHOULD use a suitable key of exactly 128 bits, as > represented by a 16 character ASCII string. Implementation UI's > SHOULD force the administrators to enter a 128-bit key when selecting > AES-128-CMAC as the KDF. UI's SHOULD reject with an error any key not > equal in length to 128 bits. If, for whatever reason this is not > acceptable for certain environments, implementations MAY consider > accepting keys from the UI with lengths not equal to 128bits and > using AES-128-CMAC as described in appendix A to create a 128-bit key > from a non-128-bit string. > > - Appendix A (non-Normative): > - if the UI will allow strings of length not equal to 128 bits, and > - if you get a string > 128-bit or <128-bit, then > - if > 128-bit, truncate the string to 128-bits, and use them as the key > - if < 128-bit, pad the end of the string with zeros until the > string length equals 128-bit, and use that as the key string. > > I realize this isn't great, but I'm not sure how else to solve the > problem that hasn't already been shot down. If neither the method in > draft-01 nor the above work for you, then PLEASE send text for > something better. Remember, we need to get this done asap, and I'd > like to have a scrubbed proposal for the TCPM WG meeting in Stockholm. This seems to me to be a bad approach; it creates a different interface for CMAC and HMAC. I would prefer that we abandon the requirement to use only AES and use an HMAC-based PRF as a whitening function. I don't think it matters whether it's SHA-1 or SHA-256--SHA-1 is plenty strong for this, but SHA-256 seems more popular at this point. -Ekr From ilpo.jarvinen@helsinki.fi Thu Jul 23 01:03:00 2009 Return-Path: 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 509903A67B3 for ; Thu, 23 Jul 2009 01:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[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 yXo0di-tSaIJ for ; Thu, 23 Jul 2009 01:02:59 -0700 (PDT) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by core3.amsl.com (Postfix) with ESMTP id 291AD3A6765 for ; Thu, 23 Jul 2009 01:02:58 -0700 (PDT) Received: from wel-95.cs.helsinki.fi (wel-95.cs.helsinki.fi [128.214.10.211]) (AUTH: PLAIN cs-relay, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Thu, 23 Jul 2009 11:01:23 +0300 id 0007044E.4A6818D3.00007F2A Received: by wel-95.cs.helsinki.fi (Postfix, from userid 50795) id 9B45B202263; Thu, 23 Jul 2009 11:01:23 +0300 (EEST) Received: from localhost (localhost [127.0.0.1]) by wel-95.cs.helsinki.fi (Postfix) with ESMTP id 99279202249 for ; Thu, 23 Jul 2009 11:01:23 +0300 (EEST) Date: Thu, 23 Jul 2009 11:01:23 +0300 (EEST) From: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" X-X-Sender: ijjarvin@wel-95.cs.helsinki.fi To: "tcpm@ietf.org" Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [tcpm] SACK-based recovery entry I-D updated (not in std repo yet) 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: , X-List-Received-Date: Thu, 23 Jul 2009 08:03:00 -0000 Hello all, We've updated draft-jarvinen-tcpm-sack-recovery-entry but missed the deadline so the updated version is not available through standard repository just yet. Therefore I've put the updated version available at: http://www.cs.helsinki.fi/group/wiseciti/I-Ds/draft-jarvinen-tcpm-sack-recovery-entry-01a.txt As promised, we've now included the paraller dupACK based fallback that solves small segment sender problem into the algorithm itself and doing corresponding removal of its description from the textual side (the biggest changes from -00 are due to that). Besides that, a placeholder for SACK splitting got added. The rest of the changes are quite minor. Any feedback is appreciated. -- i. From ilpo.jarvinen@helsinki.fi Thu Jul 23 01:06:42 2009 Return-Path: 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 9895D3A6817 for ; Thu, 23 Jul 2009 01:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[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 pbzQT+hp2PW6 for ; Thu, 23 Jul 2009 01:06:42 -0700 (PDT) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by core3.amsl.com (Postfix) with ESMTP id D51D93A67B3 for ; Thu, 23 Jul 2009 01:06:40 -0700 (PDT) Received: from wel-95.cs.helsinki.fi (wel-95.cs.helsinki.fi [128.214.10.211]) (AUTH: PLAIN cs-relay, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Thu, 23 Jul 2009 11:05:37 +0300 id 00070420.4A6819D1.00004788 Received: by wel-95.cs.helsinki.fi (Postfix, from userid 50795) id 82F7A202263; Thu, 23 Jul 2009 11:05:37 +0300 (EEST) Received: from localhost (localhost [127.0.0.1]) by wel-95.cs.helsinki.fi (Postfix) with ESMTP id 80DC6202249; Thu, 23 Jul 2009 11:05:37 +0300 (EEST) Date: Thu, 23 Jul 2009 11:05:37 +0300 (EEST) From: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" X-X-Sender: ijjarvin@wel-95.cs.helsinki.fi To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" , David Borman In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Draft Agenda for IET5 75 TCPM Meeting 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: , X-List-Received-Date: Thu, 23 Jul 2009 08:06:42 -0000 On Tue, 7 Jul 2009, Eddy, Wesley M. (GRC-MS00)[Verizon] wrote: > Here's a draft agenda for the TCPM meeting in Stockholm; please let > David and I know if we missed anyone that asked for a slot, or if there > are other people that want slots ... there should be a little bit of > room left given our 2 hour timeslot that was allocated. If there's still room on the agenda, could you please allocate a slot for draft-jarvinen-tcpm-sack-recovery-entry (10mins is fine). Thanks. -- i. From wesley.m.eddy@nasa.gov Thu Jul 23 07:54:26 2009 Return-Path: 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 7FAC23A63EB for ; Thu, 23 Jul 2009 07:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.232 X-Spam-Level: X-Spam-Status: No, score=-6.232 tagged_above=-999 required=5 tests=[AWL=0.068, 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 XX7Z8EN6cMpx for ; Thu, 23 Jul 2009 07:54:25 -0700 (PDT) Received: from ndmsnpf01.ndc.nasa.gov (ndmsnpf01.ndc.nasa.gov [198.117.0.121]) by core3.amsl.com (Postfix) with ESMTP id 9ACD73A687C for ; Thu, 23 Jul 2009 07:54:25 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 8D539A06A; Thu, 23 Jul 2009 09:52:11 -0500 (CDT) Received: from ndjshub03.ndc.nasa.gov (ndjshub03.ndc.nasa.gov [198.117.4.162]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n6NEqBe3004222; Thu, 23 Jul 2009 09:52:11 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub03.ndc.nasa.gov ([198.117.4.162]) with mapi; Thu, 23 Jul 2009 09:52:11 -0500 From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" To: =?iso-8859-1?Q?Ilpo_J=E4rvinen?= , David Borman Date: Thu, 23 Jul 2009 09:52:10 -0500 Thread-Topic: [tcpm] Draft Agenda for IET5 75 TCPM Meeting Thread-Index: AcoLbF5+VeuYhofzRnOS1MePzDNZvAAOJY5Q Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-07-23_08:2009-07-20, 2009-07-23, 2009-07-23 signatures=0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Draft Agenda for IET5 75 TCPM Meeting 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: , X-List-Received-Date: Thu, 23 Jul 2009 14:54:26 -0000 >-----Original Message----- >From: Ilpo J=E4rvinen [mailto:ilpo.jarvinen@helsinki.fi] >Sent: Thursday, July 23, 2009 4:06 AM >To: Eddy, Wesley M. (GRC-MS00)[Verizon].; David Borman >Cc: tcpm@ietf.org >Subject: Re: [tcpm] Draft Agenda for IET5 75 TCPM Meeting > >If there's still room on the agenda, could you please allocate a slot >for >draft-jarvinen-tcpm-sack-recovery-entry (10mins is fine). Thanks. > Ok; I've updated the schedule and placed this at the end. --------------------------- Wes Eddy Network & Systems Architect Verizon FNS / NASA GRC Office: (216) 433-6682 --------------------------- From narten@us.ibm.com Fri Jul 24 12:53:59 2009 Return-Path: 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 C08AA3A69A7 for ; Fri, 24 Jul 2009 12:53:59 -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 5cRSh2daqQsT for ; Fri, 24 Jul 2009 12:53:58 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by core3.amsl.com (Postfix) with ESMTP id 5B8D33A67E4 for ; Fri, 24 Jul 2009 12:53:32 -0700 (PDT) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n6OJkXnK007575 for ; Fri, 24 Jul 2009 15:46:33 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n6OJqRf8258256 for ; Fri, 24 Jul 2009 15:52:27 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n6OJqQXh030584 for ; Fri, 24 Jul 2009 15:52:26 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-65-207-1.mts.ibm.com [9.65.207.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n6OJqPnN030447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 24 Jul 2009 15:52:26 -0400 Received: from cichlid (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.3/8.12.5) with ESMTP id n6OJqMVZ006081 for ; Fri, 24 Jul 2009 15:52:24 -0400 Message-Id: <200907241952.n6OJqMVZ006081@cichlid.raleigh.ibm.com> To: tcpm@ietf.org Date: Fri, 24 Jul 2009 15:52:22 -0400 From: Thomas Narten Subject: [tcpm] Nagle Algorithm and Delayed ACKs 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: , X-List-Received-Date: Fri, 24 Jul 2009 19:53:59 -0000 It has been long known that the Nagle Algorithm and Delayed ACKs combine in ways that can be problematic. Googling around, I found Stewart Chesire's writeup (http://www.stuartcheshire.org/papers/NagleDelayedAck/) as well as an ancient (!) ID from Greg Minshall (http://lists.w3.org/Archives/Public/ietf-discuss/1998Dec/0025.html) The TCP_NODELAY socket option can be used to turn off the Nagle Algorithm, but applications have to know to enable it -- which they often don't know, until after they've run into problems and traced them down to the specific problem. This can be a long and expensive process (e.g., involve help desk calls). What is the current thinking on this problem? Am I right in assuming that: - the Nagle Algorithm is still a SHOULD to implement - Delayed ACKs are also a SHOULD to implement? - Most everyone provides a TCP_NODELAY type socket option? Is that all there is to it? Is this considered good enough? Have there not been in any attempts over the last ten years to update the above recommendations to make them work together better without an application needing to set the TCP_NODELAY option, in those cases where it matters? Thomas From Michael.Tuexen@lurchi.franken.de Fri Jul 24 13:47:39 2009 Return-Path: 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 9390C3A6925 for ; Fri, 24 Jul 2009 13:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.473 X-Spam-Level: ** X-Spam-Status: No, score=2.473 tagged_above=-999 required=5 tests=[AWL=0.435, 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 DF0ub3cF5XAz for ; Fri, 24 Jul 2009 13:47:38 -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 61A263A680C for ; Fri, 24 Jul 2009 13:47:38 -0700 (PDT) Received: from [192.168.1.100] (p508FE657.dip.t-dialin.net [80.143.230.87]) by mail-n.franken.de (Postfix) with ESMTP id E43761C0C0BD8; Fri, 24 Jul 2009 22:47:34 +0200 (CEST) Message-Id: From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: Thomas Narten In-Reply-To: <200907241952.n6OJqMVZ006081@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 24 Jul 2009 22:47:33 +0200 References: <200907241952.n6OJqMVZ006081@cichlid.raleigh.ibm.com> X-Mailer: Apple Mail (2.935.3) Cc: tcpm@ietf.org Subject: Re: [tcpm] Nagle Algorithm and Delayed ACKs 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: , X-List-Received-Date: Fri, 24 Jul 2009 20:47:39 -0000 Hi Thomas, interesting you bring this up... For SCTP we have the same problem and we therefore submitted draft-tuexen-tsvwg-sctp-sack-immediately-02.txt which was presented at the last TSVWG session. However, the result of the discussion was that the issue is minor and there was not much interest in the WG to adopt the ID. Best regards Michael On Jul 24, 2009, at 9:52 PM, Thomas Narten wrote: > It has been long known that the Nagle Algorithm and Delayed ACKs > combine in ways that can be problematic. Googling around, I found > Stewart Chesire's writeup > (http://www.stuartcheshire.org/papers/NagleDelayedAck/) as well as an > ancient (!) ID from Greg Minshall > (http://lists.w3.org/Archives/Public/ietf-discuss/1998Dec/0025.html) > > The TCP_NODELAY socket option can be used to turn off the Nagle > Algorithm, but applications have to know to enable it -- which they > often don't know, until after they've run into problems and traced > them down to the specific problem. This can be a long and expensive > process (e.g., involve help desk calls). > > What is the current thinking on this problem? Am I right in assuming > that: > > - the Nagle Algorithm is still a SHOULD to implement > - Delayed ACKs are also a SHOULD to implement? > - Most everyone provides a TCP_NODELAY type socket option? > > Is that all there is to it? Is this considered good enough? > > Have there not been in any attempts over the last ten years to update > the above recommendations to make them work together better without an > application needing to set the TCP_NODELAY option, in those cases > where it matters? > > Thomas > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From cabo@tzi.org Fri Jul 24 22:17:55 2009 Return-Path: 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 747C23A6975 for ; Fri, 24 Jul 2009 22:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 X1qbhr4pBzTN for ; Fri, 24 Jul 2009 22:17:54 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 155333A69A3 for ; Fri, 24 Jul 2009 22:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n6P5HSVd012741; Sat, 25 Jul 2009 07:17:29 +0200 (CEST) Received: from [192.168.217.107] (p5489BEB8.dip.t-dialin.net [84.137.190.184]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 89842B79D; Sat, 25 Jul 2009 07:17:28 +0200 (CEST) From: Carsten Bormann To: Thomas Narten In-Reply-To: <200907241952.n6OJqMVZ006081@cichlid.raleigh.ibm.com> References: <200907241952.n6OJqMVZ006081@cichlid.raleigh.ibm.com> Message-Id: <37C0C058-7364-4ACD-A5ED-AACA51F8B567@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 25 Jul 2009 07:17:26 +0200 X-Mailer: Apple Mail (2.935.3) Cc: tcpm@ietf.org Subject: Re: [tcpm] Nagle Algorithm and Delayed ACKs 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: , X-List-Received-Date: Sat, 25 Jul 2009 05:17:55 -0000 On Jul 24, 2009, at 21:52, Thomas Narten wrote: > TCP_NODELAY My view would be that this is a well-documented option in the socket interface. Even though the interaction with delayed ACKs is rarely explained correctly, there are lots of "Socket FAQ" and "Tuning Guide" documents that explain "Nagling" (ouch) and the TCP_NODELAY socket option (I get 117000 google hits...). TCP_NODELAY certainly is standard fare in any reasonable socket API course. People already need to think about the number of write/send operations they perform for one message. (Note that Linux also has TCP_CORK.) In essence, the kernel needs to know whether the programmer was not considering the issue (making it likely there will be lots of silly small writes) or whether the issue was considered and the program is optimized with respect to the writes. A socket option defaulting to the first case sounds like the right way to communicate that information, which is hard to infer. What would you want to improve? Gruesse, Carsten From gregory.ietf@gmail.com Sat Jul 25 16:22:42 2009 Return-Path: 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 1359C3A68D7 for ; Sat, 25 Jul 2009 16:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 Lv8Fd9qTdD9Q for ; Sat, 25 Jul 2009 16:22:41 -0700 (PDT) Received: from mail-px0-f194.google.com (mail-px0-f194.google.com [209.85.216.194]) by core3.amsl.com (Postfix) with ESMTP id 6EE563A67F3 for ; Sat, 25 Jul 2009 16:22:41 -0700 (PDT) Received: by pxi32 with SMTP id 32so1016082pxi.29 for ; Sat, 25 Jul 2009 16:22:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:x-mailer:date:to :from:subject:cc:mime-version:content-type; bh=gtxkmjCglWPdQYZIi0MZX88GEUk5vTQl3AuUvf0003o=; b=CJlDbiM9Wv4CP3QtrylIr21w5u/xXDcsz0kf8DeIcj2gQdtB7Pb7DzvQouGyTq6qO8 Gy3Z5sFoKvtrzicAplPhae9VMqwpjTPLJuKfEOiEZznyIYtQC3HaP67CJL0hroEhoJrH WrsyemFp4qb/0DO9l6KdeiGWYvK0xPKaQBSGY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:date:to:from:subject:cc:mime-version :content-type; b=I+C+bwExr2I3cpJBKDiCYHEZta9hEIoT009thy+E+RZ+u3glnG2yE3xGZjQBFYmcI1 +bWPrswuE4bPDHPO62u/Tt5FUVXQfIWhgg88J9Ct4Cy92hU1yDRohG6QWsvbiXDtVq9j 1B3SNPQMhnWxzWq3BZCiN3Cs9/DzyzyTIJTig= Received: by 10.114.95.20 with SMTP id s20mr7018035wab.114.1248564160624; Sat, 25 Jul 2009 16:22:40 -0700 (PDT) Received: from Gregory-T60.gmail.com (nat-service4.juniper.net [66.129.225.151]) by mx.google.com with ESMTPS id m30sm9864509wag.34.2009.07.25.16.22.32 (version=SSLv3 cipher=RC4-MD5); Sat, 25 Jul 2009 16:22:36 -0700 (PDT) Message-ID: <4a6b93bc.1ed6720a.33e5.0661@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 25 Jul 2009 15:26:03 -0700 To: Joe Touch ,Brian Weis , Wesley Eddy ,Fernando Gont From: "Gregory M. Lebovitz" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: tcpm@ietf.org, David Borman Subject: [tcpm] TCP-AO - Working session to close open issues? 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: , X-List-Received-Date: Sat, 25 Jul 2009 23:22:42 -0000 Hey guys, In the spirit of trying to get to working group last call asap, what do you think about having a working session on Sunday evening or monday to try to close out some of the open items on TCP-AO BEFORE our monday 17:40 TCPM session? Do any of the following work? - Sunday 21:00 - 23:00 - Monday 15:10 - 17:30 If we can't get together before the TCPM mtg on Monday, how about we get a quick bite together on Monday after the meeting, and then spend a bit of time together on the document's open issues? (note: EKR's not here this week.) Gregory. 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 From gregory.ietf@gmail.com Sat Jul 25 16:22:47 2009 Return-Path: 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 0B22F3A6B99 for ; Sat, 25 Jul 2009 16:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.049, 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 1xckBEPSYDZl for ; Sat, 25 Jul 2009 16:22:46 -0700 (PDT) Received: from mail-pz0-f191.google.com (mail-pz0-f191.google.com [209.85.222.191]) by core3.amsl.com (Postfix) with ESMTP id DA0883A6B4C for ; Sat, 25 Jul 2009 16:22:45 -0700 (PDT) Received: by pzk29 with SMTP id 29so438353pzk.29 for ; Sat, 25 Jul 2009 16:22: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:x-mailer:date:to :from:subject:in-reply-to:references:mime-version:content-type; bh=BZRxtlp59xyQ+c2RAce5nKnhRRpMR56jhF6pNytXmI0=; b=qeQ5lco2a+I7b5uPKfJk5dmX4dKQ2rSL+j4IBvQlShnp7SDwUEpFZTad9hj/1o/d5q m0eH6ecLE/1fUY9iJLB6Iez+Xe2WCnECu0tTIjfr/zevX+SmJk2vk1Sb5zaQ1683Fb3r AAyFvpDIzg/oef1SLUCCdgywUT2/2W0K2lT10= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:date:to:from:subject:in-reply-to:references :mime-version:content-type; b=iRHtJUXsAtFcmrKGVOZWfISXXtqeS8ftpospq6sjbooRcC0Y7dkH0VqxuRCt1mSCdz L7Iw+YD4wuWsWWrlPkhS8GwEb12xoLP9ZO39GkNhUJ9JLwIsWA4pEJZiO1KcJsEoDkYE sYZWvKt+aoV1RilNxOQhGypCCLypevja18E2M= Received: by 10.114.191.1 with SMTP id o1mr7001395waf.108.1248564165057; Sat, 25 Jul 2009 16:22:45 -0700 (PDT) Received: from Gregory-T60.gmail.com (nat-service4.juniper.net [66.129.225.151]) by mx.google.com with ESMTPS id m30sm9864509wag.34.2009.07.25.16.22.41 (version=SSLv3 cipher=RC4-MD5); Sat, 25 Jul 2009 16:22:43 -0700 (PDT) Message-ID: <4a6b93c3.1ed6720a.33e5.0667@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 25 Jul 2009 12:25:28 -0700 To: Joe Touch ,tcpm Extensions WG From: "Gregory M. Lebovitz" In-Reply-To: <4A5B9FEB.6080706@isi.edu> References: <4A5B9FEB.6080706@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [tcpm] possible NAT support for TCP-AO 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: , X-List-Received-Date: Sat, 25 Jul 2009 23:22:47 -0000 inline... At 01:58 PM 7/13/2009, Joe Touch wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Hi, all, > >Based on a discussion on a different list with Dan Wing, I'd like to >revisit thinking about NATs in the context of the current AO, I'm not against the idea. I see some issues (see more below). But I think it could work. My one big concern is that the BGP community has been waiting a VERY long time for this update, and I'd hate to drag out a last call, or RFC, for this issue which they don't care much about. But I think solving it in the long run is important. As a compromise between these two competing needs, might we consider this: - proceed to WG LC & RFC without the NAT solution. - in parallel, work on text for the NAT solution - do a rather quick rev of the first RFC to include the NAT solution (and the few bugs I'm sure we'll find as we move to implementations) ?? >which uses >traffic keys derived from the socket pair and ISN pair. We might be able >to now support NATs as follows, e.g.: > > add the following flags to the MKT: > > localNAT flag - indicates whether the local IP/port are > zeroed before MAC calculation > > remoteNAT flag - indicates whether the remote IP/port > are zeroed before MAC calculation This will be tough, as you won't always know. We could solve this later in a KMP system that provides NAT detection, and hands the answer down to the TCP stack config (I'm thinking of the way that NAT-T for IKE works wrt IPsec/ESP). But it could work. > add steps to the incoming/outgoing processing: > zero the corresponding IP/port when the flag indicates, > both on outgoing and incoming MAC calculation If both directions are behind NATs (a very probably case for non-routing protocol usage), then the uniqueness data defining the connection is reduced greatly, i.e. only the ISNs remain as unique. This affects the entropy of the KDF, where the connection data is used as the input to the function, in order to derive the traffic keys. If I'm not mistaken, it means that, in the unlikely event that the same ISN's are chosen for a different connection 5-tuple, then a replay attack could be accomplished. I can live with that risk trade-off, personally. But I'd want to make sure we call it out explicitly the NAT-T section where the mechanism is described, and then go into it more completely in the security considerations. section. >That's basically it. A client behind a NAT would have a MKT with >localNAT true, and a server for that client would need to have a MKT >with remoteNAT true. This does require careful MKT configuration. >Although I wouldn't expect both localNAT and remoteNAT to be true, there >isn't a particular reason it needs to be prohibited. > >Here's the security impact: > > - no impact to other connections (AFAICT) > > - SYN/SYN-ACKs limited only as much as the MKT TCP connection > ID is, i.e., as a small range or single value rather than > wildcard for either address or port > > - connections are reasonably well-protected once established, > much like BTNS (due to use of both ISNs in the traffic keys) > > - reduced entropy for the traffic keys from a given MKT, > since their input could be limited to the ISN pair in the > worst case I think what I described above fits under this point, if I understood Joe's point correctly. That's my .02, after a very quick read and response, Gregory. >I did NOT include this in TCP-AO-05, but it's simple enough to add if >useful. I'd like to ask that we think about this before Stockholm, and >discuss it on the list if possible in advance. > >Joe >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.9 (MingW32) >Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > >iEYEARECAAYFAkpbn+sACgkQE5f5cImnZru8uwCeLaty+1z8+Qnrzg8L3G82SFO0 >4WEAoJ00Ww9omlO9ggb58lW064tDMqxl >=3Z2o >-----END PGP SIGNATURE----- >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www.ietf.org/mailman/listinfo/tcpm From touch@ISI.EDU Sat Jul 25 22:32:18 2009 Return-Path: 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 72A6C3A6A1D for ; Sat, 25 Jul 2009 22:32:18 -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 kGoYBtXrA0Mw for ; Sat, 25 Jul 2009 22:32:17 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 945AF3A68D7 for ; Sat, 25 Jul 2009 22:32:17 -0700 (PDT) Received: from [10.38.24.32] ([166.137.5.16]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n6Q5UkDx025690; Sat, 25 Jul 2009 22:30:50 -0700 (PDT) From: Joe Touch To: "Gregory M. Lebovitz" In-Reply-To: <4a6b93bc.1ed6720a.33e5.0661@mx.google.com> X-Mailer: iPhone Mail (7A341) References: <4a6b93bc.1ed6720a.33e5.0661@mx.google.com> Message-Id: <1780C440-658E-43AE-A3E0-CEA1573B34FE@isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPhone Mail 7A341) Date: Sun, 26 Jul 2009 07:30:41 +0200 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: David Borman , Wesley Eddy , Fernando Gont , "tcpm@ietf.org" Subject: Re: [tcpm] TCP-AO - Working session to close open issues? 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: , X-List-Received-Date: Sun, 26 Jul 2009 05:32:18 -0000 Please see the current doc - there are no open issues I am aware of except NAT support, which can be closed during the WG mtg. I can meet after the WG only, fwiw. Joe Sent from my iPhone On Jul 26, 2009, at 12:26 AM, "Gregory M. Lebovitz" wrote: > Hey guys, > In the spirit of trying to get to working group last call asap, what > do you think about having a working session on Sunday evening or > monday to try to close out some of the open items on TCP-AO BEFORE > our monday 17:40 TCPM session? > > Do any of the following work? > - Sunday 21:00 - 23:00 > - Monday 15:10 - 17:30 > > If we can't get together before the TCPM mtg on Monday, how about we > get a quick bite together on Monday after the meeting, and then > spend a bit of time together on the document's open issues? > > (note: EKR's not here this week.) > > Gregory. > > > 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 From touch@ISI.EDU Sun Jul 26 03:51:42 2009 Return-Path: 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 03CF63A6A00 for ; Sun, 26 Jul 2009 03:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQZnvtEm9vtI for ; Sun, 26 Jul 2009 03:51:41 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 48A0F3A68C1 for ; Sun, 26 Jul 2009 03:51:41 -0700 (PDT) Received: from [10.39.253.62] ([166.137.7.138]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n6QAo2Fb021980; Sun, 26 Jul 2009 03:50:04 -0700 (PDT) From: Joe Touch To: Joe Touch In-Reply-To: <1780C440-658E-43AE-A3E0-CEA1573B34FE@isi.edu> X-Mailer: iPhone Mail (7A341) References: <4a6b93bc.1ed6720a.33e5.0661@mx.google.com> <1780C440-658E-43AE-A3E0-CEA1573B34FE@isi.edu> Message-Id: <4C52AC76-46BC-4090-94F2-0188CDDE7592@isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPhone Mail 7A341) Date: Sun, 26 Jul 2009 12:49:56 +0200 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" , David Borman , Fernando Gont , Wesley Eddy Subject: Re: [tcpm] TCP-AO - Working session to close open issues? 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: , X-List-Received-Date: Sun, 26 Jul 2009 10:51:42 -0000 Sent from my iPhone On Jul 26, 2009, at 7:30 AM, Joe Touch wrote: > Please see the current doc - there are no open issues I am aware of > except NAT support, which can be closed during the WG mtg. I can > meet after the WG only, fwiw. Ps - only until the homegate bar bof. (or whatever the tsv barbof of the night is) > > Joe > > Sent from my iPhone > > On Jul 26, 2009, at 12:26 AM, "Gregory M. Lebovitz" > wrote: > >> Hey guys, >> In the spirit of trying to get to working group last call asap, >> what do you think about having a working session on Sunday evening >> or monday to try to close out some of the open items on TCP-AO >> BEFORE our monday 17:40 TCPM session? >> >> Do any of the following work? >> - Sunday 21:00 - 23:00 >> - Monday 15:10 - 17:30 >> >> If we can't get together before the TCPM mtg on Monday, how about >> we get a quick bite together on Monday after the meeting, and then >> spend a bit of time together on the document's open issues? >> >> (note: EKR's not here this week.) >> >> Gregory. >> >> >> 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 From gregory.ietf@gmail.com Sun Jul 26 05:07:51 2009 Return-Path: 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 7BEEF28C135 for ; Sun, 26 Jul 2009 05:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 xTDMIe4e8oAM for ; Sun, 26 Jul 2009 05:07:50 -0700 (PDT) Received: from mail-px0-f194.google.com (mail-px0-f194.google.com [209.85.216.194]) by core3.amsl.com (Postfix) with ESMTP id B99A428C12B for ; Sun, 26 Jul 2009 05:07:50 -0700 (PDT) Received: by pxi32 with SMTP id 32so1189474pxi.29 for ; Sun, 26 Jul 2009 05:07: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:x-mailer:date:to :from:subject:cc:in-reply-to:references:mime-version:content-type; bh=/ulo6EGqFRC0GgPDjg2MQzIRK8C067+f5fcWe0s+nt8=; b=tcJ1X38Jk88Jm5d7AJNjWEYl3FFmeW+vW37mG+KkPAydlKpo3r3gHQVit8jl5ahX/V fAOH+MJIBniFl8u/+JPzeWhp6/GNX0BZbiff0lpLWj2FgfpHHXDxNSJ879TvWjW8hmYH YQiO7PUFaXYSfZ3CtG6xLaG6FPwmxCZt+VgVQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:date:to:from:subject:cc:in-reply-to:references :mime-version:content-type; b=kB6eEWBy31biCuwfUhZ0ZDgPQ5Av7wddybXJebn5juSmVZ9c6A5Z8XukDw0dUPwSo2 Qs5rSkxN6r++28LA+ykL1LZJauWIh3tUZyqWVApOydgXdlWQ9uNNs8C9VBiPsb7SC3+m HdFeXLVkGKEBoxbo4CuZYlf5J0Z7p2L1bUN58= Received: by 10.115.107.12 with SMTP id j12mr7872821wam.94.1248610070232; Sun, 26 Jul 2009 05:07:50 -0700 (PDT) Received: from Gregory-T60.gmail.com (nat-service4.juniper.net [66.129.225.151]) by mx.google.com with ESMTPS id n9sm11003776wag.23.2009.07.26.05.07.47 (version=SSLv3 cipher=RC4-MD5); Sun, 26 Jul 2009 05:07:49 -0700 (PDT) Message-ID: <4a6c4715.09d7720a.29ab.ffffa37b@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 26 Jul 2009 05:07:42 -0700 To: Joe Touch From: "Gregory M. Lebovitz" In-Reply-To: <1780C440-658E-43AE-A3E0-CEA1573B34FE@isi.edu> References: <4a6b93bc.1ed6720a.33e5.0661@mx.google.com> <1780C440-658E-43AE-A3E0-CEA1573B34FE@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: David Borman , Wesley Eddy , Fernando Gont , "tcpm@ietf.org" Subject: Re: [tcpm] TCP-AO - Working session to close open issues? 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: , X-List-Received-Date: Sun, 26 Jul 2009 12:07:51 -0000 At 10:30 PM 7/25/2009, Joe Touch wrote: >Please see the current doc - there are no open issues I am aware of >except NAT support, which can be closed during the WG mtg. Hey Joe. It was while reading draft-05 that I wrote my email. Here are the things I'd like to work through, just to be sure we have closure: - step by step through rolling from one key to a new key - step by step through the removal of a key - step by step through the matching overlap problem - clarity on KDF / HMAC language - clarify the current crypto issue with variable length MasterKeys and AES-128-CMAC If tonight won't work, when, even if it's after the meeting another day? Gregory >I can meet >after the WG only, fwiw. > >Joe > >Sent from my iPhone > >On Jul 26, 2009, at 12:26 AM, "Gregory M. Lebovitz" > wrote: > >>Hey guys, >>In the spirit of trying to get to working group last call asap, what >>do you think about having a working session on Sunday evening or >>monday to try to close out some of the open items on TCP-AO BEFORE >>our monday 17:40 TCPM session? >> >>Do any of the following work? >>- Sunday 21:00 - 23:00 >>- Monday 15:10 - 17:30 >> >>If we can't get together before the TCPM mtg on Monday, how about we >>get a quick bite together on Monday after the meeting, and then >>spend a bit of time together on the document's open issues? >> >>(note: EKR's not here this week.) >> >>Gregory. >> >> >>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 From gregory.ietf@gmail.com Sun Jul 26 12:43:50 2009 Return-Path: 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 7FAF13A69C0 for ; Sun, 26 Jul 2009 12:43: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 cmAFxojjjG3q for ; Sun, 26 Jul 2009 12:43:49 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 77F693A6886 for ; Sun, 26 Jul 2009 12:43:49 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so681668eye.31 for ; Sun, 26 Jul 2009 12:43:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:x-mailer:date:to :from:subject:cc:in-reply-to:references:mime-version:content-type; bh=k3Zirwjy/W/WvFIMR0YXWDoiuph07Xl7VlgPvXI3xSc=; b=Py6QlrHxfyLYvr0D47JIvfIM1mbLMA3tKK1A3JX832IjYJYFWMgUDcfLtIT00VshVa EqDfst7AVyulSbveb5f01kqgqCiK3Q8if4WQy3fHkazFkMnqTwa2pm9Fredy1Uy/d+1h sRdgfofFFXhMlYc3/z4FG06YZE+yTB5DRtVcs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:date:to:from:subject:cc:in-reply-to:references :mime-version:content-type; b=mHAjuRuDICHlEBQ4eIZ+stvORLFLs8ithd7tzIJLmMqZHrW9IcNt+q3laHAvYGQY0W Fr/q/6OhFC2jCOs8bLOOG6EdGjrqwOtmhl8u+yYfl6TvKkcxDyjabn9iUWwg1x9/mZw+ ui5B1Kjr65ooJotfkmqq5d7XmzLauVqjcEe/4= Received: by 10.210.86.1 with SMTP id j1mr7249059ebb.61.1248637427864; Sun, 26 Jul 2009 12:43:47 -0700 (PDT) Received: from Gregory-T60.gmail.com (host-78-64-88-46.homerun.telia.com [78.64.88.46]) by mx.google.com with ESMTPS id 5sm4238482eyf.4.2009.07.26.12.43.44 (version=SSLv3 cipher=RC4-MD5); Sun, 26 Jul 2009 12:43:46 -0700 (PDT) Message-ID: <4a6cb1f2.0506d00a.33a2.18df@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 26 Jul 2009 12:43:37 -0700 To: "Polk, William T." , "mcgrew@cisco.com" From: "Gregory M. Lebovitz" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "housley@vigilsec.com" , "tcpm@ietf.org" , "Pasi.Eronen@nokia.com" Subject: Re: [tcpm] handling variable length keys in draft-lebovitz-ietf-tcpm-tcp-ao-crypto 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: , X-List-Received-Date: Sun, 26 Jul 2009 19:43:50 -0000 Tim, This is helpful, thanks. We will proceed toward WG LC with the mechanism as represented in draft v-01. If later, after further discussions within the cryptographic community, it is decided that the randomness extraction mechanism to go from a variable-length user-given string to a 128-bit key would be better accomplished some other way, then we can always do a quick -bis on the RFC and update the mechanism. That's easy enough for a small RFC like this. Gregory. At 08:40 AM 7/26/2009, Polk, William T. wrote: >Gregory, > >As requested, Pasi and I took a look at how >draft-lebovitz-ietf-tcpm-tcp-ao-crypto >handles the AES-CMAC case when the master key is not 128 bits. > >The method currently used (using AES-CMAC with a known fixed key as a >"randomness extractor") is basically the same as used in IKEv2 (RFC >4615 and 4434), except IKEv2 uses all-zeroes key (but the specific >value of the known fixed key shouldn't matter much -- just pick one). > >Using the same method in TCP-AO would be acceptable us, and seems >strongly preferable to requiring network admins to configure exactly >128 bit keys. > >Other methods of getting from "what the admin configures" to 128 bits >could work, too. Since the output of this step is *only* used as the >key for further PRF calculations (and for *nothing* else), the >requirements for it are very limited. If all keys were <= 128 bits, >even something trivial such as padding with zeroes would work -- so >this step doesn't even have to be one-way. Since we need to handle >also keys >128 bits, simple padding isn't enough, of course. If the WG >wants AES-only method, the one that's in the draft now seems OK to us. > >I hope this was helpful. > >Tim Polk >Pasi Eronen From ekr@networkresonance.com Sun Jul 26 16:22:50 2009 Return-Path: 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 9BC983A67DF for ; Sun, 26 Jul 2009 16:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.312 X-Spam-Level: X-Spam-Status: No, score=-1.312 tagged_above=-999 required=5 tests=[AWL=1.287, 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 5qiAVj+1C369 for ; Sun, 26 Jul 2009 16:22:49 -0700 (PDT) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 665353A67DA for ; Sun, 26 Jul 2009 16:22:49 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id B2E5050822; Sun, 26 Jul 2009 16:26:24 -0700 (PDT) Date: Sun, 26 Jul 2009 16:26:24 -0700 From: Eric Rescorla To: "Gregory M. Lebovitz" In-Reply-To: <4a6cb1f2.0506d00a.33a2.18df@mx.google.com> References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090726232624.B2E5050822@romeo.rtfm.com> Cc: "Pasi.Eronen@nokia.com" , "housley@vigilsec.com" , "mcgrew@cisco.com" , "Polk, William T." , "tcpm@ietf.org" Subject: Re: [tcpm] handling variable length keys in draft-lebovitz-ietf-tcpm-tcp-ao-crypto 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: , X-List-Received-Date: Sun, 26 Jul 2009 23:22:50 -0000 At Sun, 26 Jul 2009 12:43:37 -0700, Gregory M. Lebovitz wrote: > > Tim, > This is helpful, thanks. We will proceed toward WG LC with the > mechanism as represented in draft v-01. I'll be sending my comments on v-01 shortly, but I object to the magic number in the current mechanism. If we're going to use a magic key, it should be zero or some other anchor point. The use of a random number pulled out of the air is highly inappropriate in cryptographic systems [I refer you to the contrroversy over the DES S-boxes]. -Ekr > If later, after further discussions within the cryptographic > community, it is decided that the randomness extraction mechanism to > go from a variable-length user-given string to a 128-bit key would be > better accomplished some other way, then we can always do a quick > -bis on the RFC and update the mechanism. That's easy enough for a > small RFC like this. > Gregory. > > At 08:40 AM 7/26/2009, Polk, William T. wrote: > >Gregory, > > > >As requested, Pasi and I took a look at how > >draft-lebovitz-ietf-tcpm-tcp-ao-crypto > >handles the AES-CMAC case when the master key is not 128 bits. > > > >The method currently used (using AES-CMAC with a known fixed key as a > >"randomness extractor") is basically the same as used in IKEv2 (RFC > >4615 and 4434), except IKEv2 uses all-zeroes key (but the specific > >value of the known fixed key shouldn't matter much -- just pick one). > > > >Using the same method in TCP-AO would be acceptable us, and seems > >strongly preferable to requiring network admins to configure exactly > >128 bit keys. > > > >Other methods of getting from "what the admin configures" to 128 bits > >could work, too. Since the output of this step is *only* used as the > >key for further PRF calculations (and for *nothing* else), the > >requirements for it are very limited. If all keys were <= 128 bits, > >even something trivial such as padding with zeroes would work -- so > >this step doesn't even have to be one-way. Since we need to handle > >also keys >128 bits, simple padding isn't enough, of course. If the WG > >wants AES-only method, the one that's in the draft now seems OK to us. > > > >I hope this was helpful. > > > >Tim Polk > >Pasi Eronen > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From ekr@networkresonance.com Sun Jul 26 16:23:38 2009 Return-Path: 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 1D2013A68CF for ; Sun, 26 Jul 2009 16:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[AWL=1.103, 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 UQUF6tx-9xrP for ; Sun, 26 Jul 2009 16:23:36 -0700 (PDT) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id AAD2E3A683C for ; Sun, 26 Jul 2009 16:23:35 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 30A7650822 for ; Sun, 26 Jul 2009 16:27:11 -0700 (PDT) Date: Sun, 26 Jul 2009 16:27:11 -0700 From: Eric Rescorla To: tcpm@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090726232711.30A7650822@romeo.rtfm.com> Subject: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-05 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: , X-List-Received-Date: Sun, 26 Jul 2009 23:23:38 -0000 $Id: draft-ietf-tcpm-tcp-auth-opt-05-rev-real.txt,v 1.1 2009/07/26 22:18:40 ekr Exp $ This draft seems to resolve all my major technical issues. The comments below are primarily editorial. TECHNICAL The relationship between MKTs and traffic keys is shown in Figure Figure 3. Traffic keys are indicated with a "*". Note that every MKT derives all four traffic keys, regardless of whether all four are needed for a given connection. Section 7.2 provides further details on how traffic keys are derived. This seems like an unwarranted requirement. The keys are generated independently, so why make implementations gnerate keys they don't need? S 8.2. When a segment is received, the following algorithm (written in C) computes the SNE used in the MAC; an equivalent algorithm can be applied to the "SND" side: I know it seems like I'm nitpicking about this, but this algorithm is *not* valid C: # is not a comment character and C identifiers may not contain .s in the name. I suppose for the latter you could be arguing that these are structs, but then where's the defn of those? This seems like perfectly legitimate pseudocode, but if you're going to claim it's C, it really needs to be valid C. I would remove the claim. S 9.5. As I read this description, if an implementation receives a TCP segment with TCP-AO but it doesn't match any existing MKT, it should silently accept it. I don't agree with this. It should discard it. It's clearly not valid. i. If lengths differ, silently discard the segment. Log and/or signal the event as indicated in Section 9.3. I observe that this logging suggestion has the possibility to be a DoS in and of itself. If we're going to recommend logging, we need to recommend log throttling. EDITORIAL Abstract protects against replays even for long-lived TCP connections, and s/protects against replays/detects replayed segments/ set of MACs with minimal other system and operational changes. TCP-AO uses its own option identifier, even though used mutually exclusive of TCP MD5 on a given TCP connection. TCP-AO supports IPv6, and is I would just remove "even though..." This wording is clumsy and it probably isn't necessary at the level of the abstract S 2. Section 9.6). This document obsoletes the TCP MD5 option with a more general TCP Authentication Option (TCP-AO), to support the use of s/obsoletes/replaces/ This document is not intended to replace the use of the IPsec suite (IPsec and IKE) to protect TCP connections [RFC4301][RFC4306]. In fact, we recommend the use of IPsec and IKE, especially where IKE's level of existing support for parameter negotiation, session key negotiation, or rekeying are desired. TCP-AO is intended for use only where the IPsec suite would not be feasible, e.g., as has been suggested is the case to support some routing protocols, or in cases where keys need to be tightly coordinated with individual transport sessions [Be07]. I would remove this paragraph entirely, but if you with to retain it, I don't think it does that great a job of explaining the relationship here. Fundamentally people have complained that IPSec is too heavyweight. I would rewrite this as: This document is not intended to replace the use of the IPsec suite (IPsec and IKE) to protect TCP connections [RFC4301][RFC4306]. Rather, it is intended for the limited goal of providing traffic integrity and denial of service (DoS) protection for TCP connections in settings where a simpler solution than IPsec/IKE is desired. S 2.1 o TCP-AO ensures per-connection traffic keys as unique as the TCP connection itself, using TCP's initial sequence numbers (ISNs) for s/ensures/provides/ s/as unique/which are as unique/ o TCP-AO forces a change of computed MACs when a connection restarts, even when reusing a TCP socket pair (IP addresses and port numbers) [Be07]. I think I know what this is supposed to mean, but I think it's getting off into the weeds. However, if you want to say it, try: TCP-AO does not allow packets from one TCP connection to be replayed on another TCP connection, even if the connection parameters (IP addess and port numbers) are the same. S 4.2. The new TCP-AO option provides a superset of the capabilities of TCP MD5, and is minimal in the spirit of SP4 [SDNS88]. TCP-AO uses a new Kind field, and similar Length field to TCP MD5, a KeyID field, and a NextKeyID field as shown in Figure 2. Isn't a similar length field a requirement of the TCP options layout. I would also observe that SP4 is now over 20 years old and was never widely deployed even then, so references to the spirit of SP4 feel anachronistic. Values of 4 and other small values larger than 4 (e.g., indicating MACs of very short length) are of dubious utility but are not specifically prohibited. It's probably worth stating explicitly here that the MAC length is dictated by the MKT, not the option. S 5. I would rewrite this first paragraph as follows: TCP-AO makes use of two sets of keys: - Master Key Tuples (MKTs) are managed either manually or by a (future) key management protocols. They comprise a master key, the set of cryptographic algorithms to be used with that key, and the TCP connection identifiers to which the MKT applies. MKTs are never used directly to protect data but rather are used to derive traffic keys. Multiple MKTs may apply to a given connection, and are distinguished by a key identifier (key-id). - Traffic keys are used to compute the MAC for each TCP segment. Each TCP connection has a fresh set(s) of traffic keys which are automatically derived from the appropriate MKT(s) for that connection. The traffic key derivation function includes the TCP Initial Sequence numbers, resulting in a high probability that traffic keys will be unique, even if the IP address and TCP port are reused. S 5.1. >> MKT IDs MUST support any value, 0-255 inclusive. There are no reserved ID values. MKTs don't support anything. TCP-AO implementations do. This construct appears in a number of places in the document and should be replaced with "Implementations MUST suupport" Implementations are advised to keep master key values in a private, protected area of memory or other storage. I'm curious if anyone has a concrete notion of what this means. As I understand the situation, Cisco routers (for example) are a single monolothic process. How would you do this for a Cisco? >> The IDs of MKTs MUST NOT overlap where their TCP connection identifiers overlap. IDs aren't ranges. I would rewrite as: Any two MKTs with overlapping TCP connection identifiers [could we use "specifications" here more generally] MUST have distinct MKT IDs. S 5.2. MKTs don't derive (see above). I'm not sure this taxonomy and the use of send/receive is that useful here, since each side has its own send and receive. It gets doubly confusing when you say Note that the keys are directional. A given connection typically uses only three of these keys, because only one of the SYN keys is typically used. All four are used only when a connection goes through 'simultaneous open' [RFC793]. But as a practical matter, if Alice does an active open (connect) to Bob, she will generate: o Send_SYN_traffic_key o Send_other_traffic_key o Receive_other_traffic_key And Bob will generate: o Receive_SYN_traffic_key o Send_other_traffic_key o Receive_other_traffic_key But Bob's Receive keys are Alice's send keys and vice versa. So, I think for clarity, this should be rewritten not to talk about the connection but about the implementation's view. E.g., Each side of the connection needs up to four traffic keys: o Send_SYN_traffic_key o Receive_SYN_traffic_key o Send_other_traffic_key o Receive_other_traffic_key The only time when the *_SYN keys are used is when sending a SYN before having seen any packets from the other side. A given side typically uses only three of these keys, because only one of the SYN keys is typically used: either that node will be doing an active open and will need the Send_SYN_traffic key or will be doing a passive open and will need the Send_SYN_traffic key. All four are used only when a connection goes through 'simultaneous open' [RFC793]. S 5.3. This whole discussion of how many MKTs can match seems confusing and self-contradictory. My understanding of the rules is as follows: - Any outgoing packet, which has not yet been processed by TCP-AO, may match any number of MKTs, but each MKT must have a distinct key-id. Once that packet has been processed by AO, it must match only one MKT, determined by key-id. - Any incoming packet must match either one or zero MKTs. Is there any disagreement that this is correct? If so, I recommend rewriting the text to contain more or less just this. S 6. Current_Key and Next_Key seem confusing here because we're punning on the use of key. - Conenctions must store the current traffic keys (or enough information to regenerate them). They must also store the key-id needed to indicate those traffic keys. - The SNEs. There is no need to *store* Next_Key. It can be regenerated every time. What's required is simply that it appear on the wire. I don't see any need to store the MKTs with the connection either. They're "associated" in that they match, I suppose... S 7.1. o MAC_truncation - the number of bytes to truncate the output of the MAC to. This is indicated by the MAC algorithm, as specified in [ao-crypto]. I don't think it makes sense to talk about truncation here. The MACs produce a value that is crammed into the packet. If there's a separate spec that describes the MACs, it's not AO's business whether those MACs were produced by a truncation process. S 7.2. o Output_length - The desired output length of the KDF, i.e., the length to which the KDF's output will be truncated. In TCP-AO, the output_length is the PRF_truncation value of the MKT. This is specified by the KDF as described in [ao-crypto]. Everything from i.e., seems (1) superfluous and (2) isnufficiently general. Who says the PRF is truncated? The data used as input to the KDF combines TCP socket pair with the endpoint initial sequence numbers (ISNs) of a connection. This s/TCP socket/the TCP socket/ Traffic keys are directional, so "source" and "destaination" are s/destaination/destination/ S 7.3. of the TCP-AO option), or for coordinating rekeying during a connection. We assume out-of-band mechanisms for MKT establishment, It does now... We encourage users of TCP-AO to apply known techniques for generating appropriate MKTs, including the use of reasonable master key lengths, limited traffic key sharing, and limiting the duration of MKT use [RFC3562]. This also includes the use of per-connection nonces, as suggested in Section 7.2. This seems like old text. We don't encoruage people to use per-connection nonces, it's part of the protocol. I don't agree that a recommendation to limit lifetime is really that sensible. I would simply remove this entirely. S 9.5. a. Optionally, set a timer on the MKT indicated by the current_key and segment socket pair to ensure that the MKT cannot be deleted for 2*MSL. If a timer has already been set, reset the timer. This timer is advisory only. Removing MKTs with unexpired timers can result in a user-level warning, but is not prohibited. Implementation of timers is not required. b. Set Current_key to the NextKeyID MKT. I would reverse the order of these, since (a) is required and (b) is optional. S 10. Was TCP-MD5 Mandatory to Implement? If not, this shouldn't be either. Even if so, this seems like kind of an unwarranted requirement. -Ekr From ekr@networkresonance.com Sun Jul 26 16:43:16 2009 Return-Path: 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 AE1803A68E7 for ; Sun, 26 Jul 2009 16:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.634 X-Spam-Level: X-Spam-Status: No, score=-1.634 tagged_above=-999 required=5 tests=[AWL=0.965, 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 RPjbf0mA+Xz5 for ; Sun, 26 Jul 2009 16:43:15 -0700 (PDT) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id A6CE33A6866 for ; Sun, 26 Jul 2009 16:43:15 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 18D7A50822 for ; Sun, 26 Jul 2009 16:46:51 -0700 (PDT) Date: Sun, 26 Jul 2009 16:46:51 -0700 From: Eric Rescorla To: tcpm@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090726234651.18D7A50822@romeo.rtfm.com> Subject: [tcpm] Review of draft-lebovitz-ietf-tcpm-tcp-ao-crypto-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: , X-List-Received-Date: Sun, 26 Jul 2009 23:43:16 -0000 $Id: draft-lebovitz-ietf-tcpm-tcp-ao-crypto-01-rev.txt,v 1.1 2009/07/26 22:40:47 ekr Exp $ TECHNICAL S 3.1. This mixing of the KDF interface and the NIST 800-108 interface is extraordinarily confusing. To recap: The input to the KDF requires: - Master Key - Context (i.e., the conn-data) - Output length Now, as it happens, you're constructing your KDFs a la SP800-108, so you then use the relevant PRF with an input block constructed as: ( i || Label || Context || Output_Length) But that is not a meaningful part of the interface to the KDF as far as AO is concerned. If you were (for instance) to define a new TLS PRF based KDF, you would not use i internally because the TLS PRF generates an arbitrary length string. Again, it's important to distinguish between the TCP-AO requirements and what this document happens to do. S 3.1.3. Wait, I don't remember agreeing to this. I'm happy to use these as labels in soem IANA registry, byt people's UI is not our business. EDITORIAL S 2.2. The security issues driving the migration from SHA-1 to SHA-256 for digital signatures [HMAC-ATTACK] [HMAC-ATTACK]do not immediately render SHA-1 weak for this application of SHA-1 in HMAC mode. The security strength of SHA-1 HMACs should be sufficient for the foreseeable future, especially given that the tags are truncated to 96 bits. However, while it's clear that the attacks aren't practical on SHA-1, these types of analysis are mounting and could potentially pose a concern for HMAC forgery if they were significantly improved, over time. In anticipation of SHA-1's growing less dependable over time, but given its wide deployment and current strength, it is a "MUST" for TCP-AO today. AES-128 CMAC is considered to be far stronger algorithm, but may not yet have very wide implementation. It is also a "MUST" to implement, in order to drive vendors toward its use. This is simply not true. It's not at all clear that AES-128-CMAC is stronger than HMAC-SHA1, and I don't believe you could get anything like a consensus of cryptographers to say that it was. The MUST-MUST was taken on the basis of a WG hum. I'm fine with that, but this justification needs to be removed. S 2.3. (1) Key Derivation Functions (KDFs) which name a pseudorandom function (PRF) and use a Master_Key and some connection- specific Input with that PRF to produce Conn_Keys, the keys suitable for authenticating and integrity checking individual TCP segments. This is confusing. KDFs may or may not be constructed with PRFs. However, THESE KDFs are so constructed. If you're giong to have a document which applies to future KDFs, don't say PRF here. S 3.1. An octet of all zeros. An optional data field used to indicate a separation of different variable length data fields. This is just dangling. When invoked, a KDF runs a certain PRF, using the Master_Key as the seed, and Input as the message input and produces a result of Output_Length bits. This result may then be used as a cryptographic key for any algorithm which takes an Output_Length length key as its seed. A KDF MAY specify a maximum Output_Length parameter. Again, misplaced concreteness. Woah, I think my numbered list cut and paste here seems needs some major re-editing. It was intended for the mailing list, not for direct import into the document. S 3.1.1. It's a mistake to talk about "Output Length" as a property of the KDF. In principle, this KDF could generate any output length of your choice by using i=0, i=1, etc.. Why are you nailing it down? S 3.1.2. I strongly object to the use of this magic key string here. S 3.2. This whole Conn_Key(KDF) thing is confusing. What's it doing? From ekr@networkresonance.com Sun Jul 26 17:58:30 2009 Return-Path: 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 C72F53A6887 for ; Sun, 26 Jul 2009 17:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=0.772, 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 cBzi-9t9nnlM for ; Sun, 26 Jul 2009 17:58:30 -0700 (PDT) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 054513A6849 for ; Sun, 26 Jul 2009 17:58:29 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 4FE9150822 for ; Sun, 26 Jul 2009 18:02:05 -0700 (PDT) Date: Sun, 26 Jul 2009 18:02:05 -0700 From: Eric Rescorla To: tcpm@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090727010205.4FE9150822@romeo.rtfm.com> Subject: [tcpm] More on KDFs and PRFs 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: , X-List-Received-Date: Mon, 27 Jul 2009 00:58:30 -0000 Greg and I spent a while discussing the construction of the KDF in draft-lebovitz-ietf-tcpm-ao-crypto-01, and I think there's some confusion about what the right interfaces are. This document does two things: - Defines the interface and requirements for all KDFs - Provides two specific KDFs. INTERFACE REQUIREMENTS As far as the first job goes, the basic interface you want for a KDF is: KDF(Master_Key, Context, Output_Length) Where Output_Length describes the size of the key you're deriving with the KDF. A KDF of this sort can be used in a mix-and-match fashion with any target cryptographic algorithm (i.e., can generate keys for any algorithm) because it can generate an arbitrary length key. For instance, you could use an HMAC-SHA based KDF to generate keys for AES or RC4. In fact, this is precisely what both TLS and IPsec do because they need to generate keys for both a MAC algorithm and an encryption algorithm. So, KDFs for TCP-AO need to meet the above interface, with: - Master_Key == the key from the MKT - Context == the data block - Output_length == the right size key for the target integrity algorithm. Aside from the security requirements for a KDF, this is all you need to say in terms of requirements on future KDFs. SPECIFIC KDFS With that in mind, we now need to define concrete KDFs that meet the above interface spec. For concreteness, let's focus on the HMAC-SHA-1-based KDF. This KDF needs to match the above interface but we're otherwise unconstrained. However, there seems to be a desire to have a KDF that matches the (IMHO over-engineered) SP800-108 definitions, and this is quite possible within this framework. We simply need to arrange for the correct input values for the PRF that is the core of the KDF. The pseudocode for this looks like: hmac_sha1_kdf(MK, context, output_length) { needed = output_length i = 0 result = "" while(needed) { blk = i + "TCP-AO" + context + output_length result += HMAC-SHA1(MK, blk) needed -= 160 } return result } Note that if you generate a 160-bit key, this is computationally compatible with what's defined in 3.1.1. We just hide the Input construction under the covers of the KDF. This means we could do a non SP800-108 KDF, such as the TLS PRF, simply by saying TLS_PRF_KDF(MK, context, output_length) = TLS_PRF(MK, context)[0..output_length-1] Is this clear to people? Are there objections to this overall strategy? If not, I can provide text that implements it. -Ekr From gregory.ietf@gmail.com Mon Jul 27 01:24:32 2009 Return-Path: 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 F41EF3A6BF8 for ; Mon, 27 Jul 2009 01:24: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 w0AoeXCaBPjM for ; Mon, 27 Jul 2009 01:24:30 -0700 (PDT) Received: from mail-pz0-f197.google.com (mail-pz0-f197.google.com [209.85.222.197]) by core3.amsl.com (Postfix) with ESMTP id DEFFF3A69F5 for ; Mon, 27 Jul 2009 01:24:30 -0700 (PDT) Received: by pzk35 with SMTP id 35so175479pzk.32 for ; Mon, 27 Jul 2009 01:24: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:x-mailer:date:to :from:subject:in-reply-to:references:mime-version:content-type; bh=7Lbr3ZykVIORvinSNSWljLDdA8Ccx6J2ohWrCLdo9ME=; b=q1Dz1lgNMejyR/z4svmcDxKgjpwCUZ+mVHTGJDYe7Td2vW/zGTVW9XI9dd9cmiDDcm QBiJjMogKjJNIA5c5fxNEx6QbcDqcJ2IK+rzTecJTUvy0MLdZfgNrgW8Z9edLFrvJSRY DYOcV2RoigBhUFl26fAQZfnL1DLii9t6X6tPQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:date:to:from:subject:in-reply-to:references :mime-version:content-type; b=MlZoljI2JGNHyI0H4KqyZSa7QZiqI/OpnF4qkmae3ep9RtaCsjwh8lRGX78ZLKe/jq YfHaDi5+7Wgz69qdQLHtMdydPROEf9ynPK3PXJReFOtjAFC+HXuzkv7HBcsMF/arG0k4 BOHR9tKoHTYzVtDs40Gdvy301e8AKvc3h6GPY= Received: by 10.115.55.17 with SMTP id h17mr9510433wak.58.1248683069057; Mon, 27 Jul 2009 01:24:29 -0700 (PDT) Received: from Gregory-T60.gmail.com (dhcp-14dc.meeting.ietf.org [130.129.20.220]) by mx.google.com with ESMTPS id j15sm12953237waf.16.2009.07.27.01.24.26 (version=SSLv3 cipher=RC4-MD5); Mon, 27 Jul 2009 01:24:28 -0700 (PDT) Message-ID: <4a6d643c.0fba720a.10e1.ffffd732@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 27 Jul 2009 01:24:21 -0700 To: Eric Rescorla ,tcpm@ietf.org From: "Gregory M. Lebovitz" In-Reply-To: <20090726234651.18D7A50822@romeo.rtfm.com> References: <20090726234651.18D7A50822@romeo.rtfm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [tcpm] Review of draft-lebovitz-ietf-tcpm-tcp-ao-crypto-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: , X-List-Received-Date: Mon, 27 Jul 2009 08:24:32 -0000 inline... At 04:46 PM 7/26/2009, Eric Rescorla wrote: >$Id: draft-lebovitz-ietf-tcpm-tcp-ao-crypto-01-rev.txt,v 1.1 >2009/07/26 22:40:47 ekr Exp $ > >TECHNICAL >S 3.1. >This mixing of the KDF interface and the NIST 800-108 interface >is extraordinarily confusing. I'm not sure it's "mixing". Isn't one is a subset of the other? The KDF interface is an interface. The NIST thing is the actual concatenated construct which fulfills the Context. >To recap: >The input to the KDF requires: > >- Master Key >- Context (i.e., the conn-data) it's not just the Data_Block (updated lingo, per auth-opt-05). In order to follow SP800-180, the context is a few things concatenated, and Data_Block is one of the things. >- Output length > >Now, as it happens, you're constructing your KDFs a la SP800-108, >so you then use the relevant PRF with an input block constructed >as: > > ( i || Label || Context || Output_Length) > >But that is not a meaningful part of the interface to the KDF >as far as AO is concerned. If you were (for instance) to define >a new TLS PRF based KDF, you would not use i internally because >the TLS PRF generates an arbitrary length string. Again, it's >important to distinguish between the TCP-AO requirements and >what this document happens to do. I think this document is NOT just the generic interface - that's covered in auth-opt-05. This document reminds us of the generic interface, and then specifically defines how to do the SHA1 and AES-128 KDFs themselves. That's why we made it specific. Maybe I'm not understanding you? >S 3.1.3. >Wait, I don't remember agreeing to this. I'm happy to use these >as labels in soem IANA registry, byt people's UI is not our >business. This is the years of IKE interop work which motivates this. Clarifying the UI representations to make it very easy on operators is a good thing. Others opinions on this UI guidance? >EDITORIAL >S 2.2. > > The security issues driving the migration from SHA-1 to SHA-256 for > digital signatures [HMAC-ATTACK] [HMAC-ATTACK]do not immediately > render SHA-1 weak for this application of SHA-1 in HMAC mode. The > security strength of SHA-1 HMACs should be sufficient for the > foreseeable future, especially given that the tags are truncated to > 96 bits. However, while it's clear that the attacks aren't practical > on SHA-1, these types of analysis are mounting and could potentially > pose a concern for HMAC forgery if they were significantly improved, > over time. In anticipation of SHA-1's growing less dependable over > time, but given its wide deployment and current strength, it is a > "MUST" for TCP-AO today. AES-128 CMAC is considered to be far > stronger algorithm, but may not yet have very wide implementation. > It is also a "MUST" to implement, in order to drive vendors toward > its use. > >This is simply not true. It's not at all clear that AES-128-CMAC is >stronger than HMAC-SHA1, and I don't believe you could get anything >like a consensus of cryptographers to say that it was. The >MUST-MUST was taken on the basis of a WG hum. I'm fine with that, >but this justification needs to be removed. Since this is others' text, I'll let those others respond. >S 2.3. > (1) Key Derivation Functions (KDFs) which name a pseudorandom > function (PRF) and use a Master_Key and some connection- > specific Input with that PRF to produce Conn_Keys, the keys > suitable for authenticating and integrity checking > individual TCP segments. > >This is confusing. KDFs may or may not be constructed with PRFs. >However, THESE KDFs are so constructed. If you're giong to have >a document which applies to future KDFs, don't say PRF here. it does say "which name", not "MUST name". Doesn't this cover your point? >S 3.1. > An octet of all zeros. An optional data field > used to indicate a separation of different > variable length data fields. > >This is just dangling. Done. > When invoked, a KDF runs a certain PRF, using the Master_Key as the > seed, and Input as the message input and produces a result of > Output_Length bits. This result may then be used as a cryptographic > key for any algorithm which takes an Output_Length length key as its > seed. A KDF MAY specify a maximum Output_Length parameter. > >Again, misplaced concreteness. > > >Woah, I think my numbered list cut and paste here seems needs some >major re-editing. It was intended for the mailing list, not for >direct import into the document. send text. >S 3.1.1. > >It's a mistake to talk about "Output Length" as a property of the KDF. >In principle, this KDF could generate any output length of your >choice by using i=0, i=1, etc.. Why are you nailing it down? > > >S 3.1.2. >I strongly object to the use of this magic key string here. discussed with Tim Polk. done. We're back to 0^128 as the key in -02. >S 3.2. >This whole Conn_Key(KDF) thing is confusing. What's it doing? Honestly, I thought that was the notation you requested upon review of -00... I'll ping you offline. I'm posting -02 now, because there was naming I needed to update to stay in sync with auth-opt-05 anyway. Thx for the review, Gregory. >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www.ietf.org/mailman/listinfo/tcpm From gregory.ietf@gmail.com Mon Jul 27 01:29:27 2009 Return-Path: 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 981023A68CF for ; Mon, 27 Jul 2009 01:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YW6I-H69q3nT for ; Mon, 27 Jul 2009 01:29:26 -0700 (PDT) Received: from mail-px0-f194.google.com (mail-px0-f194.google.com [209.85.216.194]) by core3.amsl.com (Postfix) with ESMTP id 3FBBB28C108 for ; Mon, 27 Jul 2009 01:28:50 -0700 (PDT) Received: by pxi32 with SMTP id 32so1570922pxi.29 for ; Mon, 27 Jul 2009 01:28: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:x-mailer:date:to :from:subject:cc:in-reply-to:references:mime-version:content-type; bh=Q17idZyXvWFhpsdrUyQI0CGLag3cpcl7010rRtUvQLI=; b=Saa2xvi3wqQPZqOW3fwkoZAes2D5npLFu3loHE9LLrwudm2AcTGY4xWrzF9RXP2TNQ gZ2/D4Abjrbp+3KG+ZOqKKBUx0NQXKesfmzxWFO6vhJt3pNcKjYEU3/VI3nt7p1uMWrf y9/mWaq4JOn8A5rizU1jGCzYrIsZH5XK2EkBA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:date:to:from:subject:cc:in-reply-to:references :mime-version:content-type; b=oTtXcqt70Kkl4VL1/EMVuZ3puyVJzqI07imGNUAdQOWMJU7izF+0pmVzyU90R6M1tl MBQy5QHd6L0p4lPJfXiuW7gAER2m3sj4B2K+y8lCAMsdd49SoCgo3VUHu4QlXiaya2pQ h4YRfQKDxqtw7MITOQJAh4caafL8Odb83z6Gw= Received: by 10.114.95.20 with SMTP id s20mr9520134wab.114.1248683329150; Mon, 27 Jul 2009 01:28:49 -0700 (PDT) Received: from Gregory-T60.gmail.com (dhcp-14dc.meeting.ietf.org [130.129.20.220]) by mx.google.com with ESMTPS id m25sm13076789waf.9.2009.07.27.01.28.46 (version=SSLv3 cipher=RC4-MD5); Mon, 27 Jul 2009 01:28:48 -0700 (PDT) Message-ID: <4a6d6540.19bd720a.7437.ffffd84b@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 27 Jul 2009 01:28:41 -0700 To: "Polk, William T." ,Eric Rescorla From: "Gregory M. Lebovitz" In-Reply-To: References: <20090726232624.B2E5050822@romeo.rtfm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "Pasi.Eronen@nokia.com" , "tcpm@ietf.org" , "mcgrew@cisco.com" , "housley@vigilsec.com" Subject: Re: [tcpm] handling variable length keys in draft-lebovitz-ietf-tcpm-tcp-ao-crypto 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: , X-List-Received-Date: Mon, 27 Jul 2009 08:29:27 -0000 ack. change made in crypto-02. (I'm feeling like a ping-pong ball here -- take it out... no, put it in... no, out... no, in... -- but such is life for an I-D editor ;-) Gregory. At 11:40 PM 7/26/2009, Polk, William T. wrote: >Ekr, > >Your objections on the magic number are well taken. Since zeroes would >be a holdover from 4615 and 4434, that value won't introduce any new >issues. I think that would be the best course of action. > >Tim > >________________________________________ >From: Eric Rescorla [ekr@networkresonance.com] >Sent: Sunday, July 26, 2009 7:26 PM >To: Gregory M. Lebovitz >Cc: Polk, William T.; mcgrew@cisco.com; housley@vigilsec.com; >tcpm@ietf.org; Pasi.Eronen@nokia.com >Subject: Re: [tcpm] handling variable length keys in >draft-lebovitz-ietf-tcpm-tcp-ao-crypto > >At Sun, 26 Jul 2009 12:43:37 -0700, >Gregory M. Lebovitz wrote: > > > > Tim, > > This is helpful, thanks. We will proceed toward WG LC with the > > mechanism as represented in draft v-01. > >I'll be sending my comments on v-01 shortly, but I object to >the magic number in the current mechanism. If we're going to >use a magic key, it should be zero or some other anchor point. >The use of a random number pulled out of the air is highly >inappropriate in cryptographic systems [I refer you to the >contrroversy over the DES S-boxes]. > >-Ekr > > > > > If later, after further discussions within the cryptographic > > community, it is decided that the randomness extraction mechanism to > > go from a variable-length user-given string to a 128-bit key would be > > better accomplished some other way, then we can always do a quick > > -bis on the RFC and update the mechanism. That's easy enough for a > > small RFC like this. > > > > Gregory. > > > > At 08:40 AM 7/26/2009, Polk, William T. wrote: > > >Gregory, > > > > > >As requested, Pasi and I took a look at how > > >draft-lebovitz-ietf-tcpm-tcp-ao-crypto > > >handles the AES-CMAC case when the master key is not 128 bits. > > > > > >The method currently used (using AES-CMAC with a known fixed key as a > > >"randomness extractor") is basically the same as used in IKEv2 (RFC > > >4615 and 4434), except IKEv2 uses all-zeroes key (but the specific > > >value of the known fixed key shouldn't matter much -- just pick one). > > > > > >Using the same method in TCP-AO would be acceptable us, and seems > > >strongly preferable to requiring network admins to configure exactly > > >128 bit keys. > > > > > >Other methods of getting from "what the admin configures" to 128 bits > > >could work, too. Since the output of this step is *only* used as the > > >key for further PRF calculations (and for *nothing* else), the > > >requirements for it are very limited. If all keys were <= 128 bits, > > >even something trivial such as padding with zeroes would work -- so > > >this step doesn't even have to be one-way. Since we need to handle > > >also keys >128 bits, simple padding isn't enough, of course. If the WG > > >wants AES-only method, the one that's in the draft now seems OK to us. > > > > > >I hope this was helpful. > > > > > >Tim Polk > > >Pasi Eronen > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm From gregory.ietf@gmail.com Mon Jul 27 01:48:19 2009 Return-Path: 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 AD77628C22A for ; Mon, 27 Jul 2009 01:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_37=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 3jkenAv-eoES for ; Mon, 27 Jul 2009 01:48:18 -0700 (PDT) Received: from mail-px0-f194.google.com (mail-px0-f194.google.com [209.85.216.194]) by core3.amsl.com (Postfix) with ESMTP id DF91228C1D7 for ; Mon, 27 Jul 2009 01:48:18 -0700 (PDT) Received: by pxi32 with SMTP id 32so1578655pxi.29 for ; Mon, 27 Jul 2009 01:48:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:x-mailer:date:to :from:subject:mime-version:content-type; bh=u4YtZVsws8baQZMIcZvqxFVTqMf+6L5HpKBcXjVAQFk=; b=HpnG/x2k+G3GFes0zXqd/aVGWugIdWepC27xTrNJ6evI2jD4dQnNCHjVf4iK5gmy8D NO8XtWe+SzmLkUIYJAUW/3KbDM7VUex0Cv3V+IAPnOLZWO568FnseyflRxWAeOCXcQQl i9hgZje+LUXCE9QVuQNv9lXhaVGsBxcIMQGbw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:date:to:from:subject:mime-version:content-type; b=ESIZkLk+jHZkBrS4LNicpNfJ7Q7WoQu34DtIUb0JNe+Y12kqXZ1msJfml1MqIEHwr5 sh9X2eu7IN1SegTXTKVsTb+oLwrJJQ1ZTKk7zeS0RJyLj2U+/NgZlFMDxU2NfIN8ivDM /vSeEaTusvbnQB0BH+M68JAbHJKaRvIqIf/KE= Received: by 10.114.113.1 with SMTP id l1mr9443821wac.22.1248684498364; Mon, 27 Jul 2009 01:48:18 -0700 (PDT) Received: from Gregory-T60.gmail.com (dhcp-14dc.meeting.ietf.org [130.129.20.220]) by mx.google.com with ESMTPS id k37sm12993182waf.42.2009.07.27.01.48.16 (version=SSLv3 cipher=RC4-MD5); Mon, 27 Jul 2009 01:48:17 -0700 (PDT) Message-ID: <4a6d69d1.25bb720a.1024.ffffe510@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 27 Jul 2009 01:48:10 -0700 To: tcpm@ietf.org From: "Gregory M. Lebovitz" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [tcpm] Fwd: New Version Notification for draft-lebovitz-ietf-tcpm-tcp-ao-crypto-02 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: , X-List-Received-Date: Mon, 27 Jul 2009 08:48:19 -0000 TCPM, I did a quick turn last night to clean up the ao-crypto draft before the WG today. Here is the changes (pasted from Sect 4, Change History, of the I-D: lebovitz...-02 - 3rd submission o cleaned up explanation in 3.1.2 o in 3.1.2, changed the key extractor mechanism back, from using an alphanumeric string for the fixed key C to use 0^128 as the key (as it was in -00) (Polk & Ekr) o deleted cut-and-paste error text from sect 3.1 between "label" and "context" o changed "conn_key" to "traffic_key" throughout, to follow auth- opt-05 o changed "tsad" to "mkt" throughout, to follow auth-opt-05 o changed "conn_block" to "data_block" throughout, to follow auth- opt-05 See you later today, Gregory. >Delivered-To: gregory.ietf@gmail.com >Authentication-Results: mx.google.com; spf=neutral (google.com: >64.170.98.32 is neither permitted nor denied by best guess record >for domain of wwwrun@core3.amsl.com) smtp.mail=wwwrun@core3.amsl.com >From: IETF I-D Submission Tool >To: gregory.ietf@gmail.com >Subject: New Version Notification for > draft-lebovitz-ietf-tcpm-tcp-ao-crypto-02 >Date: Mon, 27 Jul 2009 01:44:11 -0700 (PDT) > > >A new version of I-D, draft-lebovitz-ietf-tcpm-tcp-ao-crypto-02.txt >has been successfuly submitted by Gregory Lebovitz and posted to the >IETF repository. > >Filename: draft-lebovitz-ietf-tcpm-tcp-ao-crypto >Revision: 02 >Title: Cryptographic Algorithms, Use, & Implementation >Requirments for TCP Authentication Option >Creation_date: 2009-07-27 >WG ID: Independent Submission >Number_of_pages: 16 > >Abstract: >The TCP Authentication Option, TCP-AO, relies on security algorithms >to provide authentication between two end-points. There are many >such algorithms available, and two TCP-AO systems cannot interoperate >unless they are using the same algorithm(s). This document specifies >the algorithms and attributes that can be used in TCP-AO's current >manual keying mechanism. > > > > >The IETF Secretariat. +++++++++++++++++++++++ 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 From touch@ISI.EDU Mon Jul 27 04:34:48 2009 Return-Path: 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 BB9813A69D2 for ; Mon, 27 Jul 2009 04:34: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 p4Gbr5SeOsb5 for ; Mon, 27 Jul 2009 04:34:47 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 3555228C138 for ; Mon, 27 Jul 2009 04:34:47 -0700 (PDT) Received: from [130.129.22.106] (dhcp-166a.meeting.ietf.org [130.129.22.106]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n6RBYNQ5017963; Mon, 27 Jul 2009 04:34:25 -0700 (PDT) Message-ID: <4A6D90BF.4050301@isi.edu> Date: Mon, 27 Jul 2009 04:34:23 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Eric Rescorla References: <20090726232711.30A7650822@romeo.rtfm.com> In-Reply-To: <20090726232711.30A7650822@romeo.rtfm.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-05 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: , X-List-Received-Date: Mon, 27 Jul 2009 11:34:48 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Eric, Agreed on the editorial feedback, and thanks. Notes on the technical issues below - I think we agree on most. Joe Eric Rescorla wrote: > $Id: draft-ietf-tcpm-tcp-auth-opt-05-rev-real.txt,v 1.1 2009/07/26 22:18:40 ekr Exp $ > > This draft seems to resolve all my major technical issues. > The comments below are primarily editorial. > > > TECHNICAL > The relationship between MKTs and traffic keys is shown in Figure > Figure 3. Traffic keys are indicated with a "*". Note that every MKT > derives all four traffic keys, regardless of whether all four are > needed for a given connection. Section 7.2 provides further details > on how traffic keys are derived. > > This seems like an unwarranted requirement. The keys are generated > independently, so why make implementations gnerate keys they don't > need? Agreed - I was trying to say that every MKT *can* derive any of the four traffic keys, not that all four *are* always derived. ... > S 9.5. > As I read this description, if an implementation receives a TCP segment > with TCP-AO but it doesn't match any existing MKT, it should silently > accept it. I don't agree with this. It should discard it. It's clearly > not valid. Agreed. The original intent was to allow communication with an endpoint that didn't have an MKT, but that clearly won't work because MKTs cover both directions, and thus the ACKs won't be received anyway. > i. If lengths differ, silently discard the segment. Log > and/or signal the event as indicated in Section 9.3. > > I observe that this logging suggestion has the possibility to be > a DoS in and of itself. If we're going to recommend logging, > we need to recommend log throttling. I thought we had; I'll check and add or add a reminder. > EDITORIAL ... > S 2. > Section 9.6). This document obsoletes the TCP MD5 option with a more > general TCP Authentication Option (TCP-AO), to support the use of > > s/obsoletes/replaces/ I thought we needed to use the term "obsoletes" somewhere. Maybe this is the right sentence to do so, maybe not. ... > Values of 4 and other small values larger than 4 (e.g., indicating > MACs of very short length) are of dubious utility but are not > specifically prohibited. > > It's probably worth stating explicitly here that the MAC length is > dictated by the MKT, not the option. The length of the MAC field is dictated by the option. If the option says the MAC is 70 bytes, and the MKT says it should be 72, then the packet would fail authentication. I'll correct to call this "indicating MAC fields of very short length" ... > Implementations are advised to keep master key values in a > private, protected area of memory or other storage. > > I'm curious if anyone has a concrete notion of what this means. As I > understand the situation, Cisco routers (for example) are a single > monolothic process. How would you do this for a Cisco? Keep the keys in an area that non-operator processes can't get to without explicit permission or override. ... ... > S 5.3. > This whole discussion of how many MKTs can match seems confusing > and self-contradictory. > > My understanding of the rules is as follows: > > - Any outgoing packet, which has not yet been processed by TCP-AO, > may match any number of MKTs, but each MKT must have a distinct > key-id. Once that packet has been processed by AO, it must > match only one MKT, determined by key-id. If it matches multiple MKTs, the question is whether there is a preferred one or not. I had thought there was, but if not then this text can be used. If it matches no MKTs, TCP-AO is not used. > - Any incoming packet must match either one or zero MKTs. If it matches zero MKTs and has TCP-AO option, then it must be dropped. If it matches one or more MKTs and has no TCP-AO option, then it must be dropped. > Is there any disagreement that this is correct? If so, I recommend > rewriting the text to contain more or less just this. As per above, the full set of cases needs to be discussed here. Granted the text can be revised to avoid "preferred" keys as per above. ... > S 6. > Current_Key and Next_Key seem confusing here because we're punning > on the use of key. Agreed - should change that to "current_MKT" and "next_MKT". > - Conenctions must store the current traffic keys (or enough information > to regenerate them). They must also store the key-id needed to indicate > those traffic keys. > > - The SNEs. > > There is no need to *store* Next_Key. It can be regenerated every time. > What's required is simply that it appear on the wire. I don't see any > need to store the MKTs with the connection either. They're "associated" > in that they match, I suppose... Next_key is a value indicated by the user. It needs to be stored somewhere. Connections need to either store the traffic keys or the info to generate them. The latter would include the ISNs. I'll list the info needed to generate them instead of storing the keys. > S 7.1. > > o MAC_truncation - the number of bytes to truncate the output of the > MAC to. This is indicated by the MAC algorithm, as specified in > [ao-crypto]. > > I don't think it makes sense to talk about truncation here. > The MACs produce a value that is crammed into the packet. > If there's a separate spec that describes the MACs, it's not > AO's business whether those MACs were produced by a truncation process. We need to describe the function as a call; the details are provided in Gregory's doc. Since truncation is an argument to the call, I need to indicate it. Otherwise, we need two versions: 1) the API between TCP-AO and Gregory's doc 2) the API between Gregory's doc and the MAC alg. Gregory's doc focuses on parameters; TCP-AO describes the algs and interfaces, so I think it's important to include this here - even though it's an opaque 'pass-through' value. > S 7.2. > o Output_length - The desired output length of the KDF, i.e., the > length to which the KDF's output will be truncated. In TCP-AO, the > output_length is the PRF_truncation value of the MKT. This is > specified by the KDF as described in [ao-crypto]. > > Everything from i.e., seems (1) superfluous and (2) isnufficiently > general. Who says the PRF is truncated? Again, I was describing a general alg from Gregory's doc. If that's never an arg to a PRF, then we can omit it in TCP-AO. ... > We encourage users of TCP-AO to apply known techniques for generating > appropriate MKTs, including the use of reasonable master key lengths, > limited traffic key sharing, and limiting the duration of MKT use > [RFC3562]. This also includes the use of per-connection nonces, as > suggested in Section 7.2. > > This seems like old text. We don't encoruage people to use per-connection > nonces, it's part of the protocol. ... "It" here is TCP-AO, not the user. That should be revised to be more clear. > S 9.5. > a. Optionally, set a timer on the MKT indicated by > the current_key and segment socket pair to > ensure that the MKT cannot be deleted for 2*MSL. > If a timer has already been set, reset the > timer. > > This timer is advisory only. Removing MKTs with > unexpired timers can result in a user-level > warning, but is not prohibited. Implementation > of timers is not required. > > b. Set Current_key to the NextKeyID MKT. > > I would reverse the order of these, since (a) is required and (b) is > optional. The timer is optional, and shifting keyIDs is required. If we shift the order, we would need an intermediate value for current_key, since we operate on current_key in (a). The order described avoids that. I don't see why we'd reverse the order of these as a result. > S 10. > Was TCP-MD5 Mandatory to Implement? If not, this shouldn't be either. > Even if so, this seems like kind of an unwarranted requirement. Hard to say. RFC793 says all options must be implemented, and separates that claim from the list of "currently specified" options. Whatever the WG feels is appropriate here is fine. IMO, it can't just be optional; it should be manditory at least in some environments. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkptkL8ACgkQE5f5cImnZrutgQCeMYlz00TM43zbPeLsLurLb+1i PasAn0T0Ct/BbBFBlx6grIkIKMcsln8M =bGeu -----END PGP SIGNATURE----- From root@core3.amsl.com Mon Jul 27 05:15:01 2009 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A82233A68FC; Mon, 27 Jul 2009 05:15: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: <20090727121501.A82233A68FC@core3.amsl.com> Date: Mon, 27 Jul 2009 05:15:01 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-rfc2581bis-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: , X-List-Received-Date: Mon, 27 Jul 2009 12:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : TCP Congestion Control Author(s) : M. Allman, et al. Filename : draft-ietf-tcpm-rfc2581bis-06.txt Pages : 17 Date : 2009-07-27 This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods. This document obsoletes RFC 2581. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc2581bis-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-rfc2581bis-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-27050819.I-D@ietf.org> --NextPart-- From touch@ISI.EDU Mon Jul 27 05:56:22 2009 Return-Path: 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 B257628C213 for ; Mon, 27 Jul 2009 05:56:22 -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 QWH6YYXgM-Vs for ; Mon, 27 Jul 2009 05:56:20 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id D4D8F3A6802 for ; Mon, 27 Jul 2009 05:56:20 -0700 (PDT) Received: from [128.9.176.38] (c1-vpn8.isi.edu [128.9.176.38]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n6RCu3U2008162; Mon, 27 Jul 2009 05:56:05 -0700 (PDT) Message-ID: <4A6DA3E3.1080607@isi.edu> Date: Mon, 27 Jul 2009 05:56:03 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: tcpm@ietf.org References: <20090727121501.A82233A68FC@core3.amsl.com> In-Reply-To: <20090727121501.A82233A68FC@core3.amsl.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-rfc2581bis-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: , X-List-Received-Date: Mon, 27 Jul 2009 12:56:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, all, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. > > > Title : TCP Congestion Control > Author(s) : M. Allman, et al. > Filename : draft-ietf-tcpm-rfc2581bis-06.txt > Pages : 17 > Date : 2009-07-27 > > This document defines TCP's four intertwined congestion control > algorithms: slow start, congestion avoidance, fast retransmit, and > fast recovery. In addition, the document specifies how TCP should > begin transmission after a relatively long idle period, as well as > discussing various acknowledgment generation methods. This document > obsoletes RFC 2581. FWIW, regarding the discussion of the long idle period: The algorithm used is based on a footnote in the appendix of an unpublished extension of Van's 1988 Sigcomm paper. Amy Hughes, John Heidemann, and I noted this a few years ago on this list in the following I-D: http://www.isi.edu/touch/pubs/draft-hughes-restart-00.txt Here is a link to the 1988 Sigcomm paper: http://www.acm.org/pubs/articles/proceedings/comm/52324/p314-jacobson/p314-jacobson.pdf The Sigcomm version was only 16 pages long. The word "idle" does not appear anywhere in it. FWIW, see also our I-D for a few ways to deal with the issue. The problem is really that the sender is accumulating permission to burst, which just using a timer cannot address. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkpto+MACgkQE5f5cImnZrtdUACg9VSBT9UVxOpA6ciJoDF/C7K1 5SUAn32ZTJmCC8uCNIPtwiTwvBfUma9x =cKug -----END PGP SIGNATURE----- From ekr@networkresonance.com Mon Jul 27 07:36:19 2009 Return-Path: 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 0B9E63A699E for ; Mon, 27 Jul 2009 07:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.589 X-Spam-Level: X-Spam-Status: No, score=-0.589 tagged_above=-999 required=5 tests=[AWL=-0.607, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 wZk8IS-OXq+O for ; Mon, 27 Jul 2009 07:36:18 -0700 (PDT) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id EF5783A68FD for ; Mon, 27 Jul 2009 07:36:17 -0700 (PDT) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 032251D2EE1; Mon, 27 Jul 2009 07:39:05 -0700 (PDT) Date: Mon, 27 Jul 2009 07:39:05 -0700 From: Eric Rescorla To: Joe Touch In-Reply-To: <4A6D90BF.4050301@isi.edu> References: <20090726232711.30A7650822@romeo.rtfm.com> <4A6D90BF.4050301@isi.edu> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090727143906.032251D2EE1@kilo.networkresonance.com> Cc: tcpm@ietf.org Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-05 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: , X-List-Received-Date: Mon, 27 Jul 2009 14:36:19 -0000 At Mon, 27 Jul 2009 04:34:23 -0700, > > This seems like an unwarranted requirement. The keys are generated > > independently, so why make implementations gnerate keys they don't > > need? > > Agreed - I was trying to say that every MKT *can* derive any of the four > traffic keys, not that all four *are* always derived. OK. So this may be editorial only. > > EDITORIAL > ... > > S 2. > > Section 9.6). This document obsoletes the TCP MD5 option with a more > > general TCP Authentication Option (TCP-AO), to support the use of > > > > s/obsoletes/replaces/ > > I thought we needed to use the term "obsoletes" somewhere. Maybe this is > the right sentence to do so, maybe not. Well, I think we could rewrite this as. "This document obsoletes the TCP MD5 option. It replaces it with..." > ... > > Values of 4 and other small values larger than 4 (e.g., indicating > > MACs of very short length) are of dubious utility but are not > > specifically prohibited. > > > > It's probably worth stating explicitly here that the MAC length is > > dictated by the MKT, not the option. > > The length of the MAC field is dictated by the option. If the option > says the MAC is 70 bytes, and the MKT says it should be 72, then the > packet would fail authentication. > > I'll correct to call this "indicating MAC fields of very short length" AGreed. I'm just mentioning this so people don't think that you can specify a shorter MAC in the option and have it validate. > ... > > Implementations are advised to keep master key values in a > > private, protected area of memory or other storage. > > > > I'm curious if anyone has a concrete notion of what this means. As I > > understand the situation, Cisco routers (for example) are a single > > monolothic process. How would you do this for a Cisco? > > Keep the keys in an area that non-operator processes can't get to > without explicit permission or override. Sure. I'm just observing that this isn't true on some systems which only have one level of securuty. > > S 5.3. > > This whole discussion of how many MKTs can match seems confusing > > and self-contradictory. > > > > My understanding of the rules is as follows: > > > > - Any outgoing packet, which has not yet been processed by TCP-AO, > > may match any number of MKTs, but each MKT must have a distinct > > key-id. Once that packet has been processed by AO, it must > > match only one MKT, determined by key-id. > > If it matches multiple MKTs, the question is whether there is a > preferred one or not. I had thought there was, but if not then this text > can be used. I had sort of assumed that this was an invariant--that the system had to pick a preference if there were any. > > There is no need to *store* Next_Key. It can be regenerated every time. > > What's required is simply that it appear on the wire. I don't see any > > need to store the MKTs with the connection either. They're "associated" > > in that they match, I suppose... > > Next_key is a value indicated by the user. It needs to be stored somewhere. Sure, but it could be a global setting. > > S 7.1. > > > > o MAC_truncation - the number of bytes to truncate the output of the > > MAC to. This is indicated by the MAC algorithm, as specified in > > [ao-crypto]. > > > > I don't think it makes sense to talk about truncation here. > > The MACs produce a value that is crammed into the packet. > > If there's a separate spec that describes the MACs, it's not > > AO's business whether those MACs were produced by a truncation process. > > We need to describe the function as a call; the details are provided in > Gregory's doc. Since truncation is an argument to the call, I need to > indicate it. Right, I don't think it should be an argument to the call--so it's Greg's fault :) > > S 9.5. > > a. Optionally, set a timer on the MKT indicated by > > the current_key and segment socket pair to > > ensure that the MKT cannot be deleted for 2*MSL. > > If a timer has already been set, reset the > > timer. > > > > This timer is advisory only. Removing MKTs with > > unexpired timers can result in a user-level > > warning, but is not prohibited. Implementation > > of timers is not required. > > > > b. Set Current_key to the NextKeyID MKT. > > > > I would reverse the order of these, since (a) is required and (b) is > > optional. > > The timer is optional, and shifting keyIDs is required. > > If we shift the order, we would need an intermediate value for > current_key, since we operate on current_key in (a). The order described > avoids that. I don't see why we'd reverse the order of these as a result. OK. I just think mndatory before optional. > > S 10. > > Was TCP-MD5 Mandatory to Implement? If not, this shouldn't be either. > > Even if so, this seems like kind of an unwarranted requirement. > > Hard to say. RFC793 says all options must be implemented, and separates > that claim from the list of "currently specified" options. Whatever the > WG feels is appropriate here is fine. > > IMO, it can't just be optional; it should be manditory at least in some > environments. I'm not going to go to the wall on this one. What do others think? -Ekr From ekr@networkresonance.com Mon Jul 27 07:54:07 2009 Return-Path: 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 C45A63A6980 for ; Mon, 27 Jul 2009 07:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.538 X-Spam-Level: X-Spam-Status: No, score=-0.538 tagged_above=-999 required=5 tests=[AWL=-0.556, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 rE6SgHtTUvCW for ; Mon, 27 Jul 2009 07:54:07 -0700 (PDT) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id DEDA73A6B23 for ; Mon, 27 Jul 2009 07:54:06 -0700 (PDT) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id D62181D2EEB; Mon, 27 Jul 2009 07:56:53 -0700 (PDT) Date: Mon, 27 Jul 2009 07:56:53 -0700 From: Eric Rescorla To: "Gregory M. Lebovitz" In-Reply-To: <4a6d643c.0fba720a.10e1.ffffd732@mx.google.com> References: <20090726234651.18D7A50822@romeo.rtfm.com> <4a6d643c.0fba720a.10e1.ffffd732@mx.google.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090727145653.D62181D2EEB@kilo.networkresonance.com> Cc: tcpm@ietf.org Subject: Re: [tcpm] Review of draft-lebovitz-ietf-tcpm-tcp-ao-crypto-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: , X-List-Received-Date: Mon, 27 Jul 2009 14:54:07 -0000 At Mon, 27 Jul 2009 01:24:21 -0700, Gregory M. Lebovitz wrote: > > inline... > > At 04:46 PM 7/26/2009, Eric Rescorla wrote: > >$Id: draft-lebovitz-ietf-tcpm-tcp-ao-crypto-01-rev.txt,v 1.1 > >2009/07/26 22:40:47 ekr Exp $ > > > >TECHNICAL > >S 3.1. > >This mixing of the KDF interface and the NIST 800-108 interface > >is extraordinarily confusing. > > I'm not sure it's "mixing". Isn't one is a subset of the other? The > KDF interface is an interface. The NIST thing is the actual > concatenated construct which fulfills the Context. Well, as usual, the interface is abstract and the NIST thing is a concrete implementation. > >To recap: > >The input to the KDF requires: > > > >- Master Key > >- Context (i.e., the conn-data) > > it's not just the Data_Block (updated lingo, per auth-opt-05). In > order to follow SP800-180, the context is a few things concatenated, > and Data_Block is one of the things. Yes, that's what it is now and my point is that that's wrong. > >- Output length > > > >Now, as it happens, you're constructing your KDFs a la SP800-108, > >so you then use the relevant PRF with an input block constructed > >as: > > > > ( i || Label || Context || Output_Length) > > > >But that is not a meaningful part of the interface to the KDF > >as far as AO is concerned. If you were (for instance) to define > >a new TLS PRF based KDF, you would not use i internally because > >the TLS PRF generates an arbitrary length string. Again, it's > >important to distinguish between the TCP-AO requirements and > >what this document happens to do. > > I think this document is NOT just the generic interface - that's > covered in auth-opt-05. This document reminds us of the generic > interface, and then specifically defines how to do the SHA1 and > AES-128 KDFs themselves. That's why we made it specific. Maybe I'm > not understanding you? Apparently not. My point is that you shouldn't be exporting the SP800-108 stuff into the TCP-AO document, and the way you have defined the generic interface does that. > >S 3.1.3. > >Wait, I don't remember agreeing to this. I'm happy to use these > >as labels in soem IANA registry, byt people's UI is not our > >business. > > This is the years of IKE interop work which motivates this. Well, years of TLS interop suggest the exact contrary. We're not in the business of mandating UI. > Clarifying the UI representations to make it very easy on operators > is a good thing. Others opinions on this UI guidance? > >S 2.3. > > (1) Key Derivation Functions (KDFs) which name a pseudorandom > > function (PRF) and use a Master_Key and some connection- > > specific Input with that PRF to produce Conn_Keys, the keys > > suitable for authenticating and integrity checking > > individual TCP segments. > > > >This is confusing. KDFs may or may not be constructed with PRFs. > >However, THESE KDFs are so constructed. If you're giong to have > >a document which applies to future KDFs, don't say PRF here. > > it does say "which name", not "MUST name". Doesn't this cover your point? Not really, no. I think you need to separate the abstract requirements from the concrete instantiations. -Ekr From Alexander.Zimmermann@nets.rwth-aachen.de Mon Jul 27 07:57:34 2009 Return-Path: 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 D64CE28C1A6 for ; Mon, 27 Jul 2009 07:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.001 X-Spam-Level: X-Spam-Status: No, score=-3.001 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, J_CHICKENPOX_26=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_35=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 LiUY1x+qG3JT for ; Mon, 27 Jul 2009 07:57:33 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 7A1B828C19A for ; Mon, 27 Jul 2009 07:57:33 -0700 (PDT) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KNG0054747XC090@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Mon, 27 Jul 2009 16:57:33 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.43,276,1246831200"; d="sig'?scan'208";a="20526644" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Mon, 27 Jul 2009 16:57:33 +0200 Received: from dhcp-52b1.meeting.ietf.org ([unknown] [130.129.82.177]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0KNG0068G47WSM10@relay-auth-1.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Mon, 27 Jul 2009 16:57:33 +0200 (CEST) Message-id: <88586BB2-ECEC-48AC-A2ED-61C8A6196B7E@nets.rwth-aachen.de> From: Alexander Zimmermann To: David Borman In-reply-to: <79C12B51-C0CE-47F9-A6EF-F61239D661B0@windriver.com> Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-12--183486968 Content-transfer-encoding: 7bit Date: Mon, 27 Jul 2009 16:57:32 +0200 References: <1E6B7C58-4AE4-4B82-B110-F26D8F76F71B@nets.rwth-aachen.de> <79C12B51-C0CE-47F9-A6EF-F61239D661B0@windriver.com> X-Pgp-Agent: GPGMail 1.2.0 (v56) X-Mailer: Apple Mail (2.935.3) Cc: "tcpm@ietf.org" Subject: Re: [tcpm] 1323bis - PAWS check's problem with reodering on the reverse path 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: , X-List-Received-Date: Mon, 27 Jul 2009 14:57:34 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-12--183486968 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi David, comments are inline. Am 14.07.2009 um 01:12 schrieb David Borman: > I've been thinking about this recently, and I think that while it may > be a real issue, it's not one that we need to worry about. I believe > that the problem that the change fixes is a more likely scenario, so > if you have to choose between the two, that's the one to pick. Sure. As you mentioned offline last time after the meeting the new version of the alg. is version that most OS implement. I fully agree with you that we should adopt the updated version. > > Also, for this issue that Alexander brings up, the timestamp has to be > changing between ACKs. If the timestamp hasn't changed between the > re- > ordered ACKs, then the "SEG.TSval >= TS.recent" check will succeed. > Generally, the TS clock shouldn't be ticking that often, if it is > changing with every ACK then it might be going faster than it needs > to. However, *if* reordering is present in the network the case that I mentioned is not so unlikely. We saw the phenomenon during some measurements/ dumps... > > So, this issue only occurs when ACKs are re-ordered, *and* the > Timestamp clock has ticked between the reordered ACKs. I'm thinking > that 1323bis should just note that this situation does exist. Definitely. I know that for example Linux implement also an heuristic to detect reordered ACK. Maybe we can put a point to that. > > What does everyone else think? Shall we leave the text as is and just > document this edge case, or do people disagree with me and feel that > this is a real problem that needs to be addressed, and is more > important than the problems that the original change fixes? > > -David Alex > > On Mar 26, 2009, at 6:10 PM, Alexander Zimmermann wrote: > >> Hi David, hi TCPM Folks, >> >> in the 1323bis draft the PAWS check has a problem (discarding ACKs) >> if reordering is present on the >> reverse path and no data is piggybacked. Actually, it's not the PAWS >> check itself, it's the modification >> of section 3.4: "Which Timestamp to Echo". >> >> The important parts of the RFC1323 and the draft (in this order) are >> >> --- >> (2) If Last.ACK.sent falls within the range of sequence numbers >> of an incoming segment: >> >> SEG.SEQ <= Last.ACK.sent < SEG.SEQ + SEG.LEN >> >> then the TSval from the segment is copied to TS.Recent; >> otherwise, the TSval is ignored. >> >> --- >> >> (2) If: >> >> SEG.TSval >= TS.recent and SEG.SEQ <= Last.ACK.sent >> >> then SEG.TSval is copied to TS.Recent; otherwise, it is >> ignored. >> --- >> >> The addition of "SEG.TSval >= TS.recent" is not important for us at >> moment. As the appendix said, >> this check is included for consistency with the PAWS test only. >> >> The relevant paragraph is the change from "SEG.SEQ <= Last.ACK.sent >> < SEG.SEQ + SEG.LEN" to the >> reduced form "SEG.SEQ <= Last.ACK.sent". Again, the appendix said >> that this change was made >> since the original algorithm to control which timestamp is echoed >> was incorrect in two regards: >> >> (1) It failed to update TSrecent for a retransmitted segment that >> resulted from a lost ACK. >> >> (2) It failed if SEG.LEN = 0. >> >> It's right that the 1323bis algo fix these two problems, however, >> it's introduced the new problem mentioned >> already above. >> >> Following situation: >> - One-way flow from TCP A to TCP B >> - Reordering on the reverse path >> >> Consequence >> - TCP A will discard all ACKs with were delayed >> - Harmful in the case ABC (RFC 3465) is off, since we count ACKs for >> slow-start and congestion avoidance >> >> Examples are attached. >> >> Alex >> >> >> // >> // Dipl.-Inform. Alexander Zimmermann >> // Department of Computer Science, Informatik 4 >> // RWTH Aachen University >> // Ahornstr. 55, 52056 Aachen, Germany >> // phone: (49-241) 80-21422, fax: (49-241) 80-22220 >> // email: zimmermann@cs.rwth-aachen.de >> // web: http://www.umic-mesh.net >> // >> > --Apple-Mail-12--183486968 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: Signierter Teil der Nachricht content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkptwFwACgkQdyiq39b9uS73QQCfenyeD2vfRT9pOw69RPVOk2oI 00gAnjhwQQ3+OHoURGB/KQYMZ18RPDvr =P3ks -----END PGP SIGNATURE----- --Apple-Mail-12--183486968-- From william.polk@nist.gov Sun Jul 26 08:44:04 2009 Return-Path: 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 6029E3A63EB for ; Sun, 26 Jul 2009 08:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.792 X-Spam-Level: X-Spam-Status: No, score=-6.792 tagged_above=-999 required=5 tests=[AWL=-0.193, 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 GfKIu49FrbOx for ; Sun, 26 Jul 2009 08:44:03 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 5FAF23A69AB for ; Sun, 26 Jul 2009 08:43:46 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (wsxghub1.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n6QFhdsB006885; Sun, 26 Jul 2009 11:43:39 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([2002:8106:1260::8106:1260]) with mapi; Sun, 26 Jul 2009 11:43:39 -0400 From: "Polk, William T." To: "gregory.ietf@gmail.com" , "mcgrew@cisco.com" Date: Sun, 26 Jul 2009 11:40:50 -0400 Thread-Topic: handling variable length keys in draft-lebovitz-ietf-tcpm-tcp-ao-crypto Thread-Index: AQHKDgfXKGETfA/aWkKnhV49u9jzAg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: william.polk@nist.gov X-Mailman-Approved-At: Mon, 27 Jul 2009 08:02:15 -0700 Cc: "housley@vigilsec.com" , "tcpm@ietf.org" , "Pasi.Eronen@nokia.com" Subject: [tcpm] handling variable length keys in draft-lebovitz-ietf-tcpm-tcp-ao-crypto 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: , X-List-Received-Date: Sun, 26 Jul 2009 15:44:04 -0000 Gregory, As requested, Pasi and I took a look at how draft-lebovitz-ietf-tcpm-tcp-ao= -crypto handles the AES-CMAC case when the master key is not 128 bits. The method currently used (using AES-CMAC with a known fixed key as a "randomness extractor") is basically the same as used in IKEv2 (RFC 4615 and 4434), except IKEv2 uses all-zeroes key (but the specific value of the known fixed key shouldn't matter much -- just pick one). Using the same method in TCP-AO would be acceptable us, and seems strongly preferable to requiring network admins to configure exactly 128 bit keys. Other methods of getting from "what the admin configures" to 128 bits could work, too. Since the output of this step is *only* used as the key for further PRF calculations (and for *nothing* else), the requirements for it are very limited. If all keys were <=3D 128 bits, even something trivial such as padding with zeroes would work -- so this step doesn't even have to be one-way. Since we need to handle also keys >128 bits, simple padding isn't enough, of course. If the WG wants AES-only method, the one that's in the draft now seems OK to us. I hope this was helpful. Tim Polk Pasi Eronen= From william.polk@nist.gov Sun Jul 26 23:45:25 2009 Return-Path: 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 64B6D28C11B for ; Sun, 26 Jul 2009 23:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.779 X-Spam-Level: X-Spam-Status: No, score=-6.779 tagged_above=-999 required=5 tests=[AWL=-0.180, 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 vavhXZlIyDAN for ; Sun, 26 Jul 2009 23:45:24 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 6183A28C10A for ; Sun, 26 Jul 2009 23:45:24 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (wsxghub1.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n6R6jHfU010864; Mon, 27 Jul 2009 02:45:17 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([2002:8106:1260::8106:1260]) with mapi; Mon, 27 Jul 2009 02:45:17 -0400 From: "Polk, William T." To: Eric Rescorla , "Gregory M. Lebovitz" Date: Mon, 27 Jul 2009 02:40:55 -0400 Thread-Topic: [tcpm] handling variable length keys in draft-lebovitz-ietf-tcpm-tcp-ao-crypto Thread-Index: AcoOSAr8DJq7sEDlTDGDQCn2PGg96AAPSYP3 Message-ID: References: , <20090726232624.B2E5050822@romeo.rtfm.com> In-Reply-To: <20090726232624.B2E5050822@romeo.rtfm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: william.polk@nist.gov X-Mailman-Approved-At: Mon, 27 Jul 2009 08:02:15 -0700 Cc: "Pasi.Eronen@nokia.com" , "tcpm@ietf.org" , "mcgrew@cisco.com" , "housley@vigilsec.com" Subject: Re: [tcpm] handling variable length keys in draft-lebovitz-ietf-tcpm-tcp-ao-crypto 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: , X-List-Received-Date: Mon, 27 Jul 2009 06:45:25 -0000 Ekr, Your objections on the magic number are well taken. Since zeroes would be a holdover from 4615 and 4434, that value won't introduce any new issues. I think that would be the best course of action. Tim ________________________________________ From: Eric Rescorla [ekr@networkresonance.com] Sent: Sunday, July 26, 2009 7:26 PM To: Gregory M. Lebovitz Cc: Polk, William T.; mcgrew@cisco.com; housley@vigilsec.com; tcpm@ietf.org= ; Pasi.Eronen@nokia.com Subject: Re: [tcpm] handling variable length keys in draft-lebovitz-ietf-tc= pm-tcp-ao-crypto At Sun, 26 Jul 2009 12:43:37 -0700, Gregory M. Lebovitz wrote: > > Tim, > This is helpful, thanks. We will proceed toward WG LC with the > mechanism as represented in draft v-01. I'll be sending my comments on v-01 shortly, but I object to the magic number in the current mechanism. If we're going to use a magic key, it should be zero or some other anchor point. The use of a random number pulled out of the air is highly inappropriate in cryptographic systems [I refer you to the contrroversy over the DES S-boxes]. -Ekr > If later, after further discussions within the cryptographic > community, it is decided that the randomness extraction mechanism to > go from a variable-length user-given string to a 128-bit key would be > better accomplished some other way, then we can always do a quick > -bis on the RFC and update the mechanism. That's easy enough for a > small RFC like this. > Gregory. > > At 08:40 AM 7/26/2009, Polk, William T. wrote: > >Gregory, > > > >As requested, Pasi and I took a look at how > >draft-lebovitz-ietf-tcpm-tcp-ao-crypto > >handles the AES-CMAC case when the master key is not 128 bits. > > > >The method currently used (using AES-CMAC with a known fixed key as a > >"randomness extractor") is basically the same as used in IKEv2 (RFC > >4615 and 4434), except IKEv2 uses all-zeroes key (but the specific > >value of the known fixed key shouldn't matter much -- just pick one). > > > >Using the same method in TCP-AO would be acceptable us, and seems > >strongly preferable to requiring network admins to configure exactly > >128 bit keys. > > > >Other methods of getting from "what the admin configures" to 128 bits > >could work, too. Since the output of this step is *only* used as the > >key for further PRF calculations (and for *nothing* else), the > >requirements for it are very limited. If all keys were <=3D 128 bits, > >even something trivial such as padding with zeroes would work -- so > >this step doesn't even have to be one-way. Since we need to handle > >also keys >128 bits, simple padding isn't enough, of course. If the WG > >wants AES-only method, the one that's in the draft now seems OK to us. > > > >I hope this was helpful. > > > >Tim Polk > >Pasi Eronen > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From ekr@networkresonance.com Mon Jul 27 08:05:32 2009 Return-Path: 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 8D6083A6AE8 for ; Mon, 27 Jul 2009 08:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=-0.513, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 iQqJOcXWt3Aq for ; Mon, 27 Jul 2009 08:05:31 -0700 (PDT) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id B1EB73A6A7B for ; Mon, 27 Jul 2009 08:05:31 -0700 (PDT) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 42E941D2F19; Mon, 27 Jul 2009 08:08:19 -0700 (PDT) Date: Mon, 27 Jul 2009 08:08:18 -0700 From: Eric Rescorla To: "Polk, William T." In-Reply-To: References: User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090727150819.42E941D2F19@kilo.networkresonance.com> Cc: "Pasi.Eronen@nokia.com" , "housley@vigilsec.com" , "mcgrew@cisco.com" , "tcpm@ietf.org" Subject: Re: [tcpm] handling variable length keys in draft-lebovitz-ietf-tcpm-tcp-ao-crypto 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: , X-List-Received-Date: Mon, 27 Jul 2009 15:05:32 -0000 At Sun, 26 Jul 2009 11:40:50 -0400, Polk, William T. wrote: > > Gregory, > > As requested, Pasi and I took a look at how draft-lebovitz-ietf-tcpm-tcp-ao-crypto > handles the AES-CMAC case when the master key is not 128 bits. > > The method currently used (using AES-CMAC with a known fixed key as a > "randomness extractor") is basically the same as used in IKEv2 (RFC > 4615 and 4434), except IKEv2 uses all-zeroes key (but the specific > value of the known fixed key shouldn't matter much -- just pick one). > > Using the same method in TCP-AO would be acceptable us, and seems > strongly preferable to requiring network admins to configure exactly > 128 bit keys. > > Other methods of getting from "what the admin configures" to 128 bits > could work, too. Since the output of this step is *only* used as the > key for further PRF calculations (and for *nothing* else), the > requirements for it are very limited. If all keys were <= 128 bits, > even something trivial such as padding with zeroes would work -- so > this step doesn't even have to be one-way. It seems like you're putting a lot of weight on AES to assume that a key that is 24 random bits and 104 bits of zeros at the end really has strength 2^24 -Ekr From root@core3.amsl.com Mon Jul 27 08:15:02 2009 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 164063A6C8F; Mon, 27 Jul 2009 08:15: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: <20090727151502.164063A6C8F@core3.amsl.com> Date: Mon, 27 Jul 2009 08:15:02 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-rfc2581bis-07.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: , X-List-Received-Date: Mon, 27 Jul 2009 15:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : TCP Congestion Control Author(s) : M. Allman, et al. Filename : draft-ietf-tcpm-rfc2581bis-07.txt Pages : 17 Date : 2009-07-27 This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods. This document obsoletes RFC 2581. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc2581bis-07.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-rfc2581bis-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-27080820.I-D@ietf.org> --NextPart-- From ekr@networkresonance.com Mon Jul 27 08:52:22 2009 Return-Path: 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 84D1F28C28A for ; Mon, 27 Jul 2009 08:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.767 X-Spam-Level: X-Spam-Status: No, score=-1.767 tagged_above=-999 required=5 tests=[AWL=0.832, 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 8AXZs0tNy8-c for ; Mon, 27 Jul 2009 08:52:21 -0700 (PDT) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id BA11D28C273 for ; Mon, 27 Jul 2009 08:52:21 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 6621750822; Mon, 27 Jul 2009 08:55:57 -0700 (PDT) Date: Mon, 27 Jul 2009 08:55:57 -0700 From: Eric Rescorla To: Joe Touch In-Reply-To: <4A5B9FEB.6080706@isi.edu> References: <4A5B9FEB.6080706@isi.edu> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090727155557.6621750822@romeo.rtfm.com> Cc: tcpm Extensions WG Subject: Re: [tcpm] possible NAT support for TCP-AO 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: , X-List-Received-Date: Mon, 27 Jul 2009 15:52:22 -0000 At Mon, 13 Jul 2009 13:58:19 -0700, Joe Touch wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, all, > > Based on a discussion on a different list with Dan Wing, I'd like to > revisit thinking about NATs in the context of the current AO, which uses > traffic keys derived from the socket pair and ISN pair. We might be able > to now support NATs as follows, e.g.: > > add the following flags to the MKT: > > localNAT flag - indicates whether the local IP/port are > zeroed before MAC calculation > > remoteNAT flag - indicates whether the remote IP/port > are zeroed before MAC calculation > > add steps to the incoming/outgoing processing: > zero the corresponding IP/port when the flag indicates, > both on outgoing and incoming MAC calculation > > That's basically it. A client behind a NAT would have a MKT with > localNAT true, and a server for that client would need to have a MKT > with remoteNAT true. This does require careful MKT configuration. > Although I wouldn't expect both localNAT and remoteNAT to be true, there > isn't a particular reason it needs to be prohibited. So I'm going to jump in right here: it's not in general practical to know whether you are behind a NAT. That's why the BEHAVE NAT discovery document is going to Experimental. -Ekr From touch@ISI.EDU Mon Jul 27 09:17:27 2009 Return-Path: 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 7757428C1A0 for ; Mon, 27 Jul 2009 09:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=0.218, 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 z0AgkqhrhQjR for ; Mon, 27 Jul 2009 09:17:26 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 2A95F3A6C9D for ; Mon, 27 Jul 2009 09:17:26 -0700 (PDT) Received: from [130.129.22.106] (dhcp-166a.meeting.ietf.org [130.129.22.106]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n6RGGoYi028054; Mon, 27 Jul 2009 09:16:52 -0700 (PDT) Message-ID: <4A6DD2F1.5000301@isi.edu> Date: Mon, 27 Jul 2009 09:16:49 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Eric Rescorla References: <4A5B9FEB.6080706@isi.edu> <20090727155557.6621750822@romeo.rtfm.com> In-Reply-To: <20090727155557.6621750822@romeo.rtfm.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm Extensions WG Subject: Re: [tcpm] possible NAT support for TCP-AO 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: , X-List-Received-Date: Mon, 27 Jul 2009 16:17:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Rescorla wrote: ... > So I'm going to jump in right here: it's not in general practical > to know whether you are behind a NAT. That's why the BEHAVE > NAT discovery document is going to Experimental. You're talking about NAT discovery; this mod doesn't talk about how you figure that out, just how to support it if you do know it. You can trivially know it in a key distro protocol if you send your adr/port in the payload, so that the endpoint can see if it matches what is on the outside. Granted that won't work in a backward-compatible way (e.g., for BEHAVE), but key distro protocols don't have that limitation. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkpt0vAACgkQE5f5cImnZrs3nACgqtxQKbYhXUYTeGNubvzEp4lh nfYAn3N8wByqcEQyPSo08MHvrJiqqcz1 =2bhD -----END PGP SIGNATURE----- From mallman@icir.org Mon Jul 27 12:28:13 2009 Return-Path: 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 BF5AE3A6CB6 for ; Mon, 27 Jul 2009 12:28: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 WqXm-1q0wLME for ; Mon, 27 Jul 2009 12:28:12 -0700 (PDT) Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id D6D873A6988 for ; Mon, 27 Jul 2009 12:28:12 -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 n6RJSBOo009668; Mon, 27 Jul 2009 12:28:11 -0700 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id D89BE3BC8A83; Mon, 27 Jul 2009 15:28:03 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id A142437DB08; Mon, 27 Jul 2009 15:28:05 -0400 (EDT) To: Jerry Chu From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Sweet Emotion MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma65477-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 27 Jul 2009 15:28:05 -0400 Sender: mallman@icir.org Message-Id: <20090727192805.A142437DB08@lawyers.icir.org> Cc: "tcpm@ietf.org" Subject: [tcpm] initial RTO (was Re: Tuning TCP parameters for the 21st century) 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: , X-List-Received-Date: Mon, 27 Jul 2009 19:28:13 -0000 ----------ma65477-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Jerry- A few random thoughts here ... > I'll start with Lowering initRTO. > > RFC1122 contains the following paragraph: > > The following values SHOULD be used to initialize the > estimation parameters for a new connection: > > (a) RTT = 0 seconds. > > (b) RTO = 3 seconds. (The smoothed variance is to be > initialized to the value that will result in this RTO). > > The "3secs SHOULD" is reaffirmed in RFC2988. > > From our own measurement of world wide RTT distribution to Google > servers we believe 3secs is too conservative, and like to propose it > to be reduced to 1sect. I am not at all sure this is a good idea. I have an easier time believing the others on your list are perhaps reasonable. But, this one seems somewhat dubious to me. A few things ... - The fundamental problem here is that you have *no* information. That is, we don't know how long the path is before we have done an exchange. When you start from scratch you have nothing to go on except defaults. So, it seems to me on those grounds alone conservativeness is fine. Because, - If it was just an extra small packet or two that got sent out that doesn't seem like a Big Deal. But, once you retransmit the SYN you no longer can take an RTT sample from the 3WHS per Karn's algorithm. So, if in fact the initial RTO is too short then it isn't just going to strobe out an extra packet, but what it means is that it's pretty likely that the packets in your initial window---after clumsily finishing the 3WHS---will likewise be retransmitted because the RTO estimate is low and we did not get the opportunity in the 3WHS to take an actual RTT sample to better seed the estimator. This is RTO Hell. - At first blush timestamps might help here because if used then we don't have to use Karn's algorithm. But, again, since we are just initiating a connection how do we know if the peer is going to use timestamps? If the initiator sends a timestamp option then there is a chance that timestamps will be in use and therefore there is a chance you'll avoid RTO Hell. But, there is also a chance you won't. The 3WHS responder (sender of the SYN+ACK) will know if timestamps will be in use and therefore could perhaps lower the initial RTO (basically, this is the ECNSYN trick). That doesn't seem all that unreasonable to me. - Now, if you track information across connections as others have noted then, sure. It seems perfectly acceptable to take the view that with high confidence you understand that 1sec (or whatever) will be fine for an initial RTO over some path that you have transmitted traffic across in the recent past and so then you can use that. In this case, you are picking an initial RTO for a connection but not flying completely in the dark. - It seems that (per the discussion in today's meeting) a naive lowering to 1sec is going to be problematic because we have bandwidth-on-demand networks, deep queues in access devices are not rare, etc. In a subsequent email you note: > Correct so there is a fine line to walk. But if > 98% of all TCP > connections experience RTT << 1 sec, it just seems too conservative to > have a global initRTO == 3secs just to avoid spurious retransmission > in the < 2% category. I agree that it is a fine line. But, I think your 98%-vs-2% is far too glib. That is, we have to look at how bad we're making it for those 2%. If we degraded each of those 2% by "a smidge" then who cares. But, if we really hose those connections (see second bullet above about RTO Hell) it doesn't seem like a good tradeoff. It's useful to remember that TCP was designed to be general and not optimal. Certainly we don't want to unduly penalize most of the traffic (/users) to dogmatically accommodate every last esoteric situation that might happen to crop up on the third Tuesday of the 6th month following the most recent blue moon. But, we also can err on the other side, too. I think simple percentages as you have given are pretty superficial and we'd need to go beyond that to really decide what line we wanted to walk. Just my two bits ... allman ----------ma65477-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkpt/8UACgkQWyrrWs4yIs4LGACcDXwaLENpU8R7k+RnKipiZNos VkwAoI9utPNoocwo0KwOq4PKkJGLjxpm =goSP -----END PGP SIGNATURE----- ----------ma65477-1-- From hkchu@google.com Tue Jul 28 08:32:05 2009 Return-Path: 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 992F33A708D for ; Tue, 28 Jul 2009 08:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] 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 AJFUcnkk4rp8 for ; Tue, 28 Jul 2009 08:32:04 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 4FCB43A7088 for ; Tue, 28 Jul 2009 08:32:04 -0700 (PDT) Received: from zps36.corp.google.com (zps36.corp.google.com [172.25.146.36]) by smtp-out.google.com with ESMTP id n6SFW5kA022471 for ; Tue, 28 Jul 2009 08:32:05 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1248795125; bh=ktPzucje9BS9x9oTbO+0pFKKbaQ=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type: Content-Transfer-Encoding:X-System-Of-Record; b=lhEBB9J5psUWtgx5DW hCRPy/deP3q/iQeRlrihQLEnNzEeM8pzfzJyd/CgHK9eAcODCnopRekgOL/nxzhqXep w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=jGlX+XQQYatHhxj9pXjTDm4TrMCkeNMtINx6iPpBEIwRUgYh2QB8zycZuoEwk9Zgr WUW09vI8+8g+oFJU+fAhA== Received: from an-out-0708.google.com (ancc5.prod.google.com [10.100.29.5]) by zps36.corp.google.com with ESMTP id n6SFW2Ze018713 for ; Tue, 28 Jul 2009 08:32:03 -0700 Received: by an-out-0708.google.com with SMTP id c5so45101anc.42 for ; Tue, 28 Jul 2009 08:32:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.213.13 with SMTP id l13mr10106789ang.110.1248795122538; Tue, 28 Jul 2009 08:32:02 -0700 (PDT) In-Reply-To: <20090727192805.A142437DB08@lawyers.icir.org> References: <20090727192805.A142437DB08@lawyers.icir.org> Date: Tue, 28 Jul 2009 08:32:02 -0700 Message-ID: From: Jerry Chu To: mallman@icir.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "tcpm@ietf.org" Subject: Re: [tcpm] initial RTO (was Re: Tuning TCP parameters for the 21st century) 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: , X-List-Received-Date: Tue, 28 Jul 2009 15:32:05 -0000 Mark, Thanks for your thoughtful comments. The good news is, I'm pretty much on the same page as you. The problem has to be real and the solution must be reasonable with acceptable downside if the latter is unavoidable. From our applications folks the problem seems very real and the performance difference is not negligible. So I'll focus more on how to rein in the down= side. On Mon, Jul 27, 2009 at 12:28 PM, Mark Allman wrote: > > Jerry- > > A few random thoughts here ... > > > I'll start with Lowering initRTO. > > > > RFC1122 contains the following paragraph: > > > > The following values SHOULD be used to initialize the > > estimation parameters for a new connection: > > > > (a) =A0RTT =3D 0 seconds. > > > > (b) =A0RTO =3D 3 seconds. =A0(The smoothed variance is to be > > initialized to the value that will result in this RTO). > > > > The "3secs SHOULD" is reaffirmed in RFC2988. > > > > From our own measurement of world wide RTT distribution to Google > > servers we believe 3secs is too conservative, and like to propose it > > to be reduced to 1sect. > > I am not at all sure this is a good idea. =A0I have an easier time > believing the others on your list are perhaps reasonable. =A0But, this on= e > seems somewhat dubious to me. =A0A few things ... > > =A0- The fundamental problem here is that you have *no* information. > =A0 =A0That is, we don't know how long the path is before we have done an > =A0 =A0exchange. =A0When you start from scratch you have nothing to go on > =A0 =A0except defaults. =A0So, it seems to me on those grounds alone > =A0 =A0conservativeness is fine. =A0Because, Agreed. The question is, how conservative one needs to be? Can we do better for the majority and still not sacrificing the ones left behind? If some cost is unavoidable, will the tradeoff be acceptable? > > =A0- If it was just an extra small packet or two that got sent out that > =A0 =A0doesn't seem like a Big Deal. =A0But, once you retransmit the SYN = you > =A0 =A0no longer can take an RTT sample from the 3WHS per Karn's algorith= m. > =A0 =A0So, if in fact the initial RTO is too short then it isn't just goi= ng > =A0 =A0to strobe out an extra packet, but what it means is that it's pret= ty > =A0 =A0likely that the packets in your initial window---after clumsily > =A0 =A0finishing the 3WHS---will likewise be retransmitted because the RT= O > =A0 =A0estimate is low and we did not get the opportunity in the 3WHS to > =A0 =A0take an actual RTT sample to better seed the estimator. =A0This is= RTO > =A0 =A0Hell. Understood. I've also had this as one of the bullet points on the cost side in my slides. But my gut feeling was this problem could be mitigated someho= w. (Guess now I'll need to demonstrate how :-) > > =A0- At first blush timestamps might help here because if used then we > =A0 =A0don't have to use Karn's algorithm. =A0But, again, since we are ju= st > =A0 =A0initiating a connection how do we know if the peer is going to use > =A0 =A0timestamps? =A0If the initiator sends a timestamp option then ther= e is > =A0 =A0a chance that timestamps will be in use and therefore there is a > =A0 =A0chance you'll avoid RTO Hell. =A0But, there is also a chance you > =A0 =A0won't. So the active open side has retransmitted SYN, assuming initRTO of 1sec, and eventually received a SYN-ACK but the TS option was denied so no good RTT sample can be taken. It will continue to send the init data with the initRTO. If the SYN retransmission has been unnecessary because the initRTO has been too aggressive, more SYN-ACK will be triggered. Assuming these dup SYN-ACKs are not lost, could they be used as a hint to the active open side that the initRTO has been too short, so that the RTO timer can be reverted back to 3secs immediately, in time to avoid further RTO hell? One price to pay in the above scenario compared to the default case of 3secs is that one could have gotten a good RTT sample of say, 2secs but due to the choice of a more aggressive initRTO of 1sec, one ends up with a fall-back 3secs again for the data phase so any loss from there will incur more time (3 vs 2secs) to recover. But the price seems acceptable, and is incurred only when there is immediate further loss. At least the dreadful endless spurious retransmission, which would've been unacceptable, is stopped. >The 3WHS responder (sender of the SYN+ACK) will know if > =A0 =A0timestamps will be in use and therefore could perhaps lower the > =A0 =A0initial RTO (basically, this is the ECNSYN trick). =A0That doesn't > =A0 =A0seem all that unreasonable to me. Correct, but I'd really like to find a solution for the active open side because there are other techniques the server side can employ (e.g., initialize the initRTO from the RTT history...) as a backup if this one doesn't fly, but those techniques don't work well on the client side. > > =A0- Now, if you track information across connections as others have > =A0 =A0noted then, sure. =A0It seems perfectly acceptable to take the vie= w > =A0 =A0that with high confidence you understand that 1sec (or whatever) > =A0 =A0will be fine for an initial RTO over some path that you have > =A0 =A0transmitted traffic across in the recent past and so then you can > =A0 =A0use that. =A0In this case, you are picking an initial RTO for a > =A0 =A0connection but not flying completely in the dark. Correct. There is a certain amount of added complexity associated with the cached RTT idea. As such, it is still nice if this reducing initRT= O proposal can fly, not just to cover the client side but also as a simpler solution for those servers that can't afford to use the more complex solution. > > =A0- It seems that (per the discussion in today's meeting) a naive > =A0 =A0lowering to 1sec is going to be problematic because we have > =A0 =A0bandwidth-on-demand networks, deep queues in access devices are no= t > =A0 =A0rare, etc. Yes I heard it, loud and clear :-). > > In a subsequent email you note: > > > Correct so there is a fine line to walk. But if > 98% of all TCP > > connections experience RTT << 1 sec, it just seems too conservative to > > have a global initRTO =3D=3D 3secs just to avoid spurious retransmissio= n > > in the < 2% category. > > I agree that it is a fine line. =A0But, I think your 98%-vs-2% is far too > glib. =A0That is, we have to look at how bad we're making it for those 2%= . > If we degraded each of those 2% by "a smidge" then who cares. =A0But, if > we really hose those connections (see second bullet above about RTO > Hell) it doesn't seem like a good tradeoff. =A0It's useful to remember > that TCP was designed to be general and not optimal. =A0Certainly we don'= t > want to unduly penalize most of the traffic (/users) to dogmatically > accommodate every last esoteric situation that might happen to crop up > on the third Tuesday of the 6th month following the most recent blue > moon. =A0But, we also can err on the other side, too. =A0I think simple > percentages as you have given are pretty superficial and we'd need to go > beyond that to really decide what line we wanted to walk. Understood. See above. Jerry > > Just my two bits ... > > allman > > > From mallman@icir.org Tue Jul 28 11:36:05 2009 Return-Path: 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 93DB73A684C for ; Tue, 28 Jul 2009 11:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=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 CaGQFNY2JuNT for ; Tue, 28 Jul 2009 11:36:04 -0700 (PDT) Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id DF8733A6A84 for ; Tue, 28 Jul 2009 11:36:04 -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 n6SIa38n015110; Tue, 28 Jul 2009 11:36:03 -0700 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id DDEFC3BCFC45; Tue, 28 Jul 2009 14:35:55 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id A5820385088; Tue, 28 Jul 2009 14:35:56 -0400 (EDT) To: Jerry Chu From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Sweet Emotion MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma17674-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 28 Jul 2009 14:35:56 -0400 Sender: mallman@icir.org Message-Id: <20090728183556.A5820385088@lawyers.icir.org> Cc: "tcpm@ietf.org" Subject: Re: [tcpm] initial RTO (was Re: Tuning TCP parameters for the 21st century) 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: , X-List-Received-Date: Tue, 28 Jul 2009 18:36:05 -0000 ----------ma17674-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Jerry- > So the active open side has retransmitted SYN, assuming initRTO of > 1sec, and eventually received a SYN-ACK but the TS option was > denied so no good RTT sample can be taken. It will continue to send > the init data with the initRTO. > > If the SYN retransmission has been unnecessary because the initRTO has > been too aggressive, more SYN-ACK will be triggered. Assuming these > dup SYN-ACKs are not lost, could they be used as a hint to the active > open side that the initRTO has been too short, so that the RTO timer > can be reverted back to 3secs immediately, in time to avoid further > RTO hell? So, you're saying that if you send N SYNs (N>1) and you get N SYN+ACKs then you take that to mean the initRTO was too short. Yeah, perhaps ... Are you suggesting something like this ... (1) Use an initRTO of 1sec. (2) If the RTO fires and you retransmit the SYN back the RTO to 3sec. (And, if necessary you exponential backoff even more.) (3) After the 3WHS you will either (a) have a good RTT sample from the timestamp option and can therefore set the RTO reasonably or (b) you retain the 3sec RTO until you get a good RTT sample. ?? That means that if 1sec is not enough in the 3WHS you have to use 3sec until you have some idea about the network. However, you also get a shot [*one shot*] to retransmit sooner based on the notion that most RTTs are less than 1sec. I think I buy that notion ... that both allows for more aggressiveness for the common case while also protecting against RTO Hell for the long path cases. Is that the right walking of the line? allman ----------ma17674-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkpvRQwACgkQWyrrWs4yIs5REgCfS87x6CzSVEk0XQZfM3qv+AQ6 NzYAoIgxvdya80axQ2LjnXEMOpGucWlP =pGwU -----END PGP SIGNATURE----- ----------ma17674-1-- From wwwrun@core3.amsl.com Wed Jul 29 01:36:01 2009 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 8072C3A6EE9; Wed, 29 Jul 2009 01:36:01 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090729083601.8072C3A6EE9@core3.amsl.com> Date: Wed, 29 Jul 2009 01:36:01 -0700 (PDT) Cc: tcpm chair , tcpm mailing list , Internet Architecture Board , RFC Editor Subject: [tcpm] Protocol Action: 'TCP Congestion Control' to Draft Standard 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: , X-List-Received-Date: Wed, 29 Jul 2009 08:36:01 -0000 The IESG has approved the following document: - 'TCP Congestion Control ' as a Draft Standard This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc2581bis-07.txt Technical Summary The congestion control algorithms described in RFC 2581 are widely implemented and used. This document clarifies some specific points that have created questions for implementers in the past. Working Group Summary The working group saw the need for this document based on a small number of commonly recurring questions about what is meant by certain wordings in RFC2581. The working group was easily able to agree on the clarifications that this document provides. Document Quality The document was reviewed for quality by a large number of TCPM WG members. Personnel Wes Eddy (wesley.m.eddy@nasa.gov) is the document shepherd. Lars Eggert (lars.eggert@nokia.com) reviewed the document for the IESG. From lars.eggert@nokia.com Wed Jul 29 03:48:57 2009 Return-Path: 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 CEB0B3A6E7A; Wed, 29 Jul 2009 03:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=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 qWWc3irHQZ4S; Wed, 29 Jul 2009 03:48:57 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 324383A6F1D; Wed, 29 Jul 2009 03:48:45 -0700 (PDT) Received: from host-78-64-88-208.homerun.telia.com (host-78-64-88-208.homerun.telia.com [78.64.88.208]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n6TAmb9h005447 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 29 Jul 2009 13:48:38 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <6BB76CFA-4134-4D3E-BE20-3A90A5111CBD@nokia.com> From: Lars Eggert To: tcpm@ietf.org Content-Type: multipart/signed; boundary=Apple-Mail-20--25621888; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 29 Jul 2009 12:48:37 +0200 X-Mailer: Apple Mail (2.935.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.fit.nokia.com [212.213.221.39]); Wed, 29 Jul 2009 13:48:38 +0300 (EEST) Cc: "iesg@ietf.org IESG" Subject: [tcpm] status of TCP-MD5 after TCP-AO publication 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: , X-List-Received-Date: Wed, 29 Jul 2009 10:48:57 -0000 --Apple-Mail-20--25621888 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, at the meeting, the question came up which status TCP-MD5 should have after TCP-AO is published. Specifically, whether it should be obsoleted by TCP-AO and/or if it should be reclassified as Historic. A related issue I came across while trying to form an opinion of the former issue is if the publication of TCP-AO means that we can lift the Standards Variance for TCP-MD5 introduced by RFC4728. (I'm CC'ing the IESG because of this latter point, because that Standards Variance came from the SEC and RTG areas.) I looked at some other cases related to MD5 to see how we handled obsoleting or making things Historic in the past, with regards to TCP- MD5. Example 1 is RFC2537 "RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)", which is obsoleted by RFC3110 "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)", but *not* moved to Historic. (Note that this change replaces MD5 by SHA1, i.e., isn't wire-compatible, similar to how moving from TCP-MD5 to TCP-AO isn't wire-compatible, so that is apparently OK.) Example 2 is RFC2082, which is also obsoleted (but not made Historic) by RFC4822 and also replaces MD5 with another algorithm that affects wire-compatibility. So there is precedent for TCP-AO to obsolete TCP-MD5, which is also what the -AO draft currently contains. Now, on the topic of moving TCP-MD5 to Historic, RFC2026 says that even when one spec obsoletes another, there may be cases where the obsoleted spec is kept at its original level (i.e., not made Historic) to honor the requirements of an installed base, if there is one. (See PS below for the actual text.) I believe that TCP-MD5 will still remain widely deployed initially even after TCP-AO is published, and so moving it to Historic is not something we should aim for at this time. Agreed? Finally, on whether the publication of TCP-AO means that we can lift the Standards Variance for TCP-MD5 introduced by RFC4728, I'd be really interested in hearing your feedback. Thanks, Lars PS: To save you all some scrolling, RFC2026 says this about Historic RFCs: 4.2.4 Historic A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete is assigned to the "Historic" level. (Purists have suggested that the word should be "Historical"; however, at this point the use of "Historic" is historical.) and later 6.3 Revising a Standard A new version of an established Internet Standard must progress through the full Internet standardization process as if it were a completely new specification. Once the new version has reached the Standard level, it will usually replace the previous version, which will be moved to Historic status. However, in some cases both versions may remain as Internet Standards to honor the requirements of an installed base. In this situation, the relationship between the previous and the new versions must be explicitly stated in the text of the new version or in another appropriate document (e.g., an Applicability Statement; see section 3.2). 6.4 Retiring a Standard As the technology changes and matures, it is possible for a new Standard specification to be so clearly superior technically that one or more existing standards track specifications for the same function should be retired. In this case, or when it is felt for some other reason that an existing standards track specification should be retired, the IESG shall approve a change of status of the old specification(s) to Historic. This recommendation shall be issued with the same Last-Call and notification procedures used for any other standards action. A request to retire an existing standard can originate from a Working Group, an Area Director or some other interested party. --Apple-Mail-20--25621888 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA3MjkxMDQ4MzhaMCMGCSqGSIb3DQEJBDEWBBROBfM31tE7RVc9 D24bWeePu0reuTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAQzGUVaAjpp402xhTlNcZSyHlK6IvedXO/uuZdIgNCCWxWcO9TRkm MwKx90iu2JtwZMI/GGhyEIH/hh7oGUrXl/sLEqXfsX/c9uotmK0ExFbu+E6ZyhY4qKk1cha5CpF5 hONNbM0K5BJssAANMuTz0P7aXmbM3biQGFl+a0IsEm9cWsZybMOGW841LxiMEpOYRgAC16mpawPg 6GaGQrBqpcNwdTbF2H05nL+IFdAjspJ5xCH1rI67VSBojxyb5oHexVslp28T/980PNse4rIEJL+z 1V6c50osdji800fVcyfv6To9Y2qpGystfadgYGRM6AxIHqoUPxASxmRzUed03QAAAAAAAA== --Apple-Mail-20--25621888-- From iljitsch@muada.com Wed Jul 29 04:02:07 2009 Return-Path: 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 8E9563A6FBE; Wed, 29 Jul 2009 04:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.173 X-Spam-Level: X-Spam-Status: No, score=-6.173 tagged_above=-999 required=5 tests=[AWL=0.426, 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 jL3M0Sv+2zf3; Wed, 29 Jul 2009 04:02:07 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id A5FE23A684C; Wed, 29 Jul 2009 04:02:06 -0700 (PDT) Received: from dhcp-55f3.meeting.ietf.org (dhcp-55f3.meeting.ietf.org [130.129.85.243] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n6TB1m6b084814 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 Jul 2009 13:01:49 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: Lars Eggert In-Reply-To: <6BB76CFA-4134-4D3E-BE20-3A90A5111CBD@nokia.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 29 Jul 2009 13:02:06 +0200 References: <6BB76CFA-4134-4D3E-BE20-3A90A5111CBD@nokia.com> X-Mailer: Apple Mail (2.935.3) Cc: tcpm@ietf.org, "iesg@ietf.org IESG" Subject: Re: [tcpm] status of TCP-MD5 after TCP-AO publication 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: , X-List-Received-Date: Wed, 29 Jul 2009 11:02:07 -0000 On 29 jul 2009, at 12:48, Lars Eggert wrote: > at the meeting, the question came up which status TCP-MD5 should > have after TCP-AO is published. Specifically, whether it should be > obsoleted by TCP-AO and/or if it should be reclassified as Historic. First of all, I'd like to see some operational experience with TCP-AO. Don't throw away your old shoes until you know whether the new ones fit. Second, it's not like TCP-MD5 isn't being used. As such, "historic" wouldn't apply. "Deprecated", maybe. Third, why is it exactly that we can't simply move from MD5 to IPsec to protect BGP sessions?? From lars.eggert@nokia.com Wed Jul 29 04:14:11 2009 Return-Path: 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 7DE5C3A6953; Wed, 29 Jul 2009 04:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 eqJRltiTJwRb; Wed, 29 Jul 2009 04:14:10 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 7A4843A68C9; Wed, 29 Jul 2009 04:14:10 -0700 (PDT) Received: from [IPv6:2001:df8::80:225:ff:fe45:eccf] ([IPv6:2001:df8:0:80:225:ff:fe45:eccf]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n6TBE2wP005816 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 29 Jul 2009 14:14:03 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <54734E7B-7003-423E-86F3-97C03E2971E3@nokia.com> From: Lars Eggert To: Iljitsch van Beijnum In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-22--24102701; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 29 Jul 2009 13:13:56 +0200 References: <6BB76CFA-4134-4D3E-BE20-3A90A5111CBD@nokia.com> X-Mailer: Apple Mail (2.935.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.fit.nokia.com [IPv6:2001:2060:40:1::123]); Wed, 29 Jul 2009 14:14:03 +0300 (EEST) Cc: "tcpm@ietf.org" , "iesg@ietf.org IESG" Subject: Re: [tcpm] status of TCP-MD5 after TCP-AO publication 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: , X-List-Received-Date: Wed, 29 Jul 2009 11:14:11 -0000 --Apple-Mail-22--24102701 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, On 2009-7-29, at 13:02, Iljitsch van Beijnum wrote: >> at the meeting, the question came up which status TCP-MD5 should >> have after TCP-AO is published. Specifically, whether it should be >> obsoleted by TCP-AO and/or if it should be reclassified as Historic. > > First of all, I'd like to see some operational experience with TCP-AO. > Don't throw away your old shoes until you know whether the new ones > fit. so are you saying we should *neither* obsolete TCP-MD5 *nor* move it to Historic? > Second, it's not like TCP-MD5 isn't being used. As such, "historic" > wouldn't apply. "Deprecated", maybe. There is no way to express this for an RFC. There are two options: "A obsoletes B", which is indicated in the document header, and "A is reclassified as Historic" in the RFC Editor database. > Third, why is it exactly that we can't simply move from MD5 to IPsec > to protect BGP sessions?? I refer you to the extensive discussion that happened when draft- bonica was first presented to the WG, which I have no interest in rehashing. Lars --Apple-Mail-22--24102701 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA3MjkxMTEzNTdaMCMGCSqGSIb3DQEJBDEWBBR6PZnpAu2bUpvd 2NyHPaMzs088OTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAV0foDrNPHsYOAZKvCa+QQHfXxVy+vznHs7/T50j1rDyu8PO88YQq sBCrQOFdJ+u3rs5l/KGXuKT5Dx9YOTRpLQVISULIy+jNK/TTanPoW+PTGh4xaVNHMuemJwMicEkm hhgRpqBMbd140gl0I2nmcMlg1ULSFy7p+WvowZNmdUWMMBL2qtDZFecNe0bKQHN9QVSmodS6x7CP w1IhV5Yhe6fmTRWMbMFi5vDMRZDk0WqWIvwwe+S21+WOdw09Fn0n2+nvg4XSPI1cGsZfvma0NMHa jNJUCMnsoLkUL33iXSfFfghFVH/srnEMZXoiXGFqYwFyCAR5kqsg6GGaD+AybwAAAAAAAA== --Apple-Mail-22--24102701-- From dab@weston.borman.com Wed Jul 29 04:26:13 2009 Return-Path: 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 188F53A67B4; Wed, 29 Jul 2009 04:26:13 -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 VuKadfu7-KWd; Wed, 29 Jul 2009 04:26:12 -0700 (PDT) Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id 590763A6F57; Wed, 29 Jul 2009 04:26:12 -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 n6TBQE1M005718; Wed, 29 Jul 2009 04:26:14 -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); Wed, 29 Jul 2009 04:26:13 -0700 Received: from dhcp-53da.meeting.ietf.org ([147.11.233.48]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Jul 2009 04:26:13 -0700 Message-Id: <498A59CE-C010-4FD5-9A00-29E3FE51DB8D@weston.borman.com> From: David Borman To: Lars Eggert In-Reply-To: <6BB76CFA-4134-4D3E-BE20-3A90A5111CBD@nokia.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 29 Jul 2009 13:26:10 +0200 References: <6BB76CFA-4134-4D3E-BE20-3A90A5111CBD@nokia.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 29 Jul 2009 11:26:14.0027 (UTC) FILETIME=[619EEDB0:01CA103F] Cc: tcpm@ietf.org, "iesg@ietf.org IESG" Subject: Re: [tcpm] status of TCP-MD5 after TCP-AO publication 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: , X-List-Received-Date: Wed, 29 Jul 2009 11:26:13 -0000 On Jul 29, 2009, at 12:48 PM, Lars Eggert wrote: > Hi, > > at the meeting, the question came up which status TCP-MD5 should > have after TCP-AO is published. Specifically, whether it should be > obsoleted by TCP-AO and/or if it should be reclassified as Historic. 1) TCP-AO should obsolete TCP-MD5. That was the whole point of this exercise of creating TCP-AO. 2) Whether or not TCP-MD5 is moved to historic is a separate issue. If people are concerned about marking it historic at this point in time, then don't. We can always come back in a year or two after TCP- AO has been deployed, and then mark TCP-MD5 historic. As long as it is clear that TCP-AO obsoletes TCP-MD5, then I don't think it matters that much if/when TCP-MD5 is moved to historic. -David Borman From touch@ISI.EDU Wed Jul 29 04:45:11 2009 Return-Path: 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 F402B3A6A73; Wed, 29 Jul 2009 04:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 5OTgxXscHKFK; Wed, 29 Jul 2009 04:45:10 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id F0E3A3A62C1; Wed, 29 Jul 2009 04:45:09 -0700 (PDT) Received: from [130.129.69.215] (dhcp-45d7.meeting.ietf.org [130.129.69.215]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n6TBit5h019014; Wed, 29 Jul 2009 04:44:57 -0700 (PDT) Message-ID: <4A703636.6020406@isi.edu> Date: Wed, 29 Jul 2009 04:44:54 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Iljitsch van Beijnum References: <6BB76CFA-4134-4D3E-BE20-3A90A5111CBD@nokia.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, "iesg@ietf.org IESG" Subject: Re: [tcpm] status of TCP-MD5 after TCP-AO publication 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: , X-List-Received-Date: Wed, 29 Jul 2009 11:45:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Iljitsch van Beijnum wrote: > On 29 jul 2009, at 12:48, Lars Eggert wrote: > >> at the meeting, the question came up which status TCP-MD5 should have >> after TCP-AO is published. Specifically, whether it should be >> obsoleted by TCP-AO and/or if it should be reclassified as Historic. > > First of all, I'd like to see some operational experience with TCP-AO. > Don't throw away your old shoes until you know whether the new ones fit. > > Second, it's not like TCP-MD5 isn't being used. As such, "historic" > wouldn't apply. "Deprecated", maybe. > > Third, why is it exactly that we can't simply move from MD5 to IPsec to > protect BGP sessions?? This is addressed in the TCP-AO document: - --- This document is not intended to replace the use of the IPsec suite (IPsec and IKE) to protect TCP connections [RFC4301][RFC4306]. In fact, we recommend the use of IPsec and IKE, especially where IKE's level of existing support for parameter negotiation, session key negotiation, or rekeying are desired. TCP-AO is intended for use only where the IPsec suite would not be feasible, e.g., as has been suggested is the case to support some routing protocols, or in cases where keys need to be tightly coordinated with individual transport sessions [Be07]. - --- This document differs from an IPsec/IKE solution in that TCP-AO as follows [RFC4301][RFC4306]: o TCP-AO does not support dynamic parameter negotiation. o TCP-AO uses TCP's socket pair (source address, destination address, source port, destination port) as a security parameter index, rather than using a separate field as an index (IPsec's SPI). o TCP-AO forces a change of computed MACs when a connection restarts, even when reusing a TCP socket pair (IP addresses and port numbers) [Be07]. o TCP-AO does not support encryption. o TCP-AO does not authenticate ICMP messages (some ICMP messages may be authenticated when using IPsec, depending on the configuration). - --- See also the Security Considerations section. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkpwNjYACgkQE5f5cImnZrudFwCfSKoQZC+avY0mvEn1W2Vh/l+7 o/AAnjwO5zwoIXkkp2XtPSWRGsWmb5eX =7zMA -----END PGP SIGNATURE----- From hkchu@google.com Wed Jul 29 07:56:06 2009 Return-Path: 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 A1EC33A6F27 for ; Wed, 29 Jul 2009 07:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.677 X-Spam-Level: X-Spam-Status: No, score=-101.677 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] 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 pE3XFCUifJ9M for ; Wed, 29 Jul 2009 07:56:05 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 27AF33A6D3D for ; Wed, 29 Jul 2009 07:56:05 -0700 (PDT) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id n6TEu4eD016982 for ; Wed, 29 Jul 2009 15:56:05 +0100 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1248879365; bh=wJqF5U8T8Tnnm3KA1cBq1edfo3s=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type:X-System-Of-Record; b=h pyiMDhyx1xi2wJza9z03INdYRHXJIlpqWPNC5ppklTm2faNHjWOY63jk6zPlaDcMp3F fcDG7Envlo4dhdUziQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=Qbt3KDEWHY1/bfVG0a35dFLQMdN68pfuIH7bO1LILj+PWWLlOYQSnJa8wTxQOq/qM y9EIsqsfuRLX9J1Tl+DZg== Received: from an-out-0708.google.com (anac3.prod.google.com [10.100.54.3]) by wpaz29.hot.corp.google.com with ESMTP id n6TEu24a031353 for ; Wed, 29 Jul 2009 07:56:02 -0700 Received: by an-out-0708.google.com with SMTP id c3so405418ana.17 for ; Wed, 29 Jul 2009 07:56:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.105.4 with SMTP id d4mr12045650anc.39.1248879361876; Wed, 29 Jul 2009 07:56:01 -0700 (PDT) In-Reply-To: <20090728183556.A5820385088@lawyers.icir.org> References: <20090728183556.A5820385088@lawyers.icir.org> Date: Wed, 29 Jul 2009 07:56:01 -0700 Message-ID: From: Jerry Chu To: mallman@icir.org Content-Type: multipart/alternative; boundary=0016e64135dcbb6531046fd9623c X-System-Of-Record: true Cc: "tcpm@ietf.org" Subject: Re: [tcpm] initial RTO (was Re: Tuning TCP parameters for the 21st century) 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: , X-List-Received-Date: Wed, 29 Jul 2009 14:56:06 -0000 --0016e64135dcbb6531046fd9623c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mark, On Tue, Jul 28, 2009 at 11:35 AM, Mark Allman wrote: > > Jerry- > > > So the active open side has retransmitted SYN, assuming initRTO of > > 1sec, and eventually received a SYN-ACK but the TS option was > > denied so no good RTT sample can be taken. It will continue to send > > the init data with the initRTO. > > > > If the SYN retransmission has been unnecessary because the initRTO has > > been too aggressive, more SYN-ACK will be triggered. Assuming these > > dup SYN-ACKs are not lost, could they be used as a hint to the active > > open side that the initRTO has been too short, so that the RTO timer > > can be reverted back to 3secs immediately, in time to avoid further > > RTO hell? > > So, you're saying that if you send N SYNs (N>1) and you get N SYN+ACKs > then you take that to mean the initRTO was too short. > > Yeah, perhaps ... > > Are you suggesting something like this ... > > (1) Use an initRTO of 1sec. > > (2) If the RTO fires and you retransmit the SYN back the RTO to 3sec. > (And, if necessary you exponential backoff even more.) > > (3) After the 3WHS you will either (a) have a good RTT sample from the > timestamp option and can therefore set the RTO reasonably or (b) > you retain the 3sec RTO until you get a good RTT sample. > > ?? > > That means that if 1sec is not enough in the 3WHS you have to use 3sec > until you have some idea about the network. However, you also get a > shot [*one shot*] to retransmit sooner based on the notion that most > RTTs are less than 1sec. > > I think I buy that notion ... that both allows for more aggressiveness > for the common case while also protecting against RTO Hell for the long > path cases. Is that the right walking of the line? I can think of a number of variations. The one-shot 1-sec-initRTO idea you described above also came through my mind but the drawback is you only get one-shot even though we know statistically > 98% of connections have RTT < 1 sec so most likely the continuous use of 1-sec-initRTO will turn out to be better. (A counter argument might be one-shot is "good enough", benefitting > 90% of the cases statistically...) The advantage of it is its simplicity, restricting the max # of spurious retransmissions caused by the reduced initRTO to 1, and obviously avoiding the RTO hell problem. A different variation that is slightly more complex but allowing the reduced initRTO to be used more than one-time (hence potentially providing more benefit to those > 98% connections) is to only terminate its use upon the detection of spurious retransmission. Specifically - 1. initRTO = 1sec 2. if a valid pkt with the SYN bit on is received (so it could be either SYN or SYN-ACK) and the following two conditions are met: 2a. the connection state is neither SYN-SENT nor SYN-RCVD 2b. RTO == 1sec (or no good RTT sample has been taken) Simply reset the RTO to 3secs. On a second look it doesn't seem much more complex, although it may be slightly more work to analyze its thoroughness (e.g., what if all the dup SYN/SYN-ACK were lost, or all come back late...) Also it does incur more spurious pkts for those connections with RTT > 2sec. What do you think? Jerry > > allman > > > > --0016e64135dcbb6531046fd9623c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mark,

On Tue, Jul 28, 2009 at 11:35 AM, M= ark Allman <mallma= n@icir.org> wrote:

Jerry-

> So the active open side has retransmitted SYN, assuming initRTO of
> 1sec, and eventually received a SYN-ACK but the TS option was
> denied so no good RTT sample can be taken. It will continue to send > the init data with the initRTO.
>
> If the SYN retransmission has been unnecessary because the initRTO has=
> been too aggressive, more SYN-ACK will be triggered. Assuming these > dup SYN-ACKs are not lost, could they be used as a hint to the active<= br> > open side that the initRTO has been too short, so that the RTO timer > can be reverted back to 3secs immediately, in time to avoid further > RTO hell?

So, you're saying that if you send N SYNs (N>1) and you get N = SYN+ACKs
then you take that to mean the initRTO was too short.

Yeah, perhaps ...

Are you suggesting something like this ...

=A0(1) Use an initRTO of 1sec.

=A0(2) If the RTO fires and you retransmit the SYN back the RTO to 3sec. =A0 =A0 =A0(And, if necessary you exponential backoff even more.)

=A0(3) After the 3WHS you will either (a) have a good RTT sample from the<= br> =A0 =A0 =A0timestamp option and can therefore set the RTO reasonably or (b= )
=A0 =A0 =A0you retain the 3sec RTO until you get a good RTT sample.

??

That means that if 1sec is not enough in the 3WHS you have to use 3sec
until you have some idea about the network. =A0However, you also get a
shot [*one shot*] to retransmit sooner based on the notion that most
RTTs are less than 1sec.

I think I buy that notion ... that both allows for more aggressiveness
for the common case while also protecting against RTO Hell for the long
path cases. =A0Is that the right walking of the line?

= I can think of a number of variations. The one-shot 1-sec-initRTO idea you<= br>described above also came through my mind but the drawback is you only get one-shot even though we know statistically > 98% of connections
h= ave RTT < 1 sec so most likely the continuous use of 1-sec-initRTO will = turn
out to be better. (A counter argument might be one-shot is "go= od enough",
benefitting > 90% of the cases statistically...) The advantage of it is = its simplicity,
restricting the max # of spurious retransmissions caused= by the reduced initRTO
to 1, and obviously avoiding the RTO hell proble= m.

A different variation that is slightly more complex but allowing the re= duced
initRTO to be used more than one-time (hence potentially providing= more benefit
to those > 98% connections) is to only terminate its us= e upon the detection
of spurious retransmission. Specifically -

1. initRTO =3D 1sec
2.= if a valid pkt with the SYN bit on is received (so it could be either SYN = or
SYN-ACK) and the following two conditions are met:
=A0 2a. the con= nection state is neither SYN-SENT nor SYN-RCVD
=A0 2b. RTO =3D=3D 1sec (or no good RTT sample has been taken)
Simply re= set the RTO to 3secs.

On a second look it doesn't seem much more= complex, although it may be
slightly more work to analyze its thoroughn= ess (e.g., what if all the dup
SYN/SYN-ACK were lost, or all come back late...) Also it does incur
more= spurious pkts for those connections with RTT > 2sec.

What do you= think?

Jerry



allman




--0016e64135dcbb6531046fd9623c-- From mallman@icir.org Wed Jul 29 09:06:06 2009 Return-Path: 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 8A3313A6F33 for ; Wed, 29 Jul 2009 09:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 yGPisp2wePIK for ; Wed, 29 Jul 2009 09:06:05 -0700 (PDT) Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id 9C7D13A6830 for ; Wed, 29 Jul 2009 09:06:05 -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 n6TG64nN010804; Wed, 29 Jul 2009 09:06:04 -0700 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 2A7503BD69C4; Wed, 29 Jul 2009 12:05:57 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 122DF3884F5; Wed, 29 Jul 2009 12:05:59 -0400 (EDT) To: Jerry Chu From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Sweet Emotion MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma29542-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 29 Jul 2009 12:05:58 -0400 Sender: mallman@icir.org Message-Id: <20090729160559.122DF3884F5@lawyers.icir.org> Cc: "tcpm@ietf.org" Subject: Re: [tcpm] initial RTO (was Re: Tuning TCP parameters for the 21st century) 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: , X-List-Received-Date: Wed, 29 Jul 2009 16:06:06 -0000 ----------ma29542-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > I can think of a number of variations. The one-shot 1-sec-initRTO idea > you described above also came through my mind but the drawback is you > only get one-shot even though we know statistically > 98% of > connections have RTT < 1 sec so most likely the continuous use of > 1-sec-initRTO will turn out to be better. (A counter argument might be > one-shot is "good enough", benefitting > 90% of the cases > statistically...) The advantage of it is its simplicity, restricting > the max # of spurious retransmissions caused by the reduced initRTO to > 1, and obviously avoiding the RTO hell problem. Two responses to "one shot": (1) Yes, one-shot ought to be enough. Considering losing the SYN, retransmitting it using an initRTO of 1sec and reseting the initRTO to 3sec. Now, if there is actually loss in the first RTT of data transmission talking about fine-grained performance (i.e., that we can get from using 1sec again instead of 3sec) doesn't make a lot of sense because 1sec vs. 3sec doesn't matter because performance is going to suck no matter what. So, why bother with anything terribly "smart" here? (2) Using the numbers on your slides it seems to me that the fraction of hosts with an RTT of > 1sec is roughly the same as the SYN retransmit rate (at an RTT of 3sec, I assume). To me that says that if you use an initRTO of 1sec and then retransmit then the reason for that retransmit is just as likely to be loss as it is to be a long path. So, your approach of preferring more than one-shot assumes loss. But, I don't see the measurements you gave as suggesting that is the right approach. The notion of going back to 3sec just sort of punts. I.e., the notion is that we have hit a situation whereby we don't know what is going on and so let's not dogmatically try to push forward, but let's throw up our hands and try to do things that ultimately will figure out what is going on. And, further, one mistake does not propagate. So, for me one-shot is just about the right balance here. Any more than that we're getting into the corner of a corner case and further in that corner the empirical evidence is not suggestive of a clear path. So, let's just do something that will allow the protocol to get a handle on things as they are in the specific situation and not try to make guesses that propagate further. allman ----------ma29542-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkpwc2YACgkQWyrrWs4yIs6vawCdEAyR1DK3GBoSCb7gitsyS0hO MAYAoIrn3KY9I6CFs4aLgWfeAHvQE2pf =JwQR -----END PGP SIGNATURE----- ----------ma29542-1-- From L.Wood@surrey.ac.uk Thu Jul 30 01:27:59 2009 Return-Path: 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 D454D28C1E6 for ; Thu, 30 Jul 2009 01:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=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 wQWMjogNpyKI for ; Thu, 30 Jul 2009 01:27:58 -0700 (PDT) Received: from mail83.messagelabs.com (mail83.messagelabs.com [195.245.231.83]) by core3.amsl.com (Postfix) with SMTP id 16EFB28C218 for ; Thu, 30 Jul 2009 01:27:57 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-8.tower-83.messagelabs.com!1248942476!50636918!1 X-StarScan-Version: 6.1.2; banners=-,-,- X-Originating-IP: [131.227.102.140] Received: (qmail 31697 invoked from network); 30 Jul 2009 08:27:56 -0000 Received: from ads40.surrey.ac.uk (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-8.tower-83.messagelabs.com with SMTP; 30 Jul 2009 08:27:56 -0000 Received: from EVS-EC1-NODE4.surrey.ac.uk ([131.227.102.145]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 09:27:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA10EF.A382F661" Date: Thu, 30 Jul 2009 09:27:55 +0100 Message-ID: <4835AFD53A246A40A3B8DA85D658C4BE0136891A@EVS-EC1-NODE4.surrey.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] initial RTO (was Re: Tuning TCP parameters for the 21st century) Thread-Index: AcoPskrFnef0JXkmSROcNgOfPDCsxgBPBIoP References: <20090728183556.A5820385088@lawyers.icir.org> From: To: , X-OriginalArrivalTime: 30 Jul 2009 08:27:56.0605 (UTC) FILETIME=[A3DF9ED0:01CA10EF] Cc: tcpm@ietf.org Subject: Re: [tcpm] initial RTO (was Re: Tuning TCP parameters for the 21st century) 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: , X-List-Received-Date: Thu, 30 Jul 2009 08:27:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA10EF.A382F661 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It's necessary to disambiguate which ACK is for which SYN -=20 i.e. if you have a _very_ long-delay path, you might send out three SYNs before an ACK to the first SYN comes in. But it appears at the time to be an ACK to the third SYN, with other responses lost in transit. So SYN timestamps really are necessary to disambiguate in this situation. I can see a cascading sequence where the first ACK comes in just after say the fifth SYN goes out, and it's immediately necessary to bump the RTO up to tens of seconds. related discussion of this is in our TCP Protocol Radius paper: http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/index.html#p= rotocol-radius esp. Fig 2. L. -----Original Message----- From: tcpm-bounces@ietf.org on behalf of Mark Allman Sent: Tue 2009-07-28 19:35 To: Jerry Chu Cc: tcpm@ietf.org Subject: Re: [tcpm] initial RTO (was Re: Tuning TCP parameters for the = 21st century) =20 Jerry- > So the active open side has retransmitted SYN, assuming initRTO of > 1sec, and eventually received a SYN-ACK but the TS option was > denied so no good RTT sample can be taken. It will continue to send > the init data with the initRTO. >=20 > If the SYN retransmission has been unnecessary because the initRTO has > been too aggressive, more SYN-ACK will be triggered. Assuming these > dup SYN-ACKs are not lost, could they be used as a hint to the active > open side that the initRTO has been too short, so that the RTO timer > can be reverted back to 3secs immediately, in time to avoid further > RTO hell? So, you're saying that if you send N SYNs (N>1) and you get N SYN+ACKs then you take that to mean the initRTO was too short. Yeah, perhaps ...=20 Are you suggesting something like this ... (1) Use an initRTO of 1sec. (2) If the RTO fires and you retransmit the SYN back the RTO to 3sec. (And, if necessary you exponential backoff even more.) (3) After the 3WHS you will either (a) have a good RTT sample from the timestamp option and can therefore set the RTO reasonably or (b) you retain the 3sec RTO until you get a good RTT sample. ?? That means that if 1sec is not enough in the 3WHS you have to use 3sec until you have some idea about the network. However, you also get a shot [*one shot*] to retransmit sooner based on the notion that most RTTs are less than 1sec. =20 I think I buy that notion ... that both allows for more aggressiveness for the common case while also protecting against RTO Hell for the long path cases. Is that the right walking of the line? allman ------_=_NextPart_001_01CA10EF.A382F661 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [tcpm] initial RTO (was Re: Tuning TCP parameters for the = 21st century)

It's necessary to disambiguate which ACK is for which = SYN -
i.e. if you have a _very_ long-delay path, you might send out
three SYNs before an ACK to the first SYN comes in. But it appears
at the time to be an ACK to the third SYN, with other
responses lost in transit. So SYN timestamps really are
necessary to disambiguate in this situation. I can see
a cascading sequence where the first ACK comes in just after say
the fifth SYN goes out, and it's immediately necessary to
bump the RTO up to tens of seconds.

related discussion of this is in our TCP Protocol Radius paper:
http://personal.ee.surrey.ac.uk/Personal/L.Wood/p= ublications/index.html#protocol-radius
esp. Fig 2.

L.

<http://www.ee.surrey= .ac.uk/Personal/L.Wood/><L.Wood@surrey.ac.uk>



-----Original Message-----
From: tcpm-bounces@ietf.org on behalf of Mark Allman
Sent: Tue 2009-07-28 19:35
To: Jerry Chu
Cc: tcpm@ietf.org
Subject: Re: [tcpm] initial RTO (was Re: Tuning TCP parameters for the = 21st century)


Jerry-

> So the active open side has retransmitted SYN, assuming initRTO = of
> 1sec, and eventually received a SYN-ACK but the TS option was
> denied so no good RTT sample can be taken. It will continue to = send
> the init data with the initRTO.
>
> If the SYN retransmission has been unnecessary because the initRTO = has
> been too aggressive, more SYN-ACK will be triggered. Assuming = these
> dup SYN-ACKs are not lost, could they be used as a hint to the = active
> open side that the initRTO has been too short, so that the RTO = timer
> can be reverted back to 3secs immediately, in time to avoid = further
> RTO hell?

So, you're saying that if you send N SYNs (N>1) and you get N = SYN+ACKs
then you take that to mean the initRTO was too short.

Yeah, perhaps ...

Are you suggesting something like this ...

  (1) Use an initRTO of 1sec.

  (2) If the RTO fires and you retransmit the SYN back the RTO to = 3sec.
      (And, if necessary you exponential = backoff even more.)

  (3) After the 3WHS you will either (a) have a good RTT sample = from the
      timestamp option and can therefore set = the RTO reasonably or (b)
      you retain the 3sec RTO until you get a = good RTT sample.

??

That means that if 1sec is not enough in the 3WHS you have to use = 3sec
until you have some idea about the network.  However, you also get = a
shot [*one shot*] to retransmit sooner based on the notion that most
RTTs are less than 1sec. 

I think I buy that notion ... that both allows for more = aggressiveness
for the common case while also protecting against RTO Hell for the = long
path cases.  Is that the right walking of the line?

allman

------_=_NextPart_001_01CA10EF.A382F661-- From mallman@icir.org Thu Jul 30 04:41:28 2009 Return-Path: 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 77A8728C156 for ; Thu, 30 Jul 2009 04:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 93xFlU9lALon for ; Thu, 30 Jul 2009 04:41: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 7797B28C155 for ; Thu, 30 Jul 2009 04:41:27 -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 n6UBfQpf004950; Thu, 30 Jul 2009 04:41:26 -0700 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 664913BDC503; Thu, 30 Jul 2009 07:41:18 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id F0DA138A214; Thu, 30 Jul 2009 07:41:19 -0400 (EDT) To: L.Wood@surrey.ac.uk From: Mark Allman In-Reply-To: <4835AFD53A246A40A3B8DA85D658C4BE0136891A@EVS-EC1-NODE4.surrey.ac.uk> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Sweet Emotion MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma34525-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 30 Jul 2009 07:41:19 -0400 Sender: mallman@icir.org Message-Id: <20090730114119.F0DA138A214@lawyers.icir.org> Cc: tcpm@ietf.org Subject: Re: [tcpm] initial RTO (was Re: Tuning TCP parameters for the 21st century) 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: , X-List-Received-Date: Thu, 30 Jul 2009 11:41:28 -0000 ----------ma34525-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > It's necessary to disambiguate which ACK is for which SYN - i.e. if > you have a _very_ long-delay path, you might send out three SYNs > before an ACK to the first SYN comes in. But it appears at the time to > be an ACK to the third SYN, with other responses lost in transit. So > SYN timestamps really are necessary to disambiguate in this > situation. I can see a cascading sequence where the first ACK comes in > just after say the fifth SYN goes out, and it's immediately necessary > to bump the RTO up to tens of seconds. Sure. I guess Jerry and I are talking about the case where with exceedingly high probability the RTT is covered by the current 3sec RTO and the vast majority of the connections have an RTT of less than 1sec. (So, say, 99.99999% < 3sec and 98% < 1sec.) So, how then do we use 1sec for the common case, but still reasonably accommodate the fraction that have RTTs > 1sec but < 3sec? Would it be nice to keep pushing and accommodate connections with even larger RTTs? Ideally, yeah. But, I am not sure imposing timestamps or other mechanisms on everyone to deal with that case is useful. At some point you have to engineer your edge case for what it is. allman ----------ma34525-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkpxht8ACgkQWyrrWs4yIs4h3gCeMEe1iApSgSBTCQaIEM/MUyZ5 lRcAnRFx7/3dKtSiTgLkTTNEoBZIychM =j93g -----END PGP SIGNATURE----- ----------ma34525-1-- From L.Wood@surrey.ac.uk Thu Jul 30 04:51:55 2009 Return-Path: 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 5745C28C1FE for ; Thu, 30 Jul 2009 04:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, 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 vF67ThmlLufk for ; Thu, 30 Jul 2009 04:51:54 -0700 (PDT) Received: from mail83.messagelabs.com (mail83.messagelabs.com [195.245.231.83]) by core3.amsl.com (Postfix) with SMTP id 0DC9428C1D8 for ; Thu, 30 Jul 2009 04:51:53 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-11.tower-83.messagelabs.com!1248954714!50589405!1 X-StarScan-Version: 6.1.2; banners=-,-,- X-Originating-IP: [131.227.102.140] Received: (qmail 6098 invoked from network); 30 Jul 2009 11:51:54 -0000 Received: from ads40.surrey.ac.uk (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-11.tower-83.messagelabs.com with SMTP; 30 Jul 2009 11:51:54 -0000 Received: from EVS-EC1-NODE4.surrey.ac.uk ([131.227.102.145]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 12:51:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA110C.21AA0B0F" Date: Thu, 30 Jul 2009 12:51:40 +0100 Message-ID: <4835AFD53A246A40A3B8DA85D658C4BE0136891C@EVS-EC1-NODE4.surrey.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] initial RTO (was Re: Tuning TCP parameters for the 21st century) Thread-Index: AcoRCrEyfIeOfuvURNGGvYW6nTd3uAAAWiC+ References: <20090730114119.F0DA138A214@lawyers.icir.org> From: To: X-OriginalArrivalTime: 30 Jul 2009 11:51:53.0913 (UTC) FILETIME=[21E0A290:01CA110C] Cc: tcpm@ietf.org Subject: Re: [tcpm] initial RTO (was Re: Tuning TCP parameters for the 21st century) 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: , X-List-Received-Date: Thu, 30 Jul 2009 11:51:55 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA110C.21AA0B0F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SYN timestamps benefit _all_ cases... -----Original Message----- From: Mark Allman [mailto:mallman@icir.org] Sent: Thu 2009-07-30 12:41 To: Wood L Dr (Electronic Eng) Cc: hkchu@google.com; tcpm@ietf.org Subject: Re: [tcpm] initial RTO (was Re: Tuning TCP parameters for the = 21st century)=20 =20 > It's necessary to disambiguate which ACK is for which SYN - i.e. if > you have a _very_ long-delay path, you might send out three SYNs > before an ACK to the first SYN comes in. But it appears at the time to > be an ACK to the third SYN, with other responses lost in transit. So > SYN timestamps really are necessary to disambiguate in this > situation. I can see a cascading sequence where the first ACK comes in > just after say the fifth SYN goes out, and it's immediately necessary > to bump the RTO up to tens of seconds. Sure. I guess Jerry and I are talking about the case where with exceedingly high probability the RTT is covered by the current 3sec RTO and the vast majority of the connections have an RTT of less than 1sec. (So, say, 99.99999% < 3sec and 98% < 1sec.) So, how then do we use 1sec for the common case, but still reasonably accommodate the fraction that have RTTs > 1sec but < 3sec? Would it be nice to keep pushing and accommodate connections with even larger RTTs? Ideally, yeah. But, I am not sure imposing timestamps or other mechanisms on everyone to deal with that case is useful. At some point you have to engineer your edge case for what it is. allman ------_=_NextPart_001_01CA110C.21AA0B0F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [tcpm] initial RTO (was Re: Tuning TCP parameters for the = 21st century)

SYN timestamps benefit _all_ cases...

<http://www.ee.surrey= .ac.uk/Personal/L.Wood/><L.Wood@surrey.ac.uk>



-----Original Message-----
From: Mark Allman [mailto:mallman@icir.org]
Sent: Thu 2009-07-30 12:41
To: Wood L Dr (Electronic Eng)
Cc: hkchu@google.com; tcpm@ietf.org
Subject: Re: [tcpm] initial RTO (was Re: Tuning TCP parameters for the = 21st century)


> It's necessary to disambiguate which ACK is for which SYN - i.e. = if
> you have a _very_ long-delay path, you might send out three = SYNs
> before an ACK to the first SYN comes in. But it appears at the time = to
> be an ACK to the third SYN, with other responses lost in transit. = So
> SYN timestamps really are necessary to disambiguate in this
> situation. I can see a cascading sequence where the first ACK comes = in
> just after say the fifth SYN goes out, and it's immediately = necessary
> to bump the RTO up to tens of seconds.

Sure.

I guess Jerry and I are talking about the case where with = exceedingly
high probability the RTT is covered by the current 3sec RTO and the = vast
majority of the connections have an RTT of less than 1sec.  (So, = say,
99.99999% < 3sec and 98% < 1sec.)  So, how then do we use = 1sec for the
common case, but still reasonably accommodate the fraction that have
RTTs > 1sec but < 3sec?

Would it be nice to keep pushing and accommodate connections with = even
larger RTTs?  Ideally, yeah.  But, I am not sure imposing = timestamps or
other mechanisms on everyone to deal with that case is useful.  At = some
point you have to engineer your edge case for what it is.

allman

------_=_NextPart_001_01CA110C.21AA0B0F-- From dab@weston.borman.com Thu Jul 30 05:46:35 2009 Return-Path: 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 95EB428C1D9 for ; Thu, 30 Jul 2009 05:46:35 -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 su2itmxZ9ztN for ; Thu, 30 Jul 2009 05:46:34 -0700 (PDT) Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id D74743A7191 for ; Thu, 30 Jul 2009 05:46:34 -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 n6UCkXRJ026361; Thu, 30 Jul 2009 05:46:35 -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, 30 Jul 2009 05:46:33 -0700 Received: from dhcp-53da.meeting.ietf.org ([147.11.233.22]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Jul 2009 05:46:33 -0700 Message-Id: From: David Borman To: tcpm Extensions WG In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 30 Jul 2009 14:46:31 +0200 References: X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 30 Jul 2009 12:46:33.0794 (UTC) FILETIME=[C4D6C220:01CA1113] Cc: tsv-ads@tools.ietf.org Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security 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: , X-List-Received-Date: Thu, 30 Jul 2009 12:46:35 -0000 Based on the response to this poll, and the subsequent discussion at the IETF meeting this week, there is clear consensus to take this on as a WG item. We will be kicking off various discussions in separate messages to the TCPM list. -David Borman & Wes Eddy, TCPM co-chairs On Jun 24, 2009, at 9:25 PM, Eddy, Wesley M. (GRC-MS00)[Verizon] wrote: > TCPMers, there was a thread a while ago about working on > draft-gont-tcp-security in this working group that didn't > conclusively give us a feeling one way or other: > http://www.ietf.org/mail-archive/web/tcpm/current/msg04489.html > > Basically, my understanding is that there are at least a > handful of people in the WG that think it should be done > here as a WG item (more likely for Informational rather > than BCP), and there are also some expressed opinions on > why it shouldn't. > > Given the raw size of the document, if the WG intends to > take this document on, then we need some people to clearly > commit to putting cycles into review and contributions to > the document. Since it is quite large, and to my knowledge, > there hasn't been a specific technical review of the content > on this list, but just discussions about if the idea in > general is a good or bad thing, we still need to know if > people are willing to invest their time and energy in this. > > Please let us know if there is traction for this in the > near term, and/or we can also discuss it in Stockholm. > > --------------------------- > Wes Eddy > Network & Systems Architect > Verizon FNS / NASA GRC > Office: (216) 433-6682 > --------------------------- > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From hkchu@google.com Thu Jul 30 09:38:08 2009 Return-Path: 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 D61B028C1A8 for ; Thu, 30 Jul 2009 09:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.827 X-Spam-Level: X-Spam-Status: No, score=-101.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] 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 Ndt98vNj5wRy for ; Thu, 30 Jul 2009 09:38:08 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 0738D28C186 for ; Thu, 30 Jul 2009 09:38:07 -0700 (PDT) Received: from spaceape12.eur.corp.google.com (spaceape12.eur.corp.google.com [172.28.16.146]) by smtp-out.google.com with ESMTP id n6UGc8P1012054 for ; Thu, 30 Jul 2009 09:38:09 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1248971889; bh=lbSITgUjpJz4P8F+hiF7DgjlcHY=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type: Content-Transfer-Encoding:X-System-Of-Record; b=QSTjIObebof5tviK4O sxIIWrQzBcFvTFJ1rywrCou7kYyZnjeuXXwwCx7mH7ILzBAECmBBS9qzGORk0G/ij67 A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=dDUcpPaf5zLC8Ip7mA02sGx+ngAkDjij/3m4ihFdl1P9vo+f+tn7E4ZIYfley0oYq Hr4MqkkgMnc8XJdtUhb3A== Received: from an-out-0708.google.com (anac3.prod.google.com [10.100.54.3]) by spaceape12.eur.corp.google.com with ESMTP id n6UGc533005641 for ; Thu, 30 Jul 2009 09:38:06 -0700 Received: by an-out-0708.google.com with SMTP id c3so839825ana.28 for ; Thu, 30 Jul 2009 09:38:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.91.3 with SMTP id o3mr740624anb.157.1248971885090; Thu, 30 Jul 2009 09:38:05 -0700 (PDT) In-Reply-To: <20090729160559.122DF3884F5@lawyers.icir.org> References: <20090729160559.122DF3884F5@lawyers.icir.org> Date: Thu, 30 Jul 2009 09:38:05 -0700 Message-ID: From: Jerry Chu To: mallman@icir.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "tcpm@ietf.org" Subject: Re: [tcpm] initial RTO (was Re: Tuning TCP parameters for the 21st century) 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: , X-List-Received-Date: Thu, 30 Jul 2009 16:38:08 -0000 On Wed, Jul 29, 2009 at 9:05 AM, Mark Allman wrote: > >> I can think of a number of variations. The one-shot 1-sec-initRTO idea >> you described above also came through my mind but the drawback is you >> only get one-shot even though we know statistically > 98% of >> connections have RTT < 1 sec so most likely the continuous use of >> 1-sec-initRTO will turn out to be better. (A counter argument might be >> one-shot is "good enough", benefitting > 90% of the cases >> statistically...) The advantage of it is its simplicity, restricting >> the max # of spurious retransmissions caused by the reduced initRTO to >> 1, and obviously avoiding the RTO hell problem. > > Two responses to "one shot": > > (1) Yes, one-shot ought to be enough. =A0Considering losing the SYN, > =A0 =A0retransmitting it using an initRTO of 1sec and reseting the initRT= O > =A0 =A0to 3sec. =A0Now, if there is actually loss in the first RTT of dat= a > =A0 =A0transmission talking about fine-grained performance (i.e., that we > =A0 =A0can get from using 1sec again instead of 3sec) doesn't make a lot = of > =A0 =A0sense because 1sec vs. 3sec doesn't matter because performance is > =A0 =A0going to suck no matter what. =A0So, why bother with anything terr= ibly > =A0 =A0"smart" here? Guess we have some disagreement here and it's not surprise - although we seem to agree upon the general principles - keep it simple, focus on the main benefit not the corner cases, but both principles involve some degree of subjective calls. E.g., the exit condition to initRTO of 1sec suggested in my previous email doesn't seem all that complex to me. It only involves a simple check of dupack (or dup SYN/SYN-ACK). Also I'm not sure why performance has to suck just because a connection experience early (e.g., SYN/SYN-ACK) loss? I don't remember if TCP spec requires a connection to go into congestion avoidance mode after SYN/SYN-ACK loss? Even if so, for short lived connections with small amount of data (e.g., HTTP/TCP), a speedy recovery from a more optimal RTO value does still seem matter. Also the reason for a possible speedy recovery for a loss event AFTER 3WHS seems equally valid as the one for 3WHS, assuming these loss events are stochastically independent of each other.., > > (2) Using the numbers on your slides it seems to me that the fraction of > =A0 =A0hosts with an RTT of > 1sec is roughly the same as the SYN > =A0 =A0retransmit rate (at an RTT of 3sec, I assume). =A0To me that says = that > =A0 =A0if you use an initRTO of 1sec and then retransmit then the reason > =A0 =A0for that retransmit is just as likely to be loss as it is to be a > =A0 =A0long path. =A0So, your approach of preferring more than one-shot > =A0 =A0assumes loss. =A0But, I don't see the measurements you gave as > =A0 =A0suggesting that is the right approach. =A0The notion of going back= to > =A0 =A03sec just sort of punts. =A0I.e., the notion is that we have hit a > =A0 =A0situation whereby we don't know what is going on and so let's not > =A0 =A0dogmatically try to push forward, but let's throw up our hands and > =A0 =A0try to do things that ultimately will figure out what is going on. > =A0 =A0And, further, one mistake does not propagate. Again I agree with your statements in general but I just feel one-shot is a little weak, shy of being "good enough". How about allowing N shots where N is some TBD (> 1) number? I suspect N=3D2 may satisfy the "good enough" criterion, taking cue from MacOS (see my slides on MacOS's repeated 1sec RTO 5 times...) There may be a couple of different flavors of allowing N shots, either consecutive-only or not but that's details. > > So, for me one-shot is just about the right balance here. =A0Any more tha= n > that we're getting into the corner of a corner case and further in that > corner the empirical evidence is not suggestive of a clear path. =A0So, > let's just do something that will allow the protocol to get a handle on > things as they are in the specific situation and not try to make guesses > that propagate further. The N-shot solution doesn't add any complexity (just log(N) more bits to the TCP structure) and seems a strong enough dose for those HTTP connections suffering the dreadful 3sec pause. Jerry > > allman > > > > From hkchu@google.com Thu Jul 30 09:46:01 2009 Return-Path: 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 5E53B3A68EF for ; Thu, 30 Jul 2009 09:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.577 X-Spam-Level: X-Spam-Status: No, score=-101.577 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] 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 mn9tuC7o3bbQ for ; Thu, 30 Jul 2009 09:46:00 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 90FED3A6C30 for ; Thu, 30 Jul 2009 09:45:59 -0700 (PDT) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id n6UGk0a7010536 for ; Thu, 30 Jul 2009 09:46:01 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1248972361; bh=0/Kmi7raXnIJukRWuIhyY/8lwLM=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type: Content-Transfer-Encoding:X-System-Of-Record; b=NrW1ybRzAwk5CMIpgd n4NmKTSgq0E6g61ksCvSS1QPMuJ7cBBSaSRS9lqcUf7c/+jLLAzNtz+vKee3+QkVB15 w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=p2Ck7UFEFIfA36PZ7KwMr6ew27duOcwdhaIYQGG0KloVxNI+0/EUjYNDgkxOUQu1f TFUpursBRkbN/DNQA0x+A== Received: from ywh15 (ywh15.prod.google.com [10.192.8.15]) by wpaz1.hot.corp.google.com with ESMTP id n6UGjwAK011317 for ; Thu, 30 Jul 2009 09:45:58 -0700 Received: by ywh15 with SMTP id 15so890512ywh.10 for ; Thu, 30 Jul 2009 09:45:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.239.16 with SMTP id m16mr1743454anh.192.1248972358250; Thu, 30 Jul 2009 09:45:58 -0700 (PDT) In-Reply-To: <4835AFD53A246A40A3B8DA85D658C4BE0136891A@EVS-EC1-NODE4.surrey.ac.uk> References: <20090728183556.A5820385088@lawyers.icir.org> <4835AFD53A246A40A3B8DA85D658C4BE0136891A@EVS-EC1-NODE4.surrey.ac.uk> Date: Thu, 30 Jul 2009 09:45:58 -0700 Message-ID: From: Jerry Chu To: L.Wood@surrey.ac.uk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: tcpm@ietf.org, mallman@icir.org Subject: Re: [tcpm] initial RTO (was Re: Tuning TCP parameters for the 21st century) 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: , X-List-Received-Date: Thu, 30 Jul 2009 16:46:01 -0000 On Thu, Jul 30, 2009 at 1:27 AM, wrote: > It's necessary to disambiguate which ACK is for which SYN - > i.e. if you have a _very_ long-delay path, you might send out > three SYNs before an ACK to the first SYN comes in. But it appears > at the time to be an ACK to the third SYN, with other > responses lost in transit. So SYN timestamps really are > necessary to disambiguate in this situation. I can see > a cascading sequence where the first ACK comes in just after say > the fifth SYN goes out, and it's immediately necessary to > bump the RTO up to tens of seconds. One solution I proposed only requires the detection of sprurious retransmission so it doesn't need to match ACKs with their SYNs, as long as any dupack is received... Jerry > > related discussion of this is in our TCP Protocol Radius paper: > http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/index.html#p= rotocol-radius > esp. Fig 2. > > L. > > > > > > -----Original Message----- > From: tcpm-bounces@ietf.org on behalf of Mark Allman > Sent: Tue 2009-07-28 19:35 > To: Jerry Chu > Cc: tcpm@ietf.org > Subject: Re: [tcpm] initial RTO (was Re: Tuning TCP parameters for the 21= st > century) > > > Jerry- > >> So the active open side has retransmitted SYN, assuming initRTO of >> 1sec, and eventually received a SYN-ACK but the TS option was >> denied so no good RTT sample can be taken. It will continue to send >> the init data with the initRTO. >> >> If the SYN retransmission has been unnecessary because the initRTO has >> been too aggressive, more SYN-ACK will be triggered. Assuming these >> dup SYN-ACKs are not lost, could they be used as a hint to the active >> open side that the initRTO has been too short, so that the RTO timer >> can be reverted back to 3secs immediately, in time to avoid further >> RTO hell? > > So, you're saying that if you send N SYNs (N>1) and you get N SYN+ACKs > then you take that to mean the initRTO was too short. > > Yeah, perhaps ... > > Are you suggesting something like this ... > > =A0 (1) Use an initRTO of 1sec. > > =A0 (2) If the RTO fires and you retransmit the SYN back the RTO to 3sec. > =A0=A0=A0=A0=A0 (And, if necessary you exponential backoff even more.) > > =A0 (3) After the 3WHS you will either (a) have a good RTT sample from th= e > =A0=A0=A0=A0=A0 timestamp option and can therefore set the RTO reasonably= or (b) > =A0=A0=A0=A0=A0 you retain the 3sec RTO until you get a good RTT sample. > > ?? > > That means that if 1sec is not enough in the 3WHS you have to use 3sec > until you have some idea about the network.=A0 However, you also get a > shot [*one shot*] to retransmit sooner based on the notion that most > RTTs are less than 1sec. > > I think I buy that notion ... that both allows for more aggressiveness > for the common case while also protecting against RTO Hell for the long > path cases.=A0 Is that the right walking of the line? > > allman > > > > > > From mallman@icir.org Thu Jul 30 12:22:36 2009 Return-Path: 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 83EC83A7216 for ; Thu, 30 Jul 2009 12:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, 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 COj4zmI37abD for ; Thu, 30 Jul 2009 12:22:35 -0700 (PDT) Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id A84063A6BE0 for ; Thu, 30 Jul 2009 12:22:35 -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 n6UJMXuH017024; Thu, 30 Jul 2009 12:22:33 -0700 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id C6F883BDEBE8; Thu, 30 Jul 2009 15:22:25 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 94B8C38CAEC; Thu, 30 Jul 2009 15:22:27 -0400 (EDT) To: Jerry Chu From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Sweet Emotion MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma62193-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 30 Jul 2009 15:22:27 -0400 Sender: mallman@icir.org Message-Id: <20090730192227.94B8C38CAEC@lawyers.icir.org> Cc: "tcpm@ietf.org" Subject: Re: [tcpm] initial RTO (was Re: Tuning TCP parameters for the 21st century) 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: , X-List-Received-Date: Thu, 30 Jul 2009 19:22:36 -0000 ----------ma62193-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Jerry- Let's put some (rough; based on your slides) numbers to things here ... + With an initRTO of 3sec your data suggests that 98% of the connections complete the 3WHS without retransmitting. So, in 2% of the connections we in fact lose a SYN. + Also, you note that something like 2% of the connections have an RTT longer than 1sec. (And, I am making the assumption that is really > 1sec and < 3sec.) + So, with an initRTO of 1sec we'd expect to see 2% of the connections experience loss, 2% of the connections have a long RTT and spuriously retransmit which leaves 96% of the connections Just Working. (All in rough terms.) + Forget the 96%... they are good to go. They got an RTT sample in the 3WHS and so presumably are working fine and no longer have to worry about the initRTO. + The 2% of the connections that experienced loss will have each saved 2sec in the 3WHS by using an initRTO of 1sec vs. 3sec. So, if we care about X connections that's an aggregate savings of X*0.02*2sec when using an initRTO of 1sec versus using an initRTO of 3sec (which yields 0sec of savings). + The connections that experienced loss will send data in the first RTT (say) and experience another 2% loss rate. If we have a try-2 approach and again use an initRTO of 1sec then this would save each of these connections 2sec over my notion of reverting the initRTO to 3sec. In the aggregate the savings here is X*0.0*0.02*2sec. + So, now we have saved X*0.02*2sec + X*0.02*0.02*2sec with a try-2 approach vs. X*0.02*2sec with a try-1 approach. For X=10K connections that is a difference of 8sec in the aggregate (400sec with try-1 vs. 408sec with try-2)---or, less than 1msec per connection on average if you'd like to do it that way. + Then there are the spurious RTOs caused by lowering the initRTO to 1sec. We'll have 2% of those in the 3WHS. The problem is that keeping the initRTO at 1sec **ensures** a spurious retransmit in the first RTT of data transfer, too. So, the cwnd will be reduced to an MSS, no RTT sample will be taken again, linear increase will be forced upon the connection, etc. + (Note, I am ignoring connections that use timestamps. Connections that successfully use timestamps will have an RTT sample from the 3WHS and therefore we don't have to worry about the initRTO further.) To me the tradeoff is clearly in favor of try-1. For the advantage of a *tiny* time savings to the 0.02*0.02 of connections that experience loss in both the 3WHS and the initial window of data (i.e., what try-2 would help) you pay by dooming 0.02 of the connections (that now work fine, BTW) to no exponential ramp up. That might be a tradeoff you are personally willing to make---i.e., to sacrifice one type of connection in favor of another. But, I don't see that as a good tradeoff for the standards to make. Also, note, your scheme of counting SYNs is not overly complicated and does not have overly onerous state requirements. I didn't mean to indicate either of those. However, it isn't terribly robust either and I am not ultimately sure how it'd play out. So, say a connection has a 2sec RTT (works with others, too): 0.0 xmit SYN 1.0 RTO (==1sec), rexmit SYN 2.0 rec SYN+ACK (from original transmit) / send ACK / send DATA 3.0 resend DATA 3.0 rec SYN+ACK (from retransmit) Those last two events represent a race condition. I.e., in this case, we hope we get the SYN+ACK before we resend the data because then we can use your scheme to revert to an initRTO of 3sec. But, we might get it in the order given above. And, we might not get that packet at all. So, it might work and it might not work. But, the cost of not using it (possibly saving X*0.02*0.02*2sec) is so small that it seems like needless complication to me. Now, there is something you can do here... If you wanted to take the reception of the SYN+ACK and compare that to the *earliest* SYN transmission and use that as an RTT sample and then use that to seed the RTO estimator then fine. I.e., in this case that'd (correctly) see an RTT of 2sec. And, if the original SYN was lost then the returning SYN+ACK would yield an RTT sample of 3sec. I.e., using this scheme might overestimate the RTT, but you won't underestimate it. If that is less than 3sec you'd be better off for the first window of data and you'd be protected against spurious retransmits (to the best of the standard RTO estimator's abilities) by using a conservative RTT sample. allman ----------ma62193-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkpx8vMACgkQWyrrWs4yIs6dqACdEMD3n2LFNoc7b+j8wEeTvcTD i2wAnjBVTnF3q+NzPf6FqvyGyh2/Sakq =U1I0 -----END PGP SIGNATURE----- ----------ma62193-1--