From wesley.m.eddy@nasa.gov Tue Dec 1 13:43: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 E3BA53A681F for ; Tue, 1 Dec 2009 13:43:47 -0800 (PST) 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 tuSR5oVbTTeE for ; Tue, 1 Dec 2009 13:43:47 -0800 (PST) Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [198.117.0.123]) by core3.amsl.com (Postfix) with ESMTP id D8F723A679C for ; Tue, 1 Dec 2009 13:43:46 -0800 (PST) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 23AB02DA435; Tue, 1 Dec 2009 15:43:38 -0600 (CST) Received: from ndjshub04.ndc.nasa.gov (ndjshub04.ndc.nasa.gov [198.117.4.163]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id nB1LhbuP004960; Tue, 1 Dec 2009 15:43:38 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub04.ndc.nasa.gov ([198.117.4.163]) with mapi; Tue, 1 Dec 2009 15:42:12 -0600 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: "tcpm@ietf.org" Date: Tue, 1 Dec 2009 15:42:11 -0600 Thread-Topic: closing WGLC for TCP-AO Thread-Index: Acpyzx3mMN5CpAIqSqSwb6k6u7bDpw== 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.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-12-01_08:2009-11-30, 2009-12-01, 2009-12-01 signatures=0 Cc: Joe Touch Subject: [tcpm] closing WGLC 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: Tue, 01 Dec 2009 21:43:48 -0000 The period for the working group last call on the AO documents has passed. I didn't see any major issues that were identified. Even though the response was light, given the large amount of discussion that's gone into it to reach this point, I think this is okay to proceed; we'll write the PROTO statements if the authors can rev the drafts based on any feedback they got. One additional question that was open was whether the NAT draft of Joe's should be rolled in. Since several people supported this, and none were against it, I think Joe should go ahead and include it before it gets sent to the IESG. My late, and minor, comments on the AO and crypto drafts are below, as a WG participant. On the main AO draft =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1) editorial - in Abstract: "TCP-AO uses its own option identifier, even though used mutually exclusive of TCP MD5 on a given TCP connection." could this just be: "TCP-AO uses a separate option identifier from TCP MD5 and the two options are not capable of being used at the same time." 2) editorial, in Figure 1 (section 4.1): It's probably clear to everyone that the MD5 digest field wraps through the remainder of the option length, but could a "..." or "... (cont.)" be added to the empty areas to make that explicit? The way it's shown in Figure 2 is nice, I think. 3) editorial, in section 5.2: "derived from the MKT and the properties of a connection. For established connections, these properties include the socket pair (local IP address, local TCP port, remote IP address, remote port)," could be: "derived from the MKT and the local and remote pairs of IP addresses and TCP port numbers," 4) technical/editorial in section 5.2: I think this is just a typo, but to make sure ...: "A single MKT can be used to derive any of four different MKTs:" should be: "A single MKT can be used to derive any of four different traffic keys:" 5) editorial, in section 7.2: The heading is "Key Derivation Functions", I think it would be better as "Traffic Key Derivation Functions", as it doesn't discuss the derivation of master keys. On the AO crypto draft =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1) editorial, in abstract: "algorithm(s)" -> "algorithms" ? 2) editorial, in Section 1: "to TCP-AO [TCP-AO] [I-D.ietf-tcpm-tcp-auth-opt]." -> "to TCP-AO [I-D.ietf-tcpm-tcp-auth-opt]." 3) editorial, in Section 1: "two key derivations functions" -> "two key derivation functions" 4) editorial, in section 2.2: "Security Area Directors" -> "IETF Security Area Directors" 5) editorial/technical, in section 2.2: "especially given that the tags are truncated to 96 bits" -> "even though the tags are truncated to 96 bits" ??? 6) editorial/technical, in section 2.2: "aren't practical on SHA-1" -> "aren't practical on HMAC-SHA-1" ??? 7) editorial, section 7.1: use of Output_Length included here is not consistent with the way that the main auth-opt draft defines this. 8) editorial, section 3.1.1: "Each" -> "" 9) editorial, figure 1: formatting of top line is off -- Wes Eddy MTI Systems From touch@ISI.EDU Tue Dec 1 13:49: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 B31913A679C for ; Tue, 1 Dec 2009 13:49:31 -0800 (PST) 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 sLKi4kIXHZIQ for ; Tue, 1 Dec 2009 13:49:31 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 08C0D3A6783 for ; Tue, 1 Dec 2009 13:49:31 -0800 (PST) Received: from [70.213.188.6] (6.sub-70-213-188.myvzw.com [70.213.188.6]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nB1LnA2A015079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 Dec 2009 13:49:13 -0800 (PST) Message-ID: <4B158F56.3020805@isi.edu> Date: Tue, 01 Dec 2009 13:49:10 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" References: 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" Subject: Re: [tcpm] closing WGLC 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: Tue, 01 Dec 2009 21:49:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Wes, To confirm below... Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote: ... > On the main AO draft > ==================== ... > 4) technical/editorial in section 5.2: > I think this is just a typo, but to make sure ...: > "A single MKT can be used to derive any of four different MKTs:" > should be: > "A single MKT can be used to derive any of four different traffic keys:" Yes. That's what's intended; the original text is a typo. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksVj1YACgkQE5f5cImnZrstoQCeI59V8a6qO8l16Qw1u0cj+gkt O3kAoLVZnhTLX8vFNkw8sEjQxzw00/Uw =Kkcg -----END PGP SIGNATURE----- From ananth@cisco.com Tue Dec 1 23:19:23 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 1F14F28C15A for ; Tue, 1 Dec 2009 23:19:23 -0800 (PST) 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 R8pg8IrD1Ddo for ; Tue, 1 Dec 2009 23:19:22 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id D900728C157 for ; Tue, 1 Dec 2009 23:19:21 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACukFUurRN+K/2dsb2JhbAC/DpgghDEE X-IronPort-AV: E=Sophos;i="4.47,327,1257120000"; d="scan'208";a="56404747" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 02 Dec 2009 07:19:14 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nB27JEjE012793; Wed, 2 Dec 2009 07:19:14 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 23:19:14 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Dec 2009 23:19:11 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC58087D6B17@xmb-sjc-21c.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] closing WGLC for TCP-AO Thread-Index: Acpyzx3mMN5CpAIqSqSwb6k6u7bDpwASa9cw References: From: "Anantha Ramaiah (ananth)" To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" , X-OriginalArrivalTime: 02 Dec 2009 07:19:14.0190 (UTC) FILETIME=[C05BC2E0:01CA731F] Cc: Joe Touch Subject: Re: [tcpm] closing WGLC 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: Wed, 02 Dec 2009 07:19:23 -0000 Maybe I missing something here, I haven't seen any responses for this WGLC, typically if that is the case, I have seen the urge to ask folks to read and even they don't have any comments "I have read it, it is fine". No such thing seem to have happened for this case. May be I missed some responses. IMO, this TCP-AO option needs to have an "Applicability statement". The typical advise whenever one tries to make TCP robust or provide TCP security has always been "use IPSec" and such an argument has derailed any changes that improve TCP's robustness and resulted in endless debates in the past in TCPM. The rationale of having TCP-AO stems from the fact that "some applications can't use IPsec due to n number of reasons", TCP-MD5 came into play which is now being replaced by the TCP AO option. But not all applications/devices would want to use this option neither should it be encouraged to use this option, if one were to go by the "IPsec mantra". So, I would like to have an AS put in the doc which states the circumstances (long lived connections), applications (like BGP) and devices (routers) where the usage of this TCP option is recommended. TCP secure document has an AS which can be used as a template, if needed. Also I would want a paragraph which explains why IPsec cannot be used (even though the document contains pointers to earlier motivation document, I would rather prefer this to be made self-contained in this document.)=20 The introduction does have something to this effect, but sounds too general and not specific. As far as the NAT document goes, there seems to be rush here in folding this along with the TCP-AO. The NAT document doesn't even show up in this TCPM charter page, FWIW. Regarding the NAT document, I have some general questions : - how many clients are there that are behind NAT and still would want to use this option?. The currently used TCP-MD5 option didn't face such an issue, in other words NAT compatibility was the least bothering issue, IMO. - Also the document says it reduces the entropy and advises the both localNAT/remoteNAT should not be turned on. Hoe can you detect mis-configurations? What happens when someone configures this on the middle of the connection? I have a feeling that the NAT solution proposed has not been discussed thoroughly (there have been lot of discussions before that, but after the NAT document was written, there was some support to fold this content with the TCP-AO, agreed) but it seems like we are rushing this part, IMO. -Anantha > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] > Sent: Tuesday, December 01, 2009 1:42 PM > To: tcpm@ietf.org > Cc: Joe Touch > Subject: [tcpm] closing WGLC for TCP-AO >=20 > The period for the working group last call on the AO=20 > documents has passed. I didn't see any major issues that=20 > were identified. > Even though the response was light, given the large amount of=20 > discussion that's gone into it to reach this point, I think=20 > this is okay to proceed; we'll write the PROTO statements if=20 > the authors can rev the drafts based on any feedback they got. >=20 > One additional question that was open was whether the NAT=20 > draft of Joe's should be rolled in. Since several people=20 > supported this, and none were against it, I think Joe should=20 > go ahead and include it before it gets sent to the IESG. >=20 > My late, and minor, comments on the AO and crypto drafts are=20 > below, as a WG participant. >=20 >=20 > On the main AO draft > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > 1) editorial - in Abstract: > "TCP-AO uses its own option identifier, even though used=20 > mutually exclusive of TCP MD5 on a given TCP connection." > could this just be: > "TCP-AO uses a separate option identifier from TCP MD5 and=20 > the two options are not capable of being used at the same time." >=20 > 2) editorial, in Figure 1 (section 4.1): > It's probably clear to everyone that the MD5 digest field=20 > wraps through the remainder of the option length, but could a=20 > "..." or "... (cont.)" > be added to the empty areas to make that explicit? The way=20 > it's shown in Figure 2 is nice, I think. >=20 > 3) editorial, in section 5.2: > "derived from the MKT and the properties of a connection. =20 > For established connections, these properties include the=20 > socket pair (local IP address, local TCP port, remote IP=20 > address, remote port)," > could be: > "derived from the MKT and the local and remote pairs of IP=20 > addresses and TCP port numbers," >=20 > 4) technical/editorial in section 5.2: > I think this is just a typo, but to make sure ...: > "A single MKT can be used to derive any of four different MKTs:" > should be: > "A single MKT can be used to derive any of four different=20 > traffic keys:" >=20 > 5) editorial, in section 7.2: > The heading is "Key Derivation Functions", I think it would=20 > be better as "Traffic Key Derivation Functions", as it=20 > doesn't discuss the derivation of master keys. >=20 >=20 >=20 > On the AO crypto draft > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > 1) editorial, in abstract: > "algorithm(s)" -> "algorithms" ? >=20 > 2) editorial, in Section 1: > "to TCP-AO [TCP-AO] [I-D.ietf-tcpm-tcp-auth-opt]." > -> > "to TCP-AO [I-D.ietf-tcpm-tcp-auth-opt]." >=20 > 3) editorial, in Section 1: > "two key derivations functions" > -> > "two key derivation functions" >=20 > 4) editorial, in section 2.2: > "Security Area Directors" > -> > "IETF Security Area Directors" >=20 > 5) editorial/technical, in section 2.2: > "especially given that the tags are truncated to 96 bits" > -> > "even though the tags are truncated to 96 bits" > ??? >=20 > 6) editorial/technical, in section 2.2: > "aren't practical on SHA-1" > -> > "aren't practical on HMAC-SHA-1" > ??? >=20 > 7) editorial, section 7.1: > use of Output_Length included here is not consistent with the=20 > way that the main auth-opt draft defines this. >=20 > 8) editorial, section 3.1.1: > "Each" > -> > "" >=20 > 9) editorial, figure 1: > formatting of top line is off >=20 >=20 > -- > Wes Eddy > MTI Systems >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 From touch@ISI.EDU Wed Dec 2 00:11:33 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 979A43A6A0E for ; Wed, 2 Dec 2009 00:11:28 -0800 (PST) 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 xch1hw3DwNEO for ; Wed, 2 Dec 2009 00:11:24 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id A5AC13A68F9 for ; Wed, 2 Dec 2009 00:11:24 -0800 (PST) Received: from [192.168.1.43] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id nB28AGSt000909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Dec 2009 00:10:20 -0800 (PST) Message-ID: <4B1620E8.4040503@isi.edu> Date: Wed, 02 Dec 2009 00:10:16 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <0C53DCFB700D144284A584F54711EC58087D6B17@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC58087D6B17@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MailScanner-ID: nB28AGSt000909 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] closing WGLC 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: Wed, 02 Dec 2009 08:11:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Anantha, Anantha Ramaiah (ananth) wrote: > Maybe I missing something here, I haven't seen any responses for this > WGLC, typically if that is the case, I have seen the urge to ask folks > to read and even they don't have any comments "I have read it, it is > fine". No such thing seem to have happened for this case. May be I > missed some responses. There was one response from Donald Smith on 11/3. I didn't see any confirming responses, but we haven't required that during last calls AFAIR. > IMO, this TCP-AO option needs to have an "Applicability statement". The > typical advise whenever one tries to make TCP robust or provide TCP > security has always been "use IPSec" and such an argument has derailed > any changes that improve TCP's robustness and resulted in endless > debates in the past in TCPM. The rationale of having TCP-AO stems from > the fact that "some applications can't use IPsec due to n number of > reasons", TCP-MD5 came into play which is now being replaced by the TCP > AO option. But not all applications/devices would want to use this > option neither should it be encouraged to use this option, if one were > to go by the "IPsec mantra". So, I would like to have an AS put in the > doc which states the circumstances (long lived connections), > applications (like BGP) and devices (routers) where the usage of this > TCP option is recommended. Although there is no section entitled "Applicability Statement", the text you're seeking is already contained in the third paragraph of the Introduction (sec 2). > TCP secure document has an AS which can be > used as a template, if needed. Also I would want a paragraph which > explains why IPsec cannot > be used (even though the document contains pointers to earlier > motivation document, I would rather prefer this to be made > self-contained in this document.) > > The introduction does have something to this effect, but sounds too > general and not specific. It's quite specific. Use TCP-AO where authentication is needed and IPsec is not desired or where keys need to be bound to connections. That's about as specific as it gets. > As far as the NAT document goes, there seems to be rush here in folding > this along with the TCP-AO. The NAT document doesn't even show up in > this TCPM charter page, FWIW. There has always been interest in considering NAT support for TCP-AO, and it has been discussed many times. Until we developed the master/traffic key mechanism based on the ISNs, however, it wasn't feasible. The NAT mechanism was posted to this list 7/30. You commented on it 8/7. I don't understand your claim that this has been a rush. Keep in mind that the time needed to evaluate it ought to be commensurate with its complexity. It just zeroes out the ports, and explains why that's feasible given how traffic keys are now derived. > Regarding the NAT document, I have some general questions : > > - how many clients are there that are behind NAT and still would want to > use this option?. The currently used TCP-MD5 option didn't face such an > issue, in other words NAT compatibility was the least bothering issue, > IMO. TCP-AO is intended to be a general mechanism. In that regard, if we can support NAT traversal without substantial complexity, then we should. Zeroing the ports prior to HMAC calculation seems a fairly low level of complexity. > - Also the document says it reduces the entropy and advises the both > localNAT/remoteNAT should not be turned on. Hoe can you detect > mis-configurations? What happens when someone configures this on the > middle of the connection? TCP-AO is not a security configuration negotiation protocol. Misconfigurations result in dropped segments, as they would in any protocol. If someone turns this on in the middle of a connection the port fields aren't protected by the authentication algorithm, but it won't help much to change them on the fly. They'll just be dropped because their traffic keys won't match those of other connections (with very high probability). > I have a feeling that the NAT solution proposed has not been discussed > thoroughly (there have been lot of discussions before that, but after > the NAT document was written, there was some support to fold this > content with the TCP-AO, agreed) but it seems like we are rushing this > part, IMO. It has been out on the list for 3 months, with discussion, and was included in the request for the last call. Joe >> -----Original Message----- >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On >> Behalf Of Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] >> Sent: Tuesday, December 01, 2009 1:42 PM >> To: tcpm@ietf.org >> Cc: Joe Touch >> Subject: [tcpm] closing WGLC for TCP-AO >> >> The period for the working group last call on the AO >> documents has passed. I didn't see any major issues that >> were identified. >> Even though the response was light, given the large amount of >> discussion that's gone into it to reach this point, I think >> this is okay to proceed; we'll write the PROTO statements if >> the authors can rev the drafts based on any feedback they got. >> >> One additional question that was open was whether the NAT >> draft of Joe's should be rolled in. Since several people >> supported this, and none were against it, I think Joe should >> go ahead and include it before it gets sent to the IESG. >> >> My late, and minor, comments on the AO and crypto drafts are >> below, as a WG participant. >> >> >> On the main AO draft >> ==================== >> >> 1) editorial - in Abstract: >> "TCP-AO uses its own option identifier, even though used >> mutually exclusive of TCP MD5 on a given TCP connection." >> could this just be: >> "TCP-AO uses a separate option identifier from TCP MD5 and >> the two options are not capable of being used at the same time." >> >> 2) editorial, in Figure 1 (section 4.1): >> It's probably clear to everyone that the MD5 digest field >> wraps through the remainder of the option length, but could a >> "..." or "... (cont.)" >> be added to the empty areas to make that explicit? The way >> it's shown in Figure 2 is nice, I think. >> >> 3) editorial, in section 5.2: >> "derived from the MKT and the properties of a connection. >> For established connections, these properties include the >> socket pair (local IP address, local TCP port, remote IP >> address, remote port)," >> could be: >> "derived from the MKT and the local and remote pairs of IP >> addresses and TCP port numbers," >> >> 4) technical/editorial in section 5.2: >> I think this is just a typo, but to make sure ...: >> "A single MKT can be used to derive any of four different MKTs:" >> should be: >> "A single MKT can be used to derive any of four different >> traffic keys:" >> >> 5) editorial, in section 7.2: >> The heading is "Key Derivation Functions", I think it would >> be better as "Traffic Key Derivation Functions", as it >> doesn't discuss the derivation of master keys. >> >> >> >> On the AO crypto draft >> ====================== >> >> 1) editorial, in abstract: >> "algorithm(s)" -> "algorithms" ? >> >> 2) editorial, in Section 1: >> "to TCP-AO [TCP-AO] [I-D.ietf-tcpm-tcp-auth-opt]." >> -> >> "to TCP-AO [I-D.ietf-tcpm-tcp-auth-opt]." >> >> 3) editorial, in Section 1: >> "two key derivations functions" >> -> >> "two key derivation functions" >> >> 4) editorial, in section 2.2: >> "Security Area Directors" >> -> >> "IETF Security Area Directors" >> >> 5) editorial/technical, in section 2.2: >> "especially given that the tags are truncated to 96 bits" >> -> >> "even though the tags are truncated to 96 bits" >> ??? >> >> 6) editorial/technical, in section 2.2: >> "aren't practical on SHA-1" >> -> >> "aren't practical on HMAC-SHA-1" >> ??? >> >> 7) editorial, section 7.1: >> use of Output_Length included here is not consistent with the >> way that the main auth-opt draft defines this. >> >> 8) editorial, section 3.1.1: >> "Each" >> -> >> "" >> >> 9) editorial, figure 1: >> formatting of top line is off >> >> >> -- >> Wes Eddy >> MTI Systems >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksWIOgACgkQE5f5cImnZrtzjgCeKOafyj8D3w6gV+mbqeXidI9P gqgAn3tUFiZjoQnFHuUmNFWQKZBcJRR7 =0xzb -----END PGP SIGNATURE----- From ananth@cisco.com Wed Dec 2 01:14: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 A37413A6A92 for ; Wed, 2 Dec 2009 01:14:15 -0800 (PST) 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 nDV6S0UfROjh for ; Wed, 2 Dec 2009 01:14:14 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 454743A6A7F for ; Wed, 2 Dec 2009 01:14:11 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAC6+FUurR7Ht/2dsb2JhbAC+YIkZCI58gkMIgWYEjRk X-IronPort-AV: E=Sophos;i="4.47,327,1257120000"; d="scan'208";a="71507210" Received: from sj-core-1.cisco.com ([171.71.177.237]) by rtp-iport-2.cisco.com with ESMTP; 02 Dec 2009 09:14:00 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nB29E0No009290; Wed, 2 Dec 2009 09:14:00 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Dec 2009 01:14:00 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Dec 2009 01:13:57 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC58087D6B2F@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <4B1620E8.4040503@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] closing WGLC for TCP-AO Thread-Index: AcpzJwZRq7HmBuf/SuijYCb4vPL+lQAASpMA References: <0C53DCFB700D144284A584F54711EC58087D6B17@xmb-sjc-21c.amer.cisco.com> <4B1620E8.4040503@isi.edu> From: "Anantha Ramaiah (ananth)" To: "Joe Touch" X-OriginalArrivalTime: 02 Dec 2009 09:14:00.0551 (UTC) FILETIME=[C8F30F70:01CA732F] Cc: tcpm@ietf.org Subject: Re: [tcpm] closing WGLC 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: Wed, 02 Dec 2009 09:14:15 -0000 =20 > Anantha Ramaiah (ananth) wrote: > > Maybe I missing something here, I haven't seen any=20 > responses for this=20 > > WGLC, typically if that is the case, I have seen the urge=20 > to ask folks=20 > > to read and even they don't have any comments "I have read=20 > it, it is=20 > > fine". No such thing seem to have happened for this case. May be I=20 > > missed some responses. >=20 > There was one response from Donald Smith on 11/3. I didn't=20 Yes, I remember that. The email from Donald expressed concerns w.r.t connectionless Resets and clarifications were sought. (actually I have a quite of bit of thoughts in this area all coming from addressing/solving customer issues w.r.t RST's and MD5, but never found time to gather and share those experiences) > see any confirming responses, but we haven't required that=20 > during last calls AFAIR. My mileage is different than yours. If there are no sufficent responses within the WGLC time period, then mostly the WGLC extension was given, AFAIR. >=20 > > IMO, this TCP-AO option needs to have an "Applicability statement".=20 > > The typical advise whenever one tries to make TCP robust or provide=20 > > TCP security has always been "use IPSec" and such an argument has=20 > > derailed any changes that improve TCP's robustness and resulted in=20 > > endless debates in the past in TCPM. The rationale of=20 > having TCP-AO=20 > > stems from the fact that "some applications can't use IPsec=20 > due to n=20 > > number of reasons", TCP-MD5 came into play which is now=20 > being replaced=20 > > by the TCP AO option. But not all applications/devices=20 > would want to=20 > > use this option neither should it be encouraged to use this=20 > option, if=20 > > one were to go by the "IPsec mantra". So, I would like to=20 > have an AS=20 > > put in the doc which states the circumstances (long lived=20 > > connections), applications (like BGP) and devices (routers)=20 > where the=20 > > usage of this TCP option is recommended. >=20 > Although there is no section entitled "Applicability=20 > Statement", the text you're seeking is already contained in=20 > the third paragraph of the Introduction (sec 2). Yes, I read that and pointed out the same below, then what is the harm in calling this as an "Applicabiliy statement". Since this TCP-AO usage needs to be restricted to a handful of situations and one need to always use IPsec if available. Having an AS, it makes things more clearer for the reader, this is the general consensus a while back. > > The introduction does have something to this effect, but sounds too=20 > > general and not specific. >=20 > It's quite specific. Use TCP-AO where authentication is=20 > needed and IPsec is not desired or where keys need to be=20 > bound to connections. That's about as specific as it gets. It doesn't say why Ipsec can't be used, what reasons (explicit)? (motivation document may have it, but that needs to be spelled out here for the benefit of completeness, IMO). Then what is wrong in putting it under an AS and sending out for review? What makes you think that an AS is not necesssary, this will surely benefit a lot of implementers. > > As far as the NAT document goes, there seems to be rush here in=20 > > folding this along with the TCP-AO. The NAT document=20 > doesn't even show=20 > > up in this TCPM charter page, FWIW. >=20 > There has always been interest in considering NAT support for=20 > TCP-AO, and it has been discussed many times. Until we=20 > developed the master/traffic key mechanism based on the ISNs,=20 > however, it wasn't feasible. The MKT generation can be done multiple ways and usage of ISN's is one such scheme? Are we mandating this in TCP-AO, atleast I didn't get that feeling (that is how it should be and left to the implementer)=20 >=20 > The NAT mechanism was posted to this list 7/30. You commented=20 > on it 8/7. Sorry can't recall, which email you are referring to? Are you talking about the current document or the old NAT discussions which happened, but that time this proposed solution was non-existent. > I don't understand your claim that this has been a rush. Keep=20 > in mind that the time needed to evaluate it ought to be=20 > commensurate with its complexity. It just zeroes out the=20 > ports, and explains why that's feasible given how traffic=20 > keys are now derived. Well, that is easy to say. Let me step back a bit: Are TCP documents which are general in nature should take into account NAT/middlebox issues/, till recently the answer was (even from your earlier emails) shouldn't probably care.. The method followed in the past is to say "this wont work, just document it" Now we seem to have relaxed this a bit further by proposing solutions, a 3 month review for the same isn't simply enough and if it is considered otherwise, I simply chose to call it as a "Rush". >=20 > > Regarding the NAT document, I have some general questions : > >=20 > > - how many clients are there that are behind NAT and still=20 > would want=20 > > to use this option?. The currently used TCP-MD5 option didn't face=20 > > such an issue, in other words NAT compatibility was the least=20 > > bothering issue, IMO. >=20 > TCP-AO is intended to be a general mechanism. In that regard,=20 What do you mean by a "general mechanism" what makes TCP-MD5 specific? TCP AO is an enhancement on the exisiting TCP-MD5 option, that's it. It may have all the "nice" things, but that doesn't re-define its applicability AFAICT. When the motivation document was written a few years ago it was keeping in mind the needs of specfic applications that cannot use the recommended, existing security mechanism (called as IPsec) > if we can support NAT traversal without substantial=20 > complexity, then we should. This way you can keep adding support for almost anything, but that was not the goals of this document, esp when this is required by only a handful of protocols. (of course important ones) > It has been out on the list for 3 months, with discussion,=20 > and was included in the request for the last call. 3 months is very short time considering the life-span of typical IETF (TCPM in particular) documents . YMMV ;-) I would still call this as a "rush". -Anantha From fernando.gont.netbook.win@gmail.com Wed Dec 2 06:02: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 0247A3A6808 for ; Wed, 2 Dec 2009 06:02:11 -0800 (PST) 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 58TQ-O5SOkeb for ; Wed, 2 Dec 2009 06:02:10 -0800 (PST) Received: from mail-yw0-f117.google.com (mail-yw0-f117.google.com [209.85.211.117]) by core3.amsl.com (Postfix) with ESMTP id 0DBF33A6AC8 for ; Wed, 2 Dec 2009 06:02:09 -0800 (PST) Received: by ywh15 with SMTP id 15so46968ywh.5 for ; Wed, 02 Dec 2009 06:01:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=oTh9BHTAUPGH0aVG+D4DeOKGLhZeB8ABJHBJjUKAL/4=; b=C9pmuk610cH/V5GXAeJT/+hb2Mqd3BJ9ILAotHBVP4rgrMIhiy9tdcgUbW0QLSxY9E jcloRV8wMRpQYoGjeNXljRb9FMj1k4TDjnqFJdtQ1eLJh6bX96BhVvWqTcT5CWbK3Vj8 7nMbT/04NBL7zShCTnjYuMld0CIvgP1/6yams= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=ZrAd9WT3TWDUVgp9BnX4pILHA/HNIt9NKvjDNhszHbxMZDHNPr3KSgKWkNTlIHM5D6 yWuHUyVSXF/jKanWfd+iMC+BYAlJYVjPjhYQ2NZKJMnipoMBRei7eYUt52UQKddiwD6M hR+LZFiRDwpMhWN4VbSg+P/FsMZFFxUqLGHzE= Received: by 10.150.173.3 with SMTP id v3mr426729ybe.52.1259762519611; Wed, 02 Dec 2009 06:01:59 -0800 (PST) Received: from ?192.168.0.168? (129-130-17-190.fibertel.com.ar [190.17.130.129]) by mx.google.com with ESMTPS id 6sm428334ywc.9.2009.12.02.06.01.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 02 Dec 2009 06:01:58 -0800 (PST) Sender: Fernando Gont Message-ID: <4B16734C.3050107@gont.com.ar> Date: Wed, 02 Dec 2009 11:01:48 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <0C53DCFB700D144284A584F54711EC58087D6B17@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC58087D6B17@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Joe Touch , tcpm@ietf.org Subject: Re: [tcpm] closing WGLC 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: Wed, 02 Dec 2009 14:02:11 -0000 Anantha Ramaiah (ananth) wrote: > Maybe I missing something here, I haven't seen any responses for this > WGLC, typically if that is the case, I have seen the urge to ask folks > to read and even they don't have any comments "I have read it, it is > fine". No such thing seem to have happened for this case. May be I > missed some responses. +1 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 wesley.m.eddy@nasa.gov Wed Dec 2 06:39:20 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 4674C3A67FC for ; Wed, 2 Dec 2009 06:39:20 -0800 (PST) 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=[AWL=0.000, 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 cm4sN7Lf6DRC for ; Wed, 2 Dec 2009 06:39:19 -0800 (PST) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id 4FD673A68C3 for ; Wed, 2 Dec 2009 06:39:19 -0800 (PST) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 5B7DC328316; Wed, 2 Dec 2009 08:39:10 -0600 (CST) Received: from ndjshub01.ndc.nasa.gov (ndjshub01-pub.ndc.nasa.gov [198.117.1.160]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id nB2EdBBv027500; Wed, 2 Dec 2009 08:39:11 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub01.ndc.nasa.gov ([198.117.1.160]) with mapi; Wed, 2 Dec 2009 08:39:10 -0600 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: Fernando Gont , "Anantha Ramaiah (ananth)" Date: Wed, 2 Dec 2009 08:39:10 -0600 Thread-Topic: [tcpm] closing WGLC for TCP-AO Thread-Index: AcpzWASrXionI9YOQd2/h7ygijOqrwAA+cYR Message-ID: References: <0C53DCFB700D144284A584F54711EC58087D6B17@xmb-sjc-21c.amer.cisco.com>, <4B16734C.3050107@gont.com.ar> In-Reply-To: <4B16734C.3050107@gont.com.ar> 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.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-12-02_15:2009-11-30, 2009-12-02, 2009-12-02 signatures=0 Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] closing WGLC 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: Wed, 02 Dec 2009 14:39:20 -0000 There's a big difference between documents that authors think are ready for= WGLC but have only seen light discussion in the WG, and documents that hav= e been extensively discussed in hundreds of mail-list posts and hours of WG= face-to-face meeting time and other high-bandwidth offline discussion. Early retransmit was a good example of the first case; the document was bas= ically done, but we couldn't tell if the WG had read it sufficiently, so th= e WGLC got extended until we had that confidence. AO is an example of the second case; it's benefited from very long sesssion= s in some of our meetings (Dublin, Minneapolis, San Francisco, etc), and th= e mailing list traffic attests that a lot of people have read it, raised th= eir issues, and had them addressed in document updates. In this case, the = consensus seemed to be formed well before the WGLC, making it more of a "sp= eak now or forever hold your peace" moment, rather than an attempt to make = sure sufficient review had been obtained. I hope this clears things up for those of you who think this is odd. It's = not :). ________________________________________ From: Fernando Gont [fernando.gont.netbook.win@gmail.com] On Behalf Of Fern= ando Gont [fernando@gont.com.ar] Sent: Wednesday, December 02, 2009 9:01 AM To: Anantha Ramaiah (ananth) Cc: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; tcpm@ietf.org; Joe Tou= ch Subject: Re: [tcpm] closing WGLC for TCP-AO Anantha Ramaiah (ananth) wrote: > Maybe I missing something here, I haven't seen any responses for this > WGLC, typically if that is the case, I have seen the urge to ask folks > to read and even they don't have any comments "I have read it, it is > fine". No such thing seem to have happened for this case. May be I > missed some responses. +1 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 touch@ISI.EDU Wed Dec 2 07:09:21 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 64ADF3A6811 for ; Wed, 2 Dec 2009 07:09:21 -0800 (PST) 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 uJHlpbGDsqIE for ; Wed, 2 Dec 2009 07:09:20 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 056853A6873 for ; Wed, 2 Dec 2009 07:09:20 -0800 (PST) Received: from [192.168.1.43] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nB2F8wZR028295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Dec 2009 07:09:03 -0800 (PST) Message-ID: <4B168305.6030508@isi.edu> Date: Wed, 02 Dec 2009 07:08:53 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <0C53DCFB700D144284A584F54711EC58087D6B17@xmb-sjc-21c.amer.cisco.com> <4B1620E8.4040503@isi.edu> <0C53DCFB700D144284A584F54711EC58087D6B2F@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC58087D6B2F@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig89E7ED287E9B5A89A585BD3B" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] closing WGLC 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: Wed, 02 Dec 2009 15:09:21 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig89E7ED287E9B5A89A585BD3B Content-Type: multipart/mixed; boundary="------------040409030100050908050808" This is a multi-part message in MIME format. --------------040409030100050908050808 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anantha Ramaiah (ananth) wrote: =2E.. >> Although there is no section entitled "Applicability=20 >> Statement", the text you're seeking is already contained in=20 >> the third paragraph of the Introduction (sec 2). >=20 > Yes, I read that and pointed out the same below, then what is the harm > in calling this as an "Applicabiliy statement". Since this TCP-AO usage= > needs to be restricted to a handful of situations and one need to alway= s > use IPsec if available. Having an AS, it makes things more clearer for= > the reader, this is the general consensus a while back. TCP-AO provides protections that IPsec does not and cannot - notably, keys that change on a per-connection basis even when the addr/port pair is reused. There is no mechanism in IPsec or via IKE to force a key change when a connection is terminated or when a new connection ensues, even after TIME_WAIT. If you have reasons you want to suggest to restrict the use of TCP-AO, please list them. They have not been raised in the several years this issues has been under discussion. The design team began several years ago with a mandate to develop a general authentication mechanism, not one specific to a "handful of situations". >>> The introduction does have something to this effect, but sounds too=20 >>> general and not specific. >>> >> It's quite specific. Use TCP-AO where authentication is=20 >> needed and IPsec is not desired or where keys need to be=20 >> bound to connections. That's about as specific as it gets. >=20 > It doesn't say why Ipsec can't be used, what reasons (explicit)? It does say the two specific reasons: - when IPsec is not desired - when keys need to be bound to connections The latter is clear. The former can happen for many reasons, and we don't make that case in this doc. The doc intended to provide a solution in that case for those who have already made up their mind. > Then what is wrong in putting it under an AS and sending out for review= ? Nothing. This is something you had several *years* to raise, though. > What makes you think that an AS is not necesssary, this will surely > benefit a lot of implementers. I don't think it's not necessary; I think it's already sufficiently included. I'll leave it to the WG chairs to suggest how to proceed. >>> As far as the NAT document goes, there seems to be rush here in=20 >>> folding this along with the TCP-AO. The NAT document=20 >> doesn't even show=20 >>> up in this TCPM charter page, FWIW. >> >> There has always been interest in considering NAT support for=20 >> TCP-AO, and it has been discussed many times. Until we=20 >> developed the master/traffic key mechanism based on the ISNs,=20 >> however, it wasn't feasible. >=20 > The MKT generation can be done multiple ways and usage of ISN's is one > such scheme? Are we mandating this in TCP-AO, atleast I didn't get that= > feeling (that is how it should be and left to the implementer)=20 Please read the doc. Use of ISNs is very specifically specified and required. >> The NAT mechanism was posted to this list 7/30.... >=20 > Sorry can't recall, which email you are referring to? Are you talking > about the current document or the old NAT discussions which happened, > but that time this proposed solution was non-existent. The proposed solution was described in my post of 7/13 (sorry - typo). It is appended below. It was discussed on the list in July, and presented at the Stockholm IETF. The posted I-D is largely just that email wrapped in boilerplate with longer sentences. >> I don't understand your claim that this has been a rush. Keep=20 >> in mind that the time needed to evaluate it ought to be=20 >> commensurate with its complexity. It just zeroes out the=20 >> ports, and explains why that's feasible given how traffic=20 >> keys are now derived. >=20 > Well, that is easy to say. Let me step back a bit: Are TCP documents > which are general in nature should take into account NAT/middlebox > issues/, till recently the answer was (even from your earlier emails) > shouldn't probably care.. The method followed in the past is to say > "this wont work, just document it" Now we seem to have relaxed this a > bit further by proposing solutions, a 3 month review for the same isn't= > simply enough and if it is considered otherwise, I simply chose to call= > it as a "Rush". As I said, until we developed the MKT/traffic key approach, it was not possible to support NATs except via existing NAT traversal mechanisms (e.g., that encapsulate), and that's what we had included. This feature of the MKT/traffic key approach was recognized on the multipath mailing list (see traffic on 7/9). =2E.. >> TCP-AO is intended to be a general mechanism. In that regard,=20 >=20 > What do you mean by a "general mechanism" what makes TCP-MD5 specific? Basically, its "applicability statement", at least as much of one as it describes. > TCP AO is an enhancement on the exisiting TCP-MD5 option, that's it. It= > may have all the "nice" things, but that doesn't re-define its > applicability AFAICT. When the motivation document was written a few > years ago it was keeping in mind the needs of specfic applications that= > cannot use the recommended, existing security mechanism (called as > IPsec) These "needs" were the first half of what we already indicate: - when users don't want to use IPsec That hasn't changed. The second "need" is to have keys change on a per-connection basis, which we already describe. >> if we can support NAT traversal without substantial=20 >> complexity, then we should. >=20 > This way you can keep adding support for almost anything, but that was > not the goals of this document, esp when this is required by only a > handful of protocols. (of course important ones) Please do look at the mailing list archives. The issue of NATs was raised many years ago. The issue of generality and even NAT support was raised when the design team was formed. Joe --------------040409030100050908050808 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Attached Message" Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.4 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n6DKwYo0010338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 13 Jul 2009 13:58:35 -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 Subject: possible NAT support for TCP-AO 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, Found to be clean X-MailScanner-From: touch@isi.edu -----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----- --------------040409030100050908050808-- --------------enig89E7ED287E9B5A89A585BD3B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksWgwoACgkQE5f5cImnZrul6gCg9qtKBuq+j00BOLdBEKUWr5QQ EboAniHMxI8mW16hFgMz3/gZZ+8PcKxM =HLf7 -----END PGP SIGNATURE----- --------------enig89E7ED287E9B5A89A585BD3B-- From Donald.Smith@qwest.com Wed Dec 2 07:13:20 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 9B59F3A68D4 for ; Wed, 2 Dec 2009 07:13:20 -0800 (PST) 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 R3fQ41Q5Yso2 for ; Wed, 2 Dec 2009 07:13:19 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id F0B9B3A6930 for ; Wed, 2 Dec 2009 07:13:18 -0800 (PST) Received: from suomp61i.qintra.com (suomp61i.qintra.com [151.117.69.28]) by suomp64i.qwest.com (8.14.0/8.14.0) with ESMTP id nB2FD9AW021993; Wed, 2 Dec 2009 09:13:09 -0600 (CST) Received: from qtdenexhtm22.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.0/8.14.0) with ESMTP id nB2FD4tR003493; Wed, 2 Dec 2009 09:13:04 -0600 (CST) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm22.AD.QINTRA.COM ([151.119.91.231]) with mapi; Wed, 2 Dec 2009 08:13:04 -0700 From: "Smith, Donald" To: "Anantha Ramaiah (ananth)" , Joe Touch Content-Class: urn:content-classes:message Date: Wed, 2 Dec 2009 08:12:56 -0700 Thread-Topic: [tcpm] closing WGLC for TCP-AO Thread-Index: AcpzJwZRq7HmBuf/SuijYCb4vPL+lQAASpMAAA40oWMAADp5rA== Message-ID: <64751D63-8618-489B-BA02-EC2839053122@mimectl> References: <0C53DCFB700D144284A584F54711EC58087D6B17@xmb-sjc-21c.amer.cisco.com> <4B1620E8.4040503@isi.edu>, <0C53DCFB700D144284A584F54711EC58087D6B2F@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC58087D6B2F@xmb-sjc-21c.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-mimectl: Produced By Microsoft Exchange V8.1.348.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] closing WGLC 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: Wed, 02 Dec 2009 15:13:20 -0000 Yes, connectionless resets being equal to spoofed resets is a major drawbac= k and will hinder deployment in production systems. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com gcia ________________________________ From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of Anantha Ra= maiah (ananth) [ananth@cisco.com] Sent: Wednesday, December 02, 2009 2:13 AM To: Joe Touch Cc: tcpm@ietf.org Subject: Re: [tcpm] closing WGLC for TCP-AO > Anantha Ramaiah (ananth) wrote: > > Maybe I missing something here, I haven't seen any > responses for this > > WGLC, typically if that is the case, I have seen the urge > to ask folks > > to read and even they don't have any comments "I have read > it, it is > > fine". No such thing seem to have happened for this case. May be I > > missed some responses. > > There was one response from Donald Smith on 11/3. I didn't Yes, I remember that. The email from Donald expressed concerns w.r.t connectionless Resets and clarifications were sought. (actually I have a quite of bit of thoughts in this area all coming from addressing/solving customer issues w.r.t RST's and MD5, but never found time to gather and share those experiences) > see any confirming responses, but we haven't required that > during last calls AFAIR. My mileage is different than yours. If there are no sufficent responses within the WGLC time period, then mostly the WGLC extension was given, AFAIR. > > > IMO, this TCP-AO option needs to have an "Applicability statement". > > The typical advise whenever one tries to make TCP robust or provide > > TCP security has always been "use IPSec" and such an argument has > > derailed any changes that improve TCP's robustness and resulted in > > endless debates in the past in TCPM. The rationale of > having TCP-AO > > stems from the fact that "some applications can't use IPsec > due to n > > number of reasons", TCP-MD5 came into play which is now > being replaced > > by the TCP AO option. But not all applications/devices > would want to > > use this option neither should it be encouraged to use this > option, if > > one were to go by the "IPsec mantra". So, I would like to > have an AS > > put in the doc which states the circumstances (long lived > > connections), applications (like BGP) and devices (routers) > where the > > usage of this TCP option is recommended. > > Although there is no section entitled "Applicability > Statement", the text you're seeking is already contained in > the third paragraph of the Introduction (sec 2). Yes, I read that and pointed out the same below, then what is the harm in calling this as an "Applicabiliy statement". Since this TCP-AO usage needs to be restricted to a handful of situations and one need to always use IPsec if available. Having an AS, it makes things more clearer for the reader, this is the general consensus a while back. > > The introduction does have something to this effect, but sounds too > > general and not specific. > > It's quite specific. Use TCP-AO where authentication is > needed and IPsec is not desired or where keys need to be > bound to connections. That's about as specific as it gets. It doesn't say why Ipsec can't be used, what reasons (explicit)? (motivation document may have it, but that needs to be spelled out here for the benefit of completeness, IMO). Then what is wrong in putting it under an AS and sending out for review? What makes you think that an AS is not necesssary, this will surely benefit a lot of implementers. > > As far as the NAT document goes, there seems to be rush here in > > folding this along with the TCP-AO. The NAT document > doesn't even show > > up in this TCPM charter page, FWIW. > > There has always been interest in considering NAT support for > TCP-AO, and it has been discussed many times. Until we > developed the master/traffic key mechanism based on the ISNs, > however, it wasn't feasible. The MKT generation can be done multiple ways and usage of ISN's is one such scheme? Are we mandating this in TCP-AO, atleast I didn't get that feeling (that is how it should be and left to the implementer) > > The NAT mechanism was posted to this list 7/30. You commented > on it 8/7. Sorry can't recall, which email you are referring to? Are you talking about the current document or the old NAT discussions which happened, but that time this proposed solution was non-existent. > I don't understand your claim that this has been a rush. Keep > in mind that the time needed to evaluate it ought to be > commensurate with its complexity. It just zeroes out the > ports, and explains why that's feasible given how traffic > keys are now derived. Well, that is easy to say. Let me step back a bit: Are TCP documents which are general in nature should take into account NAT/middlebox issues/, till recently the answer was (even from your earlier emails) shouldn't probably care.. The method followed in the past is to say "this wont work, just document it" Now we seem to have relaxed this a bit further by proposing solutions, a 3 month review for the same isn't simply enough and if it is considered otherwise, I simply chose to call it as a "Rush". > > > Regarding the NAT document, I have some general questions : > > > > - how many clients are there that are behind NAT and still > would want > > to use this option?. The currently used TCP-MD5 option didn't face > > such an issue, in other words NAT compatibility was the least > > bothering issue, IMO. > > TCP-AO is intended to be a general mechanism. In that regard, What do you mean by a "general mechanism" what makes TCP-MD5 specific? TCP AO is an enhancement on the exisiting TCP-MD5 option, that's it. It may have all the "nice" things, but that doesn't re-define its applicability AFAICT. When the motivation document was written a few years ago it was keeping in mind the needs of specfic applications that cannot use the recommended, existing security mechanism (called as IPsec) > if we can support NAT traversal without substantial > complexity, then we should. This way you can keep adding support for almost anything, but that was not the goals of this document, esp when this is required by only a handful of protocols. (of course important ones) > It has been out on the list for 3 months, with discussion, > and was included in the request for the last call. 3 months is very short time considering the life-span of typical IETF (TCPM in particular) documents . YMMV ;-) I would still call this as a "rush". -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm ________________________________ This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From touch@ISI.EDU Wed Dec 2 07:21: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 7331C28C203 for ; Wed, 2 Dec 2009 07:21:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 83WCVY1dxeHN for ; Wed, 2 Dec 2009 07:21:53 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 3378B28C205 for ; Wed, 2 Dec 2009 07:21:53 -0800 (PST) Received: from [192.168.1.43] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nB2FLRqm001835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Dec 2009 07:21:29 -0800 (PST) Message-ID: <4B1685F7.9060603@isi.edu> Date: Wed, 02 Dec 2009 07:21:27 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Smith, Donald" References: <0C53DCFB700D144284A584F54711EC58087D6B17@xmb-sjc-21c.amer.cisco.com> <4B1620E8.4040503@isi.edu>, <0C53DCFB700D144284A584F54711EC58087D6B2F@xmb-sjc-21c.amer.cisco.com> <64751D63-8618-489B-BA02-EC2839053122@mimectl> In-Reply-To: <64751D63-8618-489B-BA02-EC2839053122@mimectl> 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" , "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] closing WGLC 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: Wed, 02 Dec 2009 15:21:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Smith, Donald wrote: > Yes, connectionless resets being equal to spoofed resets is a major > drawback and will hinder deployment in production systems. It is present for IPsec as well. There's no way to recover generated keys that are lost after a reboot. The only solution is to save the relevant state so it is not lost after a reboot. Why do you believe this would be an issue? It's already present whenever connections are not cleanly closed and addresses are reassigned to new hosts. It's simple enough for a server that really cares about the state kept by such orphan connections to clean them up after a timeout. Joe > ________________________________ > From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of Anantha Ramaiah (ananth) [ananth@cisco.com] > Sent: Wednesday, December 02, 2009 2:13 AM > To: Joe Touch > Cc: tcpm@ietf.org > Subject: Re: [tcpm] closing WGLC for TCP-AO > > > > >> Anantha Ramaiah (ananth) wrote: >>> Maybe I missing something here, I haven't seen any >> responses for this >>> WGLC, typically if that is the case, I have seen the urge >> to ask folks >>> to read and even they don't have any comments "I have read >> it, it is >>> fine". No such thing seem to have happened for this case. May be I >>> missed some responses. >> There was one response from Donald Smith on 11/3. I didn't > > Yes, I remember that. The email from Donald expressed concerns w.r.t > connectionless Resets and clarifications were sought. (actually I have a > quite of bit of thoughts in this area all coming from addressing/solving > customer issues w.r.t RST's and MD5, but never found time to gather and > share those experiences) > >> see any confirming responses, but we haven't required that >> during last calls AFAIR. > > My mileage is different than yours. If there are no sufficent responses > within the WGLC time period, then mostly the WGLC extension was given, > AFAIR. > > >>> IMO, this TCP-AO option needs to have an "Applicability statement". >>> The typical advise whenever one tries to make TCP robust or provide >>> TCP security has always been "use IPSec" and such an argument has >>> derailed any changes that improve TCP's robustness and resulted in >>> endless debates in the past in TCPM. The rationale of >> having TCP-AO >>> stems from the fact that "some applications can't use IPsec >> due to n >>> number of reasons", TCP-MD5 came into play which is now >> being replaced >>> by the TCP AO option. But not all applications/devices >> would want to >>> use this option neither should it be encouraged to use this >> option, if >>> one were to go by the "IPsec mantra". So, I would like to >> have an AS >>> put in the doc which states the circumstances (long lived >>> connections), applications (like BGP) and devices (routers) >> where the >>> usage of this TCP option is recommended. >> Although there is no section entitled "Applicability >> Statement", the text you're seeking is already contained in >> the third paragraph of the Introduction (sec 2). > > Yes, I read that and pointed out the same below, then what is the harm > in calling this as an "Applicabiliy statement". Since this TCP-AO usage > needs to be restricted to a handful of situations and one need to always > use IPsec if available. Having an AS, it makes things more clearer for > the reader, this is the general consensus a while back. > > >>> The introduction does have something to this effect, but sounds too >>> general and not specific. >> It's quite specific. Use TCP-AO where authentication is >> needed and IPsec is not desired or where keys need to be >> bound to connections. That's about as specific as it gets. > > It doesn't say why Ipsec can't be used, what reasons (explicit)? > (motivation document may have it, but that needs to be spelled out here > for the benefit of completeness, IMO). > > Then what is wrong in putting it under an AS and sending out for review? > What makes you think that an AS is not necesssary, this will surely > benefit a lot of implementers. > >>> As far as the NAT document goes, there seems to be rush here in >>> folding this along with the TCP-AO. The NAT document >> doesn't even show >>> up in this TCPM charter page, FWIW. >> There has always been interest in considering NAT support for >> TCP-AO, and it has been discussed many times. Until we >> developed the master/traffic key mechanism based on the ISNs, >> however, it wasn't feasible. > > The MKT generation can be done multiple ways and usage of ISN's is one > such scheme? Are we mandating this in TCP-AO, atleast I didn't get that > feeling (that is how it should be and left to the implementer) > >> The NAT mechanism was posted to this list 7/30. You commented >> on it 8/7. > > Sorry can't recall, which email you are referring to? Are you talking > about the current document or the old NAT discussions which happened, > but that time this proposed solution was non-existent. > >> I don't understand your claim that this has been a rush. Keep >> in mind that the time needed to evaluate it ought to be >> commensurate with its complexity. It just zeroes out the >> ports, and explains why that's feasible given how traffic >> keys are now derived. > > Well, that is easy to say. Let me step back a bit: Are TCP documents > which are general in nature should take into account NAT/middlebox > issues/, till recently the answer was (even from your earlier emails) > shouldn't probably care.. The method followed in the past is to say > "this wont work, just document it" Now we seem to have relaxed this a > bit further by proposing solutions, a 3 month review for the same isn't > simply enough and if it is considered otherwise, I simply chose to call > it as a "Rush". > >>> Regarding the NAT document, I have some general questions : >>> >>> - how many clients are there that are behind NAT and still >> would want >>> to use this option?. The currently used TCP-MD5 option didn't face >>> such an issue, in other words NAT compatibility was the least >>> bothering issue, IMO. >> TCP-AO is intended to be a general mechanism. In that regard, > > What do you mean by a "general mechanism" what makes TCP-MD5 specific? > TCP AO is an enhancement on the exisiting TCP-MD5 option, that's it. It > may have all the "nice" things, but that doesn't re-define its > applicability AFAICT. When the motivation document was written a few > years ago it was keeping in mind the needs of specfic applications that > cannot use the recommended, existing security mechanism (called as > IPsec) > > >> if we can support NAT traversal without substantial >> complexity, then we should. > > This way you can keep adding support for almost anything, but that was > not the goals of this document, esp when this is required by only a > handful of protocols. (of course important ones) > >> It has been out on the list for 3 months, with discussion, >> and was included in the request for the last call. > > 3 months is very short time considering the life-span of typical IETF > (TCPM in particular) documents . YMMV ;-) I would still call this as a > "rush". > > -Anantha > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > ________________________________ > This communication is the property of Qwest and may contain confidential or > privileged information. Unauthorized use of this communication is strictly > prohibited and may be unlawful. If you have received this communication > in error, please immediately notify the sender by reply e-mail and destroy > all copies of the communication and any attachments. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksWhfcACgkQE5f5cImnZruCnACeMjLWLHB+SCZvdIkMFys8rxFE uaMAnAvMEpYE6cLVvxIv36pP7R5Mgj0m =f4mD -----END PGP SIGNATURE----- From Donald.Smith@qwest.com Wed Dec 2 07: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 0D9873A6403 for ; Wed, 2 Dec 2009 07:59:31 -0800 (PST) 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 RFpqQyMMeOGi for ; Wed, 2 Dec 2009 07:59:29 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id 90ACB3A6942 for ; Wed, 2 Dec 2009 07:59:29 -0800 (PST) Received: from suomp61i.qintra.com (suomp61i.qintra.com [151.117.69.28]) by suomp64i.qwest.com (8.14.0/8.14.0) with ESMTP id nB2FxK4a024751; Wed, 2 Dec 2009 09:59:20 -0600 (CST) Received: from qtdenexhtm21.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.0/8.14.0) with ESMTP id nB2FxE9l015849; Wed, 2 Dec 2009 09:59:15 -0600 (CST) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm21.AD.QINTRA.COM ([151.119.91.230]) with mapi; Wed, 2 Dec 2009 08:59:14 -0700 From: "Smith, Donald" To: Joe Touch Content-Class: urn:content-classes:message Date: Wed, 2 Dec 2009 08:58:46 -0700 Thread-Topic: [tcpm] closing WGLC for TCP-AO Thread-Index: AcpzYy7lYO0JjM9lQzOMOfsrMxs0SgAA9iS4AABTOSQ= Message-ID: <7028E675-20AC-4874-9C2E-D3216BA8EF36@mimectl> References: <0C53DCFB700D144284A584F54711EC58087D6B17@xmb-sjc-21c.amer.cisco.com> <4B1620E8.4040503@isi.edu>, <0C53DCFB700D144284A584F54711EC58087D6B2F@xmb-sjc-21c.amer.cisco.com> <64751D63-8618-489B-BA02-EC2839053122@mimectl>, <4B1685F7.9060603@isi.edu> In-Reply-To: <4B1685F7.9060603@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-mimectl: Produced By Microsoft Exchange V8.1.348.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" , "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] closing WGLC 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: Wed, 02 Dec 2009 15:59:31 -0000 (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com gcia ________________________________ From: Joe Touch [touch@ISI.EDU] Sent: Wednesday, December 02, 2009 8:21 AM To: Smith, Donald Cc: Anantha Ramaiah (ananth); tcpm@ietf.org Subject: Re: [tcpm] closing WGLC for TCP-AO -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Smith, Donald wrote: >> Yes, connectionless resets being equal to spoofed resets is a major >> drawback and will hinder deployment in production systems. >It is present for IPsec as well. There's no way to recover generated >keys that are lost after a reboot. >The only solution is to save the relevant state so it is not lost after >a reboot. And I think for tcp-ao and bgp that should be the recommended solution (at = least a should if not a must). >Why do you believe this would be an issue? It's already present whenever >connections are not cleanly closed and addresses are reassigned to new >hosts. My main area of concern here is BGP. When a router reboots and can not rese= t its neighbors bgp sessions depending on various timers you can have long = delays before the restarting speaker can get neighbors to accept new connec= tions. In one senerio we had to remove the MD5 auth to allow connectionless= resets to terminate the old sessons before new sessions could be establish= ed. This changed convergence time from minutes to seconds. >It's simple enough for a server that really cares about the state kept >by such orphan connections to clean them up after a timeout. True, I don't have an issue with the orphan connections in most cases but i= n bgp esp single session bgp this can have quite an impact on restablishmen= t and convergence times. >Joe > ________________________________ > From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of Anantha = Ramaiah (ananth) [ananth@cisco.com] > Sent: Wednesday, December 02, 2009 2:13 AM > To: Joe Touch > Cc: tcpm@ietf.org > Subject: Re: [tcpm] closing WGLC for TCP-AO > > > > >> Anantha Ramaiah (ananth) wrote: >>> Maybe I missing something here, I haven't seen any >> responses for this >>> WGLC, typically if that is the case, I have seen the urge >> to ask folks >>> to read and even they don't have any comments "I have read >> it, it is >>> fine". No such thing seem to have happened for this case. May be I >>> missed some responses. >> There was one response from Donald Smith on 11/3. I didn't > > Yes, I remember that. The email from Donald expressed concerns w.r.t > connectionless Resets and clarifications were sought. (actually I have a > quite of bit of thoughts in this area all coming from addressing/solving > customer issues w.r.t RST's and MD5, but never found time to gather and > share those experiences) > >> see any confirming responses, but we haven't required that >> during last calls AFAIR. > > My mileage is different than yours. If there are no sufficent responses > within the WGLC time period, then mostly the WGLC extension was given, > AFAIR. > > >>> IMO, this TCP-AO option needs to have an "Applicability statement". >>> The typical advise whenever one tries to make TCP robust or provide >>> TCP security has always been "use IPSec" and such an argument has >>> derailed any changes that improve TCP's robustness and resulted in >>> endless debates in the past in TCPM. The rationale of >> having TCP-AO >>> stems from the fact that "some applications can't use IPsec >> due to n >>> number of reasons", TCP-MD5 came into play which is now >> being replaced >>> by the TCP AO option. But not all applications/devices >> would want to >>> use this option neither should it be encouraged to use this >> option, if >>> one were to go by the "IPsec mantra". So, I would like to >> have an AS >>> put in the doc which states the circumstances (long lived >>> connections), applications (like BGP) and devices (routers) >> where the >>> usage of this TCP option is recommended. >> Although there is no section entitled "Applicability >> Statement", the text you're seeking is already contained in >> the third paragraph of the Introduction (sec 2). > > Yes, I read that and pointed out the same below, then what is the harm > in calling this as an "Applicabiliy statement". Since this TCP-AO usage > needs to be restricted to a handful of situations and one need to always > use IPsec if available. Having an AS, it makes things more clearer for > the reader, this is the general consensus a while back. > > >>> The introduction does have something to this effect, but sounds too >>> general and not specific. >> It's quite specific. Use TCP-AO where authentication is >> needed and IPsec is not desired or where keys need to be >> bound to connections. That's about as specific as it gets. > > It doesn't say why Ipsec can't be used, what reasons (explicit)? > (motivation document may have it, but that needs to be spelled out here > for the benefit of completeness, IMO). > > Then what is wrong in putting it under an AS and sending out for review? > What makes you think that an AS is not necesssary, this will surely > benefit a lot of implementers. > >>> As far as the NAT document goes, there seems to be rush here in >>> folding this along with the TCP-AO. The NAT document >> doesn't even show >>> up in this TCPM charter page, FWIW. >> There has always been interest in considering NAT support for >> TCP-AO, and it has been discussed many times. Until we >> developed the master/traffic key mechanism based on the ISNs, >> however, it wasn't feasible. > > The MKT generation can be done multiple ways and usage of ISN's is one > such scheme? Are we mandating this in TCP-AO, atleast I didn't get that > feeling (that is how it should be and left to the implementer) > >> The NAT mechanism was posted to this list 7/30. You commented >> on it 8/7. > > Sorry can't recall, which email you are referring to? Are you talking > about the current document or the old NAT discussions which happened, > but that time this proposed solution was non-existent. > >> I don't understand your claim that this has been a rush. Keep >> in mind that the time needed to evaluate it ought to be >> commensurate with its complexity. It just zeroes out the >> ports, and explains why that's feasible given how traffic >> keys are now derived. > > Well, that is easy to say. Let me step back a bit: Are TCP documents > which are general in nature should take into account NAT/middlebox > issues/, till recently the answer was (even from your earlier emails) > shouldn't probably care.. The method followed in the past is to say > "this wont work, just document it" Now we seem to have relaxed this a > bit further by proposing solutions, a 3 month review for the same isn't > simply enough and if it is considered otherwise, I simply chose to call > it as a "Rush". > >>> Regarding the NAT document, I have some general questions : >>> >>> - how many clients are there that are behind NAT and still >> would want >>> to use this option?. The currently used TCP-MD5 option didn't face >>> such an issue, in other words NAT compatibility was the least >>> bothering issue, IMO. >> TCP-AO is intended to be a general mechanism. In that regard, > > What do you mean by a "general mechanism" what makes TCP-MD5 specific? > TCP AO is an enhancement on the exisiting TCP-MD5 option, that's it. It > may have all the "nice" things, but that doesn't re-define its > applicability AFAICT. When the motivation document was written a few > years ago it was keeping in mind the needs of specfic applications that > cannot use the recommended, existing security mechanism (called as > IPsec) > > >> if we can support NAT traversal without substantial >> complexity, then we should. > > This way you can keep adding support for almost anything, but that was > not the goals of this document, esp when this is required by only a > handful of protocols. (of course important ones) > >> It has been out on the list for 3 months, with discussion, >> and was included in the request for the last call. > > 3 months is very short time considering the life-span of typical IETF > (TCPM in particular) documents . YMMV ;-) I would still call this as a > "rush". > > -Anantha > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > ________________________________ > This communication is the property of Qwest and may contain confidential = or > privileged information. Unauthorized use of this communication is strictl= y > prohibited and may be unlawful. If you have received this communication > in error, please immediately notify the sender by reply e-mail and destro= y > all copies of the communication and any attachments. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksWhfcACgkQE5f5cImnZruCnACeMjLWLHB+SCZvdIkMFys8rxFE uaMAnAvMEpYE6cLVvxIv36pP7R5Mgj0m =3Df4mD -----END PGP SIGNATURE----- ________________________________ This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From touch@ISI.EDU Wed Dec 2 08:19: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 3F25828C1FD for ; Wed, 2 Dec 2009 08:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 sqw1h+S8rX+M for ; Wed, 2 Dec 2009 08:19:23 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 55AB128C1EC for ; Wed, 2 Dec 2009 08:19:23 -0800 (PST) Received: from [192.168.1.43] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id nB2GIaXu001585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Dec 2009 08:18:37 -0800 (PST) Message-ID: <4B16935B.2020209@isi.edu> Date: Wed, 02 Dec 2009 08:18:35 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Smith, Donald" References: <0C53DCFB700D144284A584F54711EC58087D6B17@xmb-sjc-21c.amer.cisco.com> <4B1620E8.4040503@isi.edu>, <0C53DCFB700D144284A584F54711EC58087D6B2F@xmb-sjc-21c.amer.cisco.com> <64751D63-8618-489B-BA02-EC2839053122@mimectl>, <4B1685F7.9060603@isi.edu> <7028E675-20AC-4874-9C2E-D3216BA8EF36@mimectl> In-Reply-To: <7028E675-20AC-4874-9C2E-D3216BA8EF36@mimectl> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MailScanner-ID: nB2GIaXu001585 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" , "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] closing WGLC 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: Wed, 02 Dec 2009 16:19:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Smith, Donald wrote: > ... Smith, Donald wrote: >>> Yes, connectionless resets being equal to spoofed resets is a >>> major drawback and will hinder deployment in production systems. > >> It is present for IPsec as well. There's no way to recover >> generated keys that are lost after a reboot. > >> The only solution is to save the relevant state so it is not lost >> after a reboot. > > And I think for tcp-ao and bgp that should be the recommended > solution (at least a should if not a must). That helps only if this is a reboot issue. If the host simply disappears and the address is reassigned, then there's no such recovery possible. >> Why do you believe this would be an issue? It's already present >> whenever connections are not cleanly closed and addresses are >> reassigned to new hosts. > > My main area of concern here is BGP. When a router reboots and can > not reset its neighbors bgp sessions depending on various timers you > can have long delays before the restarting speaker can get neighbors > to accept new connections. In one senerio we had to remove the MD5 > auth to allow connectionless resets to terminate the old sessons > before new sessions could be established. This changed convergence > time from minutes to seconds. First, this matters only when BOTH port numbers are reused. Second, if you have enough access to a machine to shut off TCP MD5, why not simply clear out the stale connections? There are numerous reasons not to want to keep security state on disk - notably, it's a security hazard. This seems like an implementation issue that is not specific to TCP-AO - any security solution requires that old connections be purgeable by an operator. >> It's simple enough for a server that really cares about the state >> kept by such orphan connections to clean them up after a timeout. > > True, I don't have an issue with the orphan connections in most cases > but in bgp esp single session bgp this can have quite an impact on > restablishment and convergence times. The kind of state that needs to be kept for TCP-AO may make this very complicated. The rebooting host needs to establish new connections with new traffic keys, but needs to allow the connection to be reset with old traffic keys. This would strictly require keeping all traffic keys around until a new connection is successfully established on a given socket pair. That means keeping traffic keys (or enough info to reconstitute them) basically forever, "just in case". I'm not clear that this is a desirable alternative - the state required could be huge, and the delays required to save the state to disk reliably would impede the start of new connections (can't send SYN/ACK until logging the ISNs, etc.). It seems more appropriate to adjust existing timers,. and to try new connection attempt (with different source ports) after a reasonable period of non-response. Note that: - if the surviving side has data pending to send, that connection will be cleaned up due to existing TCP timeouts - if TCP has keepalives set, the same should be true even when there is no data to send So wouldn't keepalives solve this? Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksWk1sACgkQE5f5cImnZruCMwCg5ZsR7wewwmuvXwyZyP2Zf3Ri jHgAoK0QelKNd6KMycYPjPSj1PZRJx9E =FoLh -----END PGP SIGNATURE----- From fernando.gont.netbook.win@gmail.com Wed Dec 2 08:32: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 413083A6AD6 for ; Wed, 2 Dec 2009 08:32:06 -0800 (PST) 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 vFnfJJcwfRBg for ; Wed, 2 Dec 2009 08:32:05 -0800 (PST) Received: from mail-yw0-f117.google.com (mail-yw0-f117.google.com [209.85.211.117]) by core3.amsl.com (Postfix) with ESMTP id D99553A6AD3 for ; Wed, 2 Dec 2009 08:32:04 -0800 (PST) Received: by ywh15 with SMTP id 15so77066ywh.5 for ; Wed, 02 Dec 2009 08:31:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=3zkJqCv1TZ+uR8w5m2JtU1u99hG0DFd8lWC3312/E00=; b=UUE/MooevLyLTm3QEQpT+byL+rbu6OD0+V3ehcR5z2spZ2YR8JkreJVo3lPNzRMGqN LBUr78OyfKV+XZhcF4VzGXmpYQwP12oWXjDC5tLPHyxKHOmeSS/kyJa14cKhzM5PW+U8 4d72iL4ITBx9y7IpSQXc9M2ODe8RgRDbCqGig= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=V6dXJINQfSvOcNK8nK3ZgKVdQAQGh88j9oy4v4PfBtI07RLWBdhub3XwXOjT696sNe eYpJk2PdQRR9whNltyxStSClLDbUn9YCVjWFs8078ToaB7Y9M4dptaKd6MddrVaHZO7u +P0VJ2zFYSZ+wsaOmlxUuv9kpwaE2dyQJA1DY= Received: by 10.101.3.26 with SMTP id f26mr281974ani.5.1259771513508; Wed, 02 Dec 2009 08:31:53 -0800 (PST) Received: from ?192.168.0.168? (129-130-17-190.fibertel.com.ar [190.17.130.129]) by mx.google.com with ESMTPS id 23sm470911ywh.3.2009.12.02.08.31.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 02 Dec 2009 08:31:52 -0800 (PST) Sender: Fernando Gont Message-ID: <4B16966E.2010107@gont.com.ar> Date: Wed, 02 Dec 2009 13:31:42 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" References: <0C53DCFB700D144284A584F54711EC58087D6B17@xmb-sjc-21c.amer.cisco.com>, <4B16734C.3050107@gont.com.ar> In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "tcpm@ietf.org" , "Anantha Ramaiah \(ananth\)" , Joe Touch Subject: Re: [tcpm] closing WGLC 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: Wed, 02 Dec 2009 16:32:06 -0000 Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote: > AO is an example of the second case; it's benefited from very long > sesssions in some of our meetings (Dublin, Minneapolis, San > Francisco, etc), and the mailing list traffic attests that a lot of > people have read it, raised their issues, and had them addressed in > document updates. FWIW, I raised at least a couple of times that the document should make specific recommendations on what to do with ICMP messages. I have skimmed through the last version of the I-D, and while it does mention ICMP attacks, I don't think it provides concrete advice on what to do about it. If I were to implemente TCP-AO, one way or another I would have to make a decision about what to do about ICMP. And there's no clear advice in the current document wrt what to do about it. Some specific comments: Section 2.1: > o TCP-AO does not authenticate ICMP messages (some ICMP messages may > be authenticated when using IPsec, depending on the > configuration). It's not clear to me why if IPsec is there to authenticate some ICMP messages, one would be using TCP-AO in the first place. (My take is that IPsec won't be there). Section 12: > f. Optional ICMP discard. > > The option should allow certain ICMPs to be discarded, notably > Type 3 (destination unreachable), Codes 2-4 (transport > protocol unreachable, port unreachable, or fragmentation > needed and IP DF field set), i.e., the ones indicating the > failure of the endpoint to communicate. I don't think ICMP discard should be "optional". What's the point of using TCP-AO if you still abort connections in response to ICMP errors? IMO, it is a hole in the spec if this is left open. The spec should recommend a default. Also, this assumes PMTUD is not in use. What if PMTUD *is*¨in use? 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 rbonica@juniper.net Wed Dec 2 08:36: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 31CCC3A693E for ; Wed, 2 Dec 2009 08:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.39 X-Spam-Level: X-Spam-Status: No, score=-6.39 tagged_above=-999 required=5 tests=[AWL=0.209, 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 o6LhRnYoC3NG for ; Wed, 2 Dec 2009 08:36:50 -0800 (PST) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id A76C63A6933 for ; Wed, 2 Dec 2009 08:36:49 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKSxaXlqO7jMcKzedeMkgUroQH1KApB4vi@postini.com; Wed, 02 Dec 2009 08:36:42 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 2 Dec 2009 08:34:28 -0800 Received: from [172.28.134.68] (172.28.134.68) by p-emfe01-wf.jnpr.net (172.28.145.22) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 2 Dec 2009 11:34:27 -0500 Message-ID: <4B169712.8080907@juniper.net> Date: Wed, 2 Dec 2009 11:34:26 -0500 From: Ron Bonica User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Smith, Donald" References: <0C53DCFB700D144284A584F54711EC58087D6B17@xmb-sjc-21c.amer.cisco.com> <4B1620E8.4040503@isi.edu>, <0C53DCFB700D144284A584F54711EC58087D6B2F@xmb-sjc-21c.amer.cisco.com> <64751D63-8618-489B-BA02-EC2839053122@mimectl>, <4B1685F7.9060603@isi.edu> <7028E675-20AC-4874-9C2E-D3216BA8EF36@mimectl> In-Reply-To: <7028E675-20AC-4874-9C2E-D3216BA8EF36@mimectl> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" , "Anantha Ramaiah \(ananth\)" , Joe Touch Subject: Re: [tcpm] closing WGLC 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: Wed, 02 Dec 2009 16:36:51 -0000 > >> It's simple enough for a server that really cares about the state kept >> by such orphan connections to clean them up after a timeout. > True, I don't have an issue with the orphan connections in most cases but >in bgp esp single session bgp this can have quite an impact on restablishment >and convergence times. One way to address this problem is to set the BGP Keepalive timer to a sufficiently low value. The down side is that BGP will send bgp keepalives more frequently. The up side is that you will detect this and many other problems in a more timely manner. Ron From touch@ISI.EDU Wed Dec 2 08: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 9FDDF3A6943 for ; Wed, 2 Dec 2009 08:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 Wzld5dRuZST8 for ; Wed, 2 Dec 2009 08:47:44 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id AD1DA3A6801 for ; Wed, 2 Dec 2009 08:47:44 -0800 (PST) Received: from [192.168.1.43] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id nB2GkZaU007505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Dec 2009 08:46:36 -0800 (PST) Message-ID: <4B1699EB.8090608@isi.edu> Date: Wed, 02 Dec 2009 08:46:35 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Fernando Gont References: <0C53DCFB700D144284A584F54711EC58087D6B17@xmb-sjc-21c.amer.cisco.com>, <4B16734C.3050107@gont.com.ar> <4B16966E.2010107@gont.com.ar> In-Reply-To: <4B16966E.2010107@gont.com.ar> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MailScanner-ID: nB2GkZaU007505 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" , "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] closing WGLC 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: Wed, 02 Dec 2009 16:47:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Gont wrote: > Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote: > >> AO is an example of the second case; it's benefited from very long >> sesssions in some of our meetings (Dublin, Minneapolis, San >> Francisco, etc), and the mailing list traffic attests that a lot of >> people have read it, raised their issues, and had them addressed in >> document updates. > > FWIW, I raised at least a couple of times that the document should make > specific recommendations on what to do with ICMP messages. I have > skimmed through the last version of the I-D, and while it does mention > ICMP attacks, I don't think it provides concrete advice on what to do > about it. See Section 12 as noted below. > If I were to implemente TCP-AO, one way or another I would have to make > a decision about what to do about ICMP. And there's no clear advice in > the current document wrt what to do about it. There was, AFAIR, no clear WG consensus on whether to require a particular behavior as default. > Some specific comments: > > Section 2.1: > >> o TCP-AO does not authenticate ICMP messages (some ICMP messages may >> be authenticated when using IPsec, depending on the >> configuration). > > It's not clear to me why if IPsec is there to authenticate some ICMP > messages, one would be using TCP-AO in the first place. (My take is that > IPsec won't be there). That paragraph isn't talking about using IPsec with TCP-AO; it's discussing the properties of the two separately. > Section 12: > >> f. Optional ICMP discard. >> >> The option should allow certain ICMPs to be discarded, notably >> Type 3 (destination unreachable), Codes 2-4 (transport >> protocol unreachable, port unreachable, or fragmentation >> needed and IP DF field set), i.e., the ones indicating the >> failure of the endpoint to communicate. > > I don't think ICMP discard should be "optional". What's the point of > using TCP-AO if you still abort connections in response to ICMP errors? > > IMO, it is a hole in the spec if this is left open. The spec should > recommend a default. > > Also, this assumes PMTUD is not in use. What if PMTUD *is*¨in use? Well, there's you're reason for not having this as a default. If you do, then you have a MTU discovery black hole you didn't know about. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksWmeoACgkQE5f5cImnZruKWACgh9M7pfQWwoFYocSr12UkQR3f MZQAn0372fKjFpODWqQjkHpUu3jS1N6Z =vWZa -----END PGP SIGNATURE----- From touch@ISI.EDU Wed Dec 2 08:51: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 3E4D03A6870 for ; Wed, 2 Dec 2009 08:51:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 UXwB2C3Keaar for ; Wed, 2 Dec 2009 08:51:09 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 4E91C3A6962 for ; Wed, 2 Dec 2009 08:51:09 -0800 (PST) Received: from [192.168.1.43] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id nB2Go50o008414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Dec 2009 08:50:06 -0800 (PST) Message-ID: <4B169ABA.106@isi.edu> Date: Wed, 02 Dec 2009 08:50:02 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Fernando Gont References: <0C53DCFB700D144284A584F54711EC58087D6B17@xmb-sjc-21c.amer.cisco.com>, <4B16734C.3050107@gont.com.ar> <4B16966E.2010107@gont.com.ar> In-Reply-To: <4B16966E.2010107@gont.com.ar> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MailScanner-ID: nB2Go50o008414 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" , "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] closing WGLC 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: Wed, 02 Dec 2009 16:51:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Additionally: Fernando Gont wrote: > Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote: > >> AO is an example of the second case; it's benefited from very long >> sesssions in some of our meetings (Dublin, Minneapolis, San >> Francisco, etc), and the mailing list traffic attests that a lot of >> people have read it, raised their issues, and had them addressed in >> document updates. > > FWIW, I raised at least a couple of times that the document should make > specific recommendations on what to do with ICMP messages. I have > skimmed through the last version of the I-D, and while it does mention > ICMP attacks, I don't think it provides concrete advice on what to do > about it. >> A TCP-AO implementation MUST allow the system administrator to configure whether TCP will ignore incoming ICMP messages of Type 3 (destination unreachable) Codes 2-4 (protocol unreachable, port unreachable, and fragmentation needed - 'hard errors') intended for connections that match MKTs. An implementation SHOULD allow ignored ICMPs to be logged. This control affects only ICMPs that currently require 'hard errors', which would abort the TCP connection [RFC1122]. This recommendation is intended to be similar to how IPsec would handle those messages [RFC4301]. > Some specific comments: > > Section 2.1: > >> o TCP-AO does not authenticate ICMP messages (some ICMP messages may >> be authenticated when using IPsec, depending on the >> configuration). > > It's not clear to me why if IPsec is there to authenticate some ICMP > messages, one would be using TCP-AO in the first place. (My take is that > IPsec won't be there). Note also that this is in the summary explaining how TCP-AO is different from IPsec, so I think the intent of the statement is clear. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksWmroACgkQE5f5cImnZrsAZgCfdsTR5B+9vugg2imN/XHw3rFD r4QAn2ZEGmDhEh3PIJ6E4Fi4QLAD8PWv =TsMD -----END PGP SIGNATURE----- From touch@ISI.EDU Wed Dec 2 09:04: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 1677E3A67A5 for ; Wed, 2 Dec 2009 09:04:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.591 X-Spam-Level: X-Spam-Status: No, score=-3.591 tagged_above=-999 required=5 tests=[AWL=1.008, BAYES_00=-2.599, GB_I_INVITATION=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hh3hsp686hm0 for ; Wed, 2 Dec 2009 09:04:23 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 2BE6E3A6832 for ; Wed, 2 Dec 2009 09:04:23 -0800 (PST) Received: from [192.168.1.43] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id nB2H2TL6010941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Dec 2009 09:02:30 -0800 (PST) Message-ID: <4B169DA5.90706@isi.edu> Date: Wed, 02 Dec 2009 09:02:29 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MailScanner-ID: nB2H2TL6010941 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] closing WGLC 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: Wed, 02 Dec 2009 17:04:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, all, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote: > The period for the working group last call on the AO documents > has passed. I didn't see any major issues that were identified. Well, apparently everyone took that as the invitation for a real last call. I'll summarize the issues, with some questions to the WG: - - discarding RSTs after reboot QUESTION: whether to include a note about recommending TCP keepalive on both ends where this is a concern, additionally: include that the side that is blocking (not the side rebooting) needs to have the keepalive set include a note that the alternative is to prevent destruction of state due to a reboot, but that a similar effect happens when a machine is replaced or when an address is reassigned - - ICMPs QUESTION: whether to recommend discard hard ICMPs for TCP-AO protected connections as a MUST or SHOULD Note - at this point, AFAICT we'd be seeking consensus, so even if you agree, please post. Given we're already past last-call, I'd presume we could close the call for responses after a very short interval. Were there any other specific issues? Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksWnaUACgkQE5f5cImnZrsFawCg0hQYqeyEIjmMbGXtKg+AB54G nmsAoPboNLfEHRzs3MEm/ivBD4c0+35b =aXny -----END PGP SIGNATURE----- From fernando.gont.netbook.win@gmail.com Wed Dec 2 09:15: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 5CDE13A6ABC for ; Wed, 2 Dec 2009 09:15:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.563 X-Spam-Level: X-Spam-Status: No, score=-1.563 tagged_above=-999 required=5 tests=[AWL=-1.036, BAYES_00=-2.599, RCVD_IN_NJABL_SPAM=2.072] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLD9P7oIpKqR for ; Wed, 2 Dec 2009 09:15:45 -0800 (PST) Received: from mail-gx0-f171.google.com (mail-gx0-f171.google.com [209.85.217.171]) by core3.amsl.com (Postfix) with ESMTP id 744D93A6856 for ; Wed, 2 Dec 2009 09:15:45 -0800 (PST) Received: by gxk19 with SMTP id 19so30574gxk.9 for ; Wed, 02 Dec 2009 09:15:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=FOLD8bfSq5OzgrsPoVLzdE4u94ljbtDxRDtmJdjL5xQ=; b=aK9dqHX96C7WKfb6+iKfwsPs1NkY2enFzpypNf8q4LiZ6KY7j2VGBxtsYVDzgCYa+J us49xf9wxGLTUb8fPE1GcMMtMteeAl4cjFEAvgQofP3fl+Cn/+ykjrj2NHZKLyBDSDsH gDQQMBmzBEZgNgCrA7Fi4v9GChIdJ2LJrksCQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=w7CxemgQBnvniMxQsY9Tv0UCsrFBLxlsp26QHzqQEo0UAeuHeKSI9c7rbj38lX+D+D C5vEIBZ1JPmWJE0AL4vvJGIjPNWD/QIWtiMU+I++Mtsk5ABRTqyFqnrh8snmju+6GnnW Nmph+wc++omdwNMpBv15rdLUO9NU/TiOck2NY= Received: by 10.101.187.12 with SMTP id o12mr378209anp.122.1259774136870; Wed, 02 Dec 2009 09:15:36 -0800 (PST) Received: from ?192.168.0.168? (129-130-17-190.fibertel.com.ar [190.17.130.129]) by mx.google.com with ESMTPS id 4sm483509ywi.57.2009.12.02.09.15.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 02 Dec 2009 09:15:36 -0800 (PST) Sender: Fernando Gont Message-ID: <4B16A0AE.2060908@gont.com.ar> Date: Wed, 02 Dec 2009 14:15:26 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Joe Touch References: <0C53DCFB700D144284A584F54711EC58087D6B17@xmb-sjc-21c.amer.cisco.com>, <4B16734C.3050107@gont.com.ar> <4B16966E.2010107@gont.com.ar> <4B1699EB.8090608@isi.edu> In-Reply-To: <4B1699EB.8090608@isi.edu> X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "tcpm@ietf.org" , "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] closing WGLC 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: Wed, 02 Dec 2009 17:15:46 -0000 Joe Touch wrote: >> If I were to implemente TCP-AO, one way or another I would have to make >> a decision about what to do about ICMP. And there's no clear advice in >> the current document wrt what to do about it. > > There was, AFAIR, no clear WG consensus on whether to require a > particular behavior as default. I don't think this issues was even discussed. I raised it, but other than your response, there was no discussion about it. >> Section 12: > >>> f. Optional ICMP discard. >>> >>> The option should allow certain ICMPs to be discarded, notably >>> Type 3 (destination unreachable), Codes 2-4 (transport >>> protocol unreachable, port unreachable, or fragmentation >>> needed and IP DF field set), i.e., the ones indicating the >>> failure of the endpoint to communicate. >> I don't think ICMP discard should be "optional". What's the point of >> using TCP-AO if you still abort connections in response to ICMP errors? > >> IMO, it is a hole in the spec if this is left open. The spec should >> recommend a default. > >> Also, this assumes PMTUD is not in use. What if PMTUD *is*¨in use? > > Well, there's you're reason for not having this as a default. If you do, > then you have a MTU discovery black hole you didn't know about. Let me rephrase my comment: TCP-AO should make a specific recommendation on how to deal with ICMP. This means it may recommend ignore ICMP hard errors (or, well, process them as soft errors) *and* implement PLPMTUD, or whatever. But I don't think this should be left unspecified. Everyone will have to make this decision when TCP-AO is implemented. So we would be washing our hands about this problem, and what's worse, chances are that some implementation will end up doing the wrong thing. Note: I think this issue can be easily addressed. And I'm trying to be constructive. 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 Donald.Smith@qwest.com Wed Dec 2 09:22: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 0EED33A6768 for ; Wed, 2 Dec 2009 09:22:51 -0800 (PST) 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 LrV1fTKJsC+k for ; Wed, 2 Dec 2009 09:22:50 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id DD57F3A63EB for ; Wed, 2 Dec 2009 09:22:49 -0800 (PST) Received: from suomp60i.qintra.com (suomp60i.qintra.com [151.117.69.27]) by suomp64i.qwest.com (8.14.0/8.14.0) with ESMTP id nB2HMeNs015177; Wed, 2 Dec 2009 11:22:40 -0600 (CST) Received: from qtdenexhtm21.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.0/8.14.0) with ESMTP id nB2HMZEQ019396; Wed, 2 Dec 2009 11:22:35 -0600 (CST) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm21.AD.QINTRA.COM ([151.119.91.230]) with mapi; Wed, 2 Dec 2009 10:22:32 -0700 From: "Smith, Donald" To: Joe Touch Content-Class: urn:content-classes:message Date: Wed, 2 Dec 2009 10:22:24 -0700 Thread-Topic: [tcpm] closing WGLC for TCP-AO Thread-Index: Acpzazl18Vv9T0OLQIi8b/O3FxISbgABTV9oAADlJQw= Message-ID: References: <0C53DCFB700D144284A584F54711EC58087D6B17@xmb-sjc-21c.amer.cisco.com> <4B1620E8.4040503@isi.edu>, <0C53DCFB700D144284A584F54711EC58087D6B2F@xmb-sjc-21c.amer.cisco.com> <64751D63-8618-489B-BA02-EC2839053122@mimectl>, <4B1685F7.9060603@isi.edu> <7028E675-20AC-4874-9C2E-D3216BA8EF36@mimectl>, <4B16935B.2020209@isi.edu> In-Reply-To: <4B16935B.2020209@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-mimectl: Produced By Microsoft Exchange V8.1.348.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" , "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] closing WGLC 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: Wed, 02 Dec 2009 17:22:51 -0000 (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com ________________________________ From: Joe Touch [touch@ISI.EDU] Sent: Wednesday, December 02, 2009 9:18 AM To: Smith, Donald Cc: Anantha Ramaiah (ananth); tcpm@ietf.org Subject: Re: [tcpm] closing WGLC for TCP-AO > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Smith, Donald wrote: > > ... Smith, Donald wrote: > >>> Yes, connectionless resets being equal to spoofed resets is a > >>> major drawback and will hinder deployment in production systems. > > > >> It is present for IPsec as well. There's no way to recover > >> generated keys that are lost after a reboot. > > > >> The only solution is to save the relevant state so it is not lost > >> after a reboot. > > > > And I think for tcp-ao and bgp that should be the recommended > > solution (at least a should if not a must). > > That helps only if this is a reboot issue. If the host simply disappears > and the address is reassigned, then there's no such recovery possible. Agreed, but that almost never happens to bgp peers:) > > >> Why do you believe this would be an issue? It's already present > >> whenever connections are not cleanly closed and addresses are > >> reassigned to new hosts. > > > > My main area of concern here is BGP. When a router reboots and can > > not reset its neighbors bgp sessions depending on various timers you > > can have long delays before the restarting speaker can get neighbors > > to accept new connections. In one senerio we had to remove the MD5 > > auth to allow connectionless resets to terminate the old sessons > > before new sessions could be established. This changed convergence > > time from minutes to seconds. > > First, this matters only when BOTH port numbers are reused. No if a single session bgp speaker reboots his peers will NOT allow a new s= ession to establish till the hold timer (or some other timer) expires. In graceful restart mode a receiving speaker should treat a new session fro= m the restarting speaker as reason to terminate the old session but we have= seen implementations that do not follow the rfc. > > Second, if you have enough access to a machine to shut off TCP MD5, why > not simply clear out the stale connections? This needs to be automatic. Turning off md5 auth was a manual task that I w= ouldn't normally recommend be done on live productions systems. > > There are numerous reasons not to want to keep security state on disk - > notably, it's a security hazard. Assuming good physical and logical security I would argue this isn't much o= f a hazard. Most routers already store various security creditential, including a passw= ord of last resort, on disk often in a reversable encrypted state. >This seems like an implementation issue > that is not specific to TCP-AO - any security solution requires that old > connections be purgeable by an operator. Agreed, but you don't want to be doing this on production bgp speakers in r= eal time. So either you disable it per your base configuration or accept connectionle= ss resets won't work. > > >> It's simple enough for a server that really cares about the state > >> kept by such orphan connections to clean them up after a timeout. > > > > True, I don't have an issue with the orphan connections in most cases > > but in bgp esp single session bgp this can have quite an impact on > > restablishment and convergence times. > > The kind of state that needs to be kept for TCP-AO may make this very > complicated. The rebooting host needs to establish new connections with > new traffic keys, but needs to allow the connection to be reset with old > traffic keys. Not quite, the rebooting host needs to be able to reset the old session to = its peers with the old keys. It doesn't need it's old session reset. > > This would strictly require keeping all traffic keys around until a new > connection is successfully established on a given socket pair. That > means keeping traffic keys (or enough info to reconstitute them) > basically forever, "just in case". Not forever. This could probably be tied to the GR restart time. Without GR you could have a "reboot" timer so some sort so you keep old key= s for a reasonable amount of time. > > I'm not clear that this is a desirable alternative - the state required > could be huge, and the delays required to save the state to disk I don't think it is huge if a router had 20 peers that would be 20 keys. > reliably would impede the start of new connections (can't send SYN/ACK > until logging the ISNs, etc.). Actually I think you would want to log the key or ISNs after the three way = was successful. Perhaps even after a successful open msg? >It seems more appropriate to adjust > existing timers,. and to try new connection attempt (with different > source ports) after a reasonable period of non-response. > > Note that: > > - if the surviving side has data pending to send, > that connection will be cleaned up due to existing > TCP timeouts Which tend to be fairly long (minutes, multiple retrys ...) and are not alw= ays adjustable. The bgp hold timer usually comes into play first depending on the value you= have assigned to that. > > - if TCP has keepalives set, the same should be true > even when there is no data to send I haven't seen a bgp implementation that relied on tcp keepalives. Most use the hold timer and keep alive advertisement specific to bgp. The recommend minimum for holdtimer and KA is 21/7 seconds. Which if your trying for a HA type failover is a LONG time. > > So wouldn't keepalives solve this? > > Joe > > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > > iEYEARECAAYFAksWk1sACgkQE5f5cImnZruCMwCg5ZsR7wewwmuvXwyZyP2Zf3Ri > jHgAoK0QelKNd6KMycYPjPSj1PZRJx9E > =3DFoLh > -----END PGP SIGNATURE----- > > ________________________________ This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From touch@ISI.EDU Wed Dec 2 09:34: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 B573828C0DE for ; Wed, 2 Dec 2009 09:34:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.638 X-Spam-Level: X-Spam-Status: No, score=-2.638 tagged_above=-999 required=5 tests=[AWL=-0.039, 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 xD5mcy+I99+9 for ; Wed, 2 Dec 2009 09:34:09 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id D81BB3A680F for ; Wed, 2 Dec 2009 09:34:09 -0800 (PST) Received: from [192.168.1.43] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id nB2HWYe4016692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Dec 2009 09:32:35 -0800 (PST) Message-ID: <4B16A4B2.7010809@isi.edu> Date: Wed, 02 Dec 2009 09:32:34 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Smith, Donald" References: <0C53DCFB700D144284A584F54711EC58087D6B17@xmb-sjc-21c.amer.cisco.com> <4B1620E8.4040503@isi.edu>, <0C53DCFB700D144284A584F54711EC58087D6B2F@xmb-sjc-21c.amer.cisco.com> <64751D63-8618-489B-BA02-EC2839053122@mimectl>, <4B1685F7.9060603@isi.edu> <7028E675-20AC-4874-9C2E-D3216BA8EF36@mimectl>, <4B16935B.2020209@isi.edu> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MailScanner-ID: nB2HWYe4016692 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" , "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] closing WGLC 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: Wed, 02 Dec 2009 17:34:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Smith, Donald wrote: ... >> The kind of state that needs to be kept for TCP-AO may make this very >> complicated. The rebooting host needs to establish new connections with >> new traffic keys, but needs to allow the connection to be reset with old >> traffic keys. > > Not quite, the rebooting host needs to be able to reset the old session to its peers with the old keys. > It doesn't need it's old session reset. The state is at the non-rebooting side. When the rebooting side tries to connect, it will receive a RST back, which will have the old keys and be ignored. The only way the non-rebooting side would receive a RST would be because it's still trying to send data, at which point TCP would time-out anyway. As Ron noted - this can be adjusted with the hold-down timers. >> > This would strictly require keeping all traffic keys around until a new >> > connection is successfully established on a given socket pair. That >> > means keeping traffic keys (or enough info to reconstitute them) >> > basically forever, "just in case". > > Not forever. This could probably be tied to the GR restart time. You need to hold onto the keys as long as it might ever take to have an endpoint restart. Note that restarting also means being physically replaced with a new system with the same IP address, i.e., upgraded - e.g., as would happen when the old system died rather than being safely shut down. >> > reliably would impede the start of new connections (can't send SYN/ACK >> > until logging the ISNs, etc.). > > Actually I think you would want to log the key or ISNs after the three way was successful. > Perhaps even after a successful open msg? You'd need to do it before you got into a TCP state that doesn't have an idle timeout. If you want 'responsiveness', you'd need to do it for basically any TCP transition. ... > The recommend minimum for holdtimer and KA is 21/7 seconds. > > Which if your trying for a HA type failover is a LONG time. That's seconds. I can't see changing a protocol to save seconds for an event that - if frequent - is more indicative of a problem with a router than a problem with a protocol. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksWpLIACgkQE5f5cImnZrvv6gCfZdXLrQpM2p2joBkQlnec6lCn rRkAni9sEUI3Usx0L8sNn4PIwcdq21pV =/Mf4 -----END PGP SIGNATURE----- From touch@ISI.EDU Wed Dec 2 09:38: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 AC9023A6807 for ; Wed, 2 Dec 2009 09:38:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.636 X-Spam-Level: X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=-0.037, 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 fyQVRnE5xEqL for ; Wed, 2 Dec 2009 09:38:59 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 10C613A67F3 for ; Wed, 2 Dec 2009 09:38:59 -0800 (PST) Received: from [192.168.1.43] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id nB2Hbung017645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Dec 2009 09:37:57 -0800 (PST) Message-ID: <4B16A5F4.2010505@isi.edu> Date: Wed, 02 Dec 2009 09:37:56 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Fernando Gont References: <0C53DCFB700D144284A584F54711EC58087D6B17@xmb-sjc-21c.amer.cisco.com>, <4B16734C.3050107@gont.com.ar> <4B16966E.2010107@gont.com.ar> <4B1699EB.8090608@isi.edu> <4B16A0AE.2060908@gont.com.ar> In-Reply-To: <4B16A0AE.2060908@gont.com.ar> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MailScanner-ID: nB2Hbung017645 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" , "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] closing WGLC 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: Wed, 02 Dec 2009 17:38:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Gont wrote: ... > Let me rephrase my comment: > > TCP-AO should make a specific recommendation on how to deal with ICMP. > > This means it may recommend ignore ICMP hard errors (or, well, process > them as soft errors) That might be reasonable. > *and* implement PLPMTUD, We could note that this could be used, but I don't see us requiring something that heavyweight by default. > or whatever. Can you be more specific? > But I don't think this should be left unspecified. You've made that point before. I've made the point that it is unspecified as a default for IPsec. Let's hear from others. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksWpfQACgkQE5f5cImnZrvZIgCg7xKwa6Qu2FoyLZkqXI0x8qUM NqIAnjNKOzgr6usinHu4DzE8wj+Mf5PP =Moj0 -----END PGP SIGNATURE----- From fernando.gont.netbook.win@gmail.com Wed Dec 2 10:01: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 6E9983A6947 for ; Wed, 2 Dec 2009 10:01:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.254 X-Spam-Level: X-Spam-Status: No, score=-2.254 tagged_above=-999 required=5 tests=[AWL=0.345, 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 B6HNkCHFAERt for ; Wed, 2 Dec 2009 10:01:06 -0800 (PST) Received: from mail-yw0-f117.google.com (mail-yw0-f117.google.com [209.85.211.117]) by core3.amsl.com (Postfix) with ESMTP id 930963A6927 for ; Wed, 2 Dec 2009 10:01:06 -0800 (PST) Received: by ywh15 with SMTP id 15so96337ywh.5 for ; Wed, 02 Dec 2009 10:00:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=qVFqxBprLh1FW3JPfEkWnmKG361KB+aQ6Sjkl6Debe8=; b=YOwtQl2PTuRAIvj8V4quPT3i2u3IArxy/Iv1kfXg36DwT9Pn8BXcXbxJvgXUfn5J5q trZ0QRV4usd0+CdOHu75fKn0ZmRrTaQcxqSE0nOzBWz1soY1oTaV+0jDdFKv8fKbMoEP F54Z/NjZZohPCns5Egfs/FWrV32m3NXXRLQv0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=X7dppJB0LDRh4qbm10kRnLSDRN2FpjoKLCVTwUCCEnKbmA1sA93JYYaZiXsHc2ryXS Z+4jZ0npgMQc+Mct7hsJLy2s6IdL6blhZgWF6h3f53sOCTD+eaojarkZYrrZ7qfsXnHx i583H4UY2m6unKITTF9AXY6VXFGsAyXUtWqu0= Received: by 10.101.146.27 with SMTP id y27mr472774ann.62.1259776855042; Wed, 02 Dec 2009 10:00:55 -0800 (PST) Received: from ?192.168.0.168? (129-130-17-190.fibertel.com.ar [190.17.130.129]) by mx.google.com with ESMTPS id 9sm497094ywf.35.2009.12.02.10.00.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 02 Dec 2009 10:00:54 -0800 (PST) Sender: Fernando Gont Message-ID: <4B16AB4C.4080501@gont.com.ar> Date: Wed, 02 Dec 2009 15:00:44 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Joe Touch References: <0C53DCFB700D144284A584F54711EC58087D6B17@xmb-sjc-21c.amer.cisco.com>, <4B16734C.3050107@gont.com.ar> <4B16966E.2010107@gont.com.ar> <4B1699EB.8090608@isi.edu> <4B16A0AE.2060908@gont.com.ar> <4B16A5F4.2010505@isi.edu> In-Reply-To: <4B16A5F4.2010505@isi.edu> X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" , "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] closing WGLC 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: Wed, 02 Dec 2009 18:01:07 -0000 Joe Touch wrote: >> This means it may recommend ignore ICMP hard errors (or, well, process >> them as soft errors) > > That might be reasonable. > >> *and* implement PLPMTUD, > > We could note that this could be used, but I don't see us requiring > something that heavyweight by default. I agree that PLPMTUD is heavyweight -- just proposed that as a NIH-suggestion. I would argue that the mechanism described in the ICMP attacks I-D is easy to implement (I did it myself), and unless you can interrupt the packet flow, it is hard to tamper with (and is certainly better than nothing, anyway). >> or whatever. > > Can you be more specific? ignoring hard errors (or processing them as soft errors) *and* implementing the PMTUD mitigation technique in the ICMP I-D is another possibility. For the BGP-use case, one might argue that you could probably safely ignores ICMP PTB that advertise a small MTU. >> But I don't think this should be left unspecified. > > You've made that point before. I've made the point that it is > unspecified as a default for IPsec. There are lots of things that have been left unspecified. Both in IPsec, TCP MD5, and others. That doesn't mean that we should re-hash that. 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 Donald.Smith@qwest.com Wed Dec 2 10:10: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 4E63F3A6359 for ; Wed, 2 Dec 2009 10:10:49 -0800 (PST) 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 TkH-OKkgGC5v for ; Wed, 2 Dec 2009 10:10:46 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id 809733A677E for ; Wed, 2 Dec 2009 10:10:45 -0800 (PST) Received: from suomp61i.qintra.com (suomp61i.qintra.com [151.117.69.28]) by suomp64i.qwest.com (8.14.0/8.14.0) with ESMTP id nB2IAZot013043; Wed, 2 Dec 2009 12:10:35 -0600 (CST) Received: from qtdenexhtm21.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.0/8.14.0) with ESMTP id nB2IASNS029507; Wed, 2 Dec 2009 12:10:30 -0600 (CST) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm21.AD.QINTRA.COM ([151.119.91.230]) with mapi; Wed, 2 Dec 2009 11:10:28 -0700 From: "Smith, Donald" To: Joe Touch Content-Class: urn:content-classes:message Date: Wed, 2 Dec 2009 11:10:21 -0700 Thread-Topic: [tcpm] closing WGLC for TCP-AO Thread-Index: AcpzdaTnazUzpzr6Qs+TGSGCw451FQAAl4ZmAACsuVY= Message-ID: References: <0C53DCFB700D144284A584F54711EC58087D6B17@xmb-sjc-21c.amer.cisco.com> <4B1620E8.4040503@isi.edu>, <0C53DCFB700D144284A584F54711EC58087D6B2F@xmb-sjc-21c.amer.cisco.com> <64751D63-8618-489B-BA02-EC2839053122@mimectl>, <4B1685F7.9060603@isi.edu> <7028E675-20AC-4874-9C2E-D3216BA8EF36@mimectl>, <4B16935B.2020209@isi.edu> , <4B16A4B2.7010809@isi.edu> In-Reply-To: <4B16A4B2.7010809@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-mimectl: Produced By Microsoft Exchange V8.1.348.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" , "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] closing WGLC 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: Wed, 02 Dec 2009 18:10:49 -0000 (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com ________________________________ From: Joe Touch [touch@ISI.EDU] Sent: Wednesday, December 02, 2009 10:32 AM To: Smith, Donald Cc: Anantha Ramaiah (ananth); tcpm@ietf.org Subject: Re: [tcpm] closing WGLC for TCP-AO > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Smith, Donald wrote: > ... > >> The kind of state that needs to be kept for TCP-AO may make this very > >> complicated. The rebooting host needs to establish new connections wit= h > >> new traffic keys, but needs to allow the connection to be reset with o= ld > >> traffic keys. > > > > Not quite, the rebooting host needs to be able to reset the old session= to >> its peers with the old keys. > > It doesn't need it's old session reset. > > The state is at the non-rebooting side. No the non-rebooting side still "thinks" it has a session with the restarti= ng/rebooting peer. It is the rebooting side that needs to be able to send an authenticated res= et to terminate the old peering session. > > When the rebooting side tries to connect, it will receive a RST back, > which will have the old keys and be ignored. No, when the rebooting side tries to connect (depending on if GR is enabled= ) you will see to different behaviors. The rebooting router attempts to establish a new session. The non-rebooting router allows that connection since this is a valid peer. The rebooting router sends an open msg with its neighbor ID. The non-rebooting router sees that is already has that neighbor ID in its d= ata base and sends some type of msg usually a notify error msg. They do a 3 or 4 way fin handshake to teardown the NEW session. Depending on hold timer you may see this happen a few time:( > > The only way the non-rebooting side would receive a RST would be because > it's still trying to send data, at which point TCP would time-out > anyway. As Ron noted - this can be adjusted with the hold-down timers. That is the issue. The reset will be sent by the rebooting router on the fi= rst packet from the non-rebooting peer so at a minimum it will reset based = on the next keepalive packet/timer (usually a 1/3 of the hold timer). So ba= sed on bcp's if you wait for the hold timer it will be three times as long = before a session can be established. > > >> > This would strictly require keeping all traffic keys around until a = new > >> > connection is successfully established on a given socket pair. That > >> > means keeping traffic keys (or enough info to reconstitute them) > >> > basically forever, "just in case". > > > > Not forever. This could probably be tied to the GR restart time. > > You need to hold onto the keys as long as it might ever take to have an > endpoint restart. Note that restarting also means being physically > replaced with a new system with the same IP address, i.e., upgraded - > e.g., as would happen when the old system died rather than being safely > shut down. > > >> > reliably would impede the start of new connections (can't send SYN/A= CK > >> > until logging the ISNs, etc.). > > > > Actually I think you would want to log the key or ISNs after the three = way >> was successful. > > Perhaps even after a successful open msg? > > You'd need to do it before you got into a TCP state that doesn't have an > idle timeout. If you want 'responsiveness', you'd need to do it for > basically any TCP transition. > > ... > > The recommend minimum for holdtimer and KA is 21/7 seconds. > > > > Which if your trying for a HA type failover is a LONG time. > > That's seconds. I can't see changing a protocol to save seconds for an > event that - if frequent - is more indicative of a problem with a router > than a problem with a protocol. In my example it is seconds but that is the minimum most holdtimers and KA = are much longer then that. In most of the implementations I have seen the default in most cases is min= utes. Cisco uses 60/180 KA/holdtime. http://www.cisco.com/en/US/docs/ios/12_0/np1/configuration/guide/1cbgp.html Juniper appears to use 30/90 http://www.juniper.net/techpubs/software/junos= /junos56/swcmdref56/html/bgp-monitor5.html If your also using a deferal timer to allow an igp to converge before sendi= ng out route updates you have to add that to the hold-timer. > > Joe > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > > iEYEARECAAYFAksWpLIACgkQE5f5cImnZrvv6gCfZdXLrQpM2p2joBkQlnec6lCn > rRkAni9sEUI3Usx0L8sNn4PIwcdq21pV > =3D/Mf4 > -----END PGP SIGNATURE----- ________________________________ This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From touch@ISI.EDU Wed Dec 2 10:11: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 F2EA83A695F for ; Wed, 2 Dec 2009 10:11:42 -0800 (PST) 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 PIoHrGxPjnRv for ; Wed, 2 Dec 2009 10:11:42 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id DECC43A6359 for ; Wed, 2 Dec 2009 10:11:41 -0800 (PST) Received: from [75.213.146.151] (151.sub-75-213-146.myvzw.com [75.213.146.151]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nB2IAoLM018708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Dec 2009 10:10:53 -0800 (PST) Message-ID: <4B16ADA9.2090003@isi.edu> Date: Wed, 02 Dec 2009 10:10:49 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Fernando Gont References: <0C53DCFB700D144284A584F54711EC58087D6B17@xmb-sjc-21c.amer.cisco.com>, <4B16734C.3050107@gont.com.ar> <4B16966E.2010107@gont.com.ar> <4B1699EB.8090608@isi.edu> <4B16A0AE.2060908@gont.com.ar> In-Reply-To: <4B16A0AE.2060908@gont.com.ar> 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" , "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] closing WGLC 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: Wed, 02 Dec 2009 18:11:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Gont wrote: > Joe Touch wrote: > >>> If I were to implemente TCP-AO, one way or another I would have to make >>> a decision about what to do about ICMP. And there's no clear advice in >>> the current document wrt what to do about it. >> There was, AFAIR, no clear WG consensus on whether to require a >> particular behavior as default. > > I don't think this issues was even discussed. I raised it, but other > than your response, there was no discussion about it. You raised it 6/16, and on 6/16 agreed to the text that the doc now includes (see snip below). You did say we ought to consider a default at that time (and in a few followup posts, all on the same day). As you note, nobody else posted on this issue. Joe - --- > We could add that TCP-AO, like IPsec (text copied from 4301): > > > > ...A compliant TCP-AO > > implementation MUST permit a local administrator to configure an > > IPsec implementation to accept or reject unauthenticated ICMP > > traffic. This control MUST be at the granularity of ICMP type and > > MAY be at the granularity of ICMP type and code. Additionally, an > > implementation SHOULD incorporate mechanisms and parameters for > > dealing with such traffic. For example, there could be the ability > > to establish a minimum PMTU for traffic (on a per destination basis), > > to prevent receipt of an unauthenticated ICMP from setting the PMTU > > to a trivial size. Makes sense to me. Although, again, I believe there should be (safe) defaults for this. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksWrakACgkQE5f5cImnZrvFwACgrKjVaUQ2xt6qHc2bYuavbom9 ozYAnj8BK3jwBIWabKKsn0y7wvnZahT1 =+yIS -----END PGP SIGNATURE----- From touch@ISI.EDU Wed Dec 2 10:21: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 6C0493A6911 for ; Wed, 2 Dec 2009 10:21:49 -0800 (PST) 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 CfcBuA2zU7wP for ; Wed, 2 Dec 2009 10:21:48 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 9D21B3A6359 for ; Wed, 2 Dec 2009 10:21:48 -0800 (PST) Received: from [75.213.146.151] (151.sub-75-213-146.myvzw.com [75.213.146.151]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nB2ILJ5j021662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Dec 2009 10:21:23 -0800 (PST) Message-ID: <4B16B01F.9030404@isi.edu> Date: Wed, 02 Dec 2009 10:21:19 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Fernando Gont References: <0C53DCFB700D144284A584F54711EC58087D6B17@xmb-sjc-21c.amer.cisco.com>, <4B16734C.3050107@gont.com.ar> <4B16966E.2010107@gont.com.ar> <4B1699EB.8090608@isi.edu> <4B16A0AE.2060908@gont.com.ar> <4B16A5F4.2010505@isi.edu> <4B16AB4C.4080501@gont.com.ar> In-Reply-To: <4B16AB4C.4080501@gont.com.ar> 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" , "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] closing WGLC 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: Wed, 02 Dec 2009 18:21:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Gont wrote: > Joe Touch wrote: > >>> This means it may recommend ignore ICMP hard errors (or, well, process >>> them as soft errors) >> That might be reasonable. >> >>> *and* implement PLPMTUD, >> We could note that this could be used, but I don't see us requiring >> something that heavyweight by default. > > I agree that PLPMTUD is heavyweight -- just proposed that as a > NIH-suggestion. > > I would argue that the mechanism described in the ICMP attacks I-D is > easy to implement (I did it myself), and unless you can interrupt the > packet flow, it is hard to tamper with (and is certainly better than > nothing, anyway). We can refer off to that doc; it'd be preferable if that were just "possible ways to deal with it" than normative (as a MUST). >>> or whatever. >> Can you be more specific? > > ignoring hard errors (or processing them as soft errors) *and* > implementing the PMTUD mitigation technique in the ICMP I-D is another > possibility. OK - we can refer off to that doc (presumably you mean Sec 7.2 of that I-D). > For the BGP-use case, one might argue that you could probably safely > ignores ICMP PTB that advertise a small MTU. I'm trying to recall where I saw that there might be a threshold for MTUs from PTBs that would be larger than 68. I think you're suggesting that BGP might declare that the min would need to be high enough to make routing to that node useful, right? We can note that as well. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksWsB8ACgkQE5f5cImnZrvpCgCfSPQC7wChpeiH2N2e5qKn5UwJ kOgAniQwyEZQUXpxsjeDARSVH6RMwJHu =NByY -----END PGP SIGNATURE----- From touch@ISI.EDU Wed Dec 2 10:57:33 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 5DF0D3A688A for ; Wed, 2 Dec 2009 10:57:33 -0800 (PST) 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 VoSmaL9ldm6Q for ; Wed, 2 Dec 2009 10:57:32 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id B279F3A6A34 for ; Wed, 2 Dec 2009 10:57:28 -0800 (PST) Received: from [75.213.146.151] (151.sub-75-213-146.myvzw.com [75.213.146.151]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nB2IueXG001753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Dec 2009 10:56:43 -0800 (PST) Message-ID: <4B16B868.5010104@isi.edu> Date: Wed, 02 Dec 2009 10:56:40 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Smith, Donald" References: <0C53DCFB700D144284A584F54711EC58087D6B17@xmb-sjc-21c.amer.cisco.com> <4B1620E8.4040503@isi.edu>, <0C53DCFB700D144284A584F54711EC58087D6B2F@xmb-sjc-21c.amer.cisco.com> <64751D63-8618-489B-BA02-EC2839053122@mimectl>, <4B1685F7.9060603@isi.edu> <7028E675-20AC-4874-9C2E-D3216BA8EF36@mimectl>, <4B16935B.2020209@isi.edu> , <4B16A4B2.7010809@isi.edu> 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" , "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] closing WGLC 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: Wed, 02 Dec 2009 18:57:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Donald, Please jump to the word "understand" below. I've responded linearly, but we need to get on the same page as to whether you're assuming the rebooted router reuses the port pair or not. If the ports are NOT reused, then there's a BGP issue to discuss. If they ARE reused, then I think we've already covered a useful and sufficient solution (TCP keepalives). Joe __________________________ > From: Joe Touch [touch@ISI.EDU] > Sent: Wednesday, December 02, 2009 10:32 AM > To: Smith, Donald > Cc: Anantha Ramaiah (ananth); tcpm@ietf.org > Subject: Re: [tcpm] closing WGLC for TCP-AO > >> > -----BEGIN PGP SIGNED MESSAGE----- >> > Hash: SHA1 >> > >> > >> > >> > Smith, Donald wrote: >> > ... >>>> > >> The kind of state that needs to be kept for TCP-AO may make this very >>>> > >> complicated. The rebooting host needs to establish new connections with >>>> > >> new traffic keys, but needs to allow the connection to be reset with old >>>> > >> traffic keys. >>> > > >>> > > Not quite, the rebooting host needs to be able to reset the old session to >>> >> its peers with the old keys. >>> > > It doesn't need it's old session reset. >> > >> > The state is at the non-rebooting side. > No the non-rebooting side still "thinks" it has a session with the restarting/rebooting peer. Right - that's why I said the state is at he non-rebooting side. > It is the rebooting side that needs to be able to send an > authenticated reset to terminate the old peering session. (this presumes BGP is trying to restart a connection with the same port pair - which it really shouldn't at least for 2*MSL, due to TIME_WAIT rules -- it can't know it wasn't in TIME_WAIT before the reboot). (if BGP is NOT restarting a connection with the old port pair, please ignore this and jump to "understand" below) Either side can send the RST and have that effect (presuming it's accepted). Consider two cases of the non-rebooting side, ignoring the effects of TCP-AO (i.e., a non-TCP-AO connection): 1) nonrebooter has data to send or keepalives set nonrebooter sends a segment rebooter receives a segment while not in ESTABLISHED rebooter returns a RST and clears out state 2) nonrebooter has no data AND keepalives is not set rebooter sends a SYN - if the SYN is in-window: non-rebooter sends a RST, clear out the state, goes to CLOSED either the RST is received by the rebooter: which clears out its state too or it's lost: the rebooter resends the SYN, which is handled correctly - if the SYN isn't in-window: the nonrebooter sends the ACK of the last data received, without the SYN set the rebooter receives the ACK in SYN-SENT state if in-window: this gets silently dropped because the SYN isn't set ** TO: this results in a timeout stall if not in-window: rebooter sends a RST and clears out state Note that many of these cause timeout problems (see "TO"). Let's consider what happens when TCP-AO is running and the keys are lost by the rebooter: 1) nonrebooter has data to send or keepalives set nonrebooter sends a segment rebooter silently discards the segment nonrebooter times out and flushes its connection locally 2) nonrebooter has no data AND keepalives is not set rebooter sends a SYN nonrebooter silently drops the SYN No forward progress So basically this is an issue only when keepalives are not set and when there is no data to send on the nonrebooter side. >> > When the rebooting side tries to connect, it will receive a RST back, >> > which will have the old keys and be ignored. > > No, when the rebooting side tries to connect (depending on if GR is enabled) you will see to different behaviors. > The rebooting router attempts to establish a new session. > The non-rebooting router allows that connection since this is a valid peer. I think I may understand better; I think you're assuming that: - new connections use new ports, thus they are NOT blocked by TCP-AO - the interference is at the BGP level due to multiple open connections to the same neighbor ID If that's correct, then we can proceed below. If not, then you're talking not only about keeping old keys, but keeping TCP connection state after a reboot. Otherwise, you'd never know which port pair to reuse. IMO, if you don't reuse the port pair, then you might have a BGP issue (but see below). If you do reuse the port pair, you should use TCP keepaliaves and it'll all work fine (as noted above). > The rebooting router sends an open msg with its neighbor ID. If using a different port pair, this would work. > The non-rebooting router sees that is already has that neighbor ID in > its data base and sends some type of msg usually a notify error msg. This depends on the keepalive time, but yes, if the nonrebooting side hasn't flushed the state this would happen. > They do a 3 or 4 way fin handshake to teardown the NEW session. Sounds like you want it to tear down the old session when this happens, not the new one. If you did, then the nonrebooting router would issue an ABORT, send a RST, and clear out its state. The rebooting router would ignore the RST because it wouldn't match keys. Everything would work fine at that point. ... >> > The only way the non-rebooting side would receive a RST would be because >> > it's still trying to send data, at which point TCP would time-out >> > anyway. As Ron noted - this can be adjusted with the hold-down timers. > > That is the issue. The reset will be sent by the rebooting router on > the first packet from the non-rebooting peer so at a minimum it will > reset based on the next keepalive packet/timer (usually a 1/3 of the > hold timer). So based on bcp's if you wait for the hold timer it will be > three times as long before a session can be established. So you're relying on the rebooting router to clear out the dup state at the nonrebooting one. That sounds like a poor implementation decision to me (though, IMO, there are numerous such problems with BGP, including relying on TCP connectivity to establish peering availability). What you want is new successful connections to *immediately* clear out old ones. Otherwise, let the old ones time out naturally if the other side isn't there. This way you recover more quickly when you can, and don't break things when you can't. I.e., this is an application TCP issue, not a TCP-AO issue. We could note it in TCP-AO, but it would be more useful to address in the KART WG, IMO. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksWuGcACgkQE5f5cImnZrsplwCg+2nQbj9TmyVqOFtm1wsSXqv9 IZkAoLUIJtckJa5lDa9wdHFltr4z7QsZ =Y18A -----END PGP SIGNATURE----- From fernando.gont.netbook.win@gmail.com Wed Dec 2 11:21: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 AB5CB3A6B20 for ; Wed, 2 Dec 2009 11:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.34 X-Spam-Level: X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[AWL=0.259, 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 R1u3Wo1gBJH7 for ; Wed, 2 Dec 2009 11:21:40 -0800 (PST) Received: from mail-yx0-f124.google.com (mail-yx0-f124.google.com [209.85.210.124]) by core3.amsl.com (Postfix) with ESMTP id C51793A6AE7 for ; Wed, 2 Dec 2009 11:21:38 -0800 (PST) Received: by yxe30 with SMTP id 30so120197yxe.29 for ; Wed, 02 Dec 2009 11:21:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=uaGWn5PRIvttBDCpWgcMFW8tXJ34TD9BwrZ6Lsg1doQ=; b=jQbmsvQceHiDjHBU1VqcJooji6BHFny1ekV8UA3LC+rEv8NpqPh+9R2QsHrRzrRMXU X9ExBY0kEfQdj+9r3idNesF6WWt7SNS3N/Ar1zFxc2hINeneckC138jM4I79xCcYcEyh kl6/tkcteeBtui5tdZF1BcYniSmZL/Z8dH3JU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=GsjY9TJNsHVfxlnIyoREJFZrF3gFrTsfhcF6SAJe8zMavQW1KT8qkAENtFEF796uBL UyE6KWJEKIWFOMrNa+OEslbghu0nk+M2Isatkx6bqNLkrxVknprM6LgEiwSyqnaisu21 vtbu2mCGkn1ohqupE5rITMQev7L0cTTppmRrc= Received: by 10.101.2.22 with SMTP id e22mr658862ani.145.1259781687539; Wed, 02 Dec 2009 11:21:27 -0800 (PST) Received: from ?192.168.0.168? (129-130-17-190.fibertel.com.ar [190.17.130.129]) by mx.google.com with ESMTPS id 4sm527757ywg.43.2009.12.02.11.21.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 02 Dec 2009 11:21:27 -0800 (PST) Sender: Fernando Gont Message-ID: <4B16BE2C.4040802@gont.com.ar> Date: Wed, 02 Dec 2009 16:21:16 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Joe Touch References: <0C53DCFB700D144284A584F54711EC58087D6B17@xmb-sjc-21c.amer.cisco.com>, <4B16734C.3050107@gont.com.ar> <4B16966E.2010107@gont.com.ar> <4B1699EB.8090608@isi.edu> <4B16A0AE.2060908@gont.com.ar> <4B16A5F4.2010505@isi.edu> <4B16AB4C.4080501@gont.com.ar> <4B16B01F.9030404@isi.edu> In-Reply-To: <4B16B01F.9030404@isi.edu> X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" , "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] closing WGLC 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: Wed, 02 Dec 2009 19:21:41 -0000 Joe Touch wrote: >> I would argue that the mechanism described in the ICMP attacks I-D is >> easy to implement (I did it myself), and unless you can interrupt the >> packet flow, it is hard to tamper with (and is certainly better than >> nothing, anyway). > > We can refer off to that doc; it'd be preferable if that were just > "possible ways to deal with it" than normative (as a MUST). "MUST" would be too much. But I think it deserves a SHOULD. If not the particular mitigation, at least "some" mitigation. > >>>> or whatever. >>> Can you be more specific? >> ignoring hard errors (or processing them as soft errors) *and* >> implementing the PMTUD mitigation technique in the ICMP I-D is another >> possibility. > > OK - we can refer off to that doc (presumably you mean Sec 7.2 of that I-D). Yes, Section 7.2 >> For the BGP-use case, one might argue that you could probably safely >> ignores ICMP PTB that advertise a small MTU. > > I'm trying to recall where I saw that there might be a threshold for > MTUs from PTBs that would be larger than 68. Some systems (e.g. OpenBSD) enforce a minimum MTU of 296 for he general case (it is hardcoded in the stack). For the BGP scenario, my take is that this thershold could be raised much more. > I think you're suggesting that BGP might declare that the min would need > to be high enough to make routing to that node useful, right? We can > note that as well. Not just useful: are there any BGP peers with an MTU of, say, 600 bytes? (i.e., does that really happen in practice) 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 Dec 2 11:39: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 843FA3A6978 for ; Wed, 2 Dec 2009 11:39:43 -0800 (PST) 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 lLzsFVjHH+Ho for ; Wed, 2 Dec 2009 11:39:42 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id A4C663A6969 for ; Wed, 2 Dec 2009 11:39:42 -0800 (PST) Received: from [75.213.146.151] (151.sub-75-213-146.myvzw.com [75.213.146.151]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nB2JcSas015795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Dec 2009 11:38:31 -0800 (PST) Message-ID: <4B16C234.4040806@isi.edu> Date: Wed, 02 Dec 2009 11:38:28 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Fernando Gont References: <0C53DCFB700D144284A584F54711EC58087D6B17@xmb-sjc-21c.amer.cisco.com>, <4B16734C.3050107@gont.com.ar> <4B16966E.2010107@gont.com.ar> <4B1699EB.8090608@isi.edu> <4B16A0AE.2060908@gont.com.ar> <4B16A5F4.2010505@isi.edu> <4B16AB4C.4080501@gont.com.ar> <4B16B01F.9030404@isi.edu> <4B16BE2C.4040802@gont.com.ar> In-Reply-To: <4B16BE2C.4040802@gont.com.ar> 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" , "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] closing WGLC 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: Wed, 02 Dec 2009 19:39:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Gont wrote: > Joe Touch wrote: > >>> I would argue that the mechanism described in the ICMP attacks I-D is >>> easy to implement (I did it myself), and unless you can interrupt the >>> packet flow, it is hard to tamper with (and is certainly better than >>> nothing, anyway). >> We can refer off to that doc; it'd be preferable if that were just >> "possible ways to deal with it" than normative (as a MUST). > > "MUST" would be too much. But I think it deserves a SHOULD. If not the > particular mitigation, at least "some" mitigation. So there are several parts: - ignore certain hard ICMPs (as already listed) MUST be able to ignore MUST be configurable MUST be defaulted to ON ? - consider additional mechanisms for ICMP PTB I don't know if we can go much beyond "consider", though. Even SHOULD would be normative, and it's not described in a way that is really normative. I don't know what we would put after SHOULD, i.e., - SHOULD what, exactly? ... >>> For the BGP-use case, one might argue that you could probably safely >>> ignores ICMP PTB that advertise a small MTU. >> I'm trying to recall where I saw that there might be a threshold for >> MTUs from PTBs that would be larger than 68. > > Some systems (e.g. OpenBSD) enforce a minimum MTU of 296 for he general > case (it is hardcoded in the stack). > > For the BGP scenario, my take is that this thershold could be raised > much more. If we did have a threshold, I can't see why it would be much higher than 296. The impact of packets that small, vs., e.g., 576, isn't all that bad. >> I think you're suggesting that BGP might declare that the min would need >> to be high enough to make routing to that node useful, right? We can >> note that as well. > > Not just useful: are there any BGP peers with an MTU of, say, 600 bytes? > (i.e., does that really happen in practice) I don't know, but I can't see why BGP should care (vs., e.g., 1500?) Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksWwjQACgkQE5f5cImnZrviPgCg1KSl6J0mKDenaucEP9WF6CD7 96AAoJqIMsmhcixrQ/U1V+o0M+KfxWDu =hcV5 -----END PGP SIGNATURE----- From Donald.Smith@qwest.com Wed Dec 2 13:19: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 27D8F3A6912 for ; Wed, 2 Dec 2009 13:19:17 -0800 (PST) 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 XJa-8Edb5Kgf for ; Wed, 2 Dec 2009 13:19:15 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id 54FBA3A68B5 for ; Wed, 2 Dec 2009 13:19:15 -0800 (PST) Received: from suomp61i.qintra.com (suomp61i.qintra.com [151.117.69.28]) by suomp64i.qwest.com (8.14.0/8.14.0) with ESMTP id nB2LIe6g027880; Wed, 2 Dec 2009 15:18:41 -0600 (CST) Received: from qtdenexhtm22.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.0/8.14.0) with ESMTP id nB2LIZmN026269; Wed, 2 Dec 2009 15:18:35 -0600 (CST) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm22.AD.QINTRA.COM ([151.119.91.231]) with mapi; Wed, 2 Dec 2009 14:18:35 -0700 From: "Smith, Donald" To: Joe Touch Content-Class: urn:content-classes:message Date: Wed, 2 Dec 2009 14:18:26 -0700 Thread-Topic: [tcpm] closing WGLC for TCP-AO Thread-Index: AcpzgUhIsRT1rg6BTwit9jQ9GAMdyQADKJ1mAAHEXeE= Message-ID: References: <0C53DCFB700D144284A584F54711EC58087D6B17@xmb-sjc-21c.amer.cisco.com> <4B1620E8.4040503@isi.edu>, <0C53DCFB700D144284A584F54711EC58087D6B2F@xmb-sjc-21c.amer.cisco.com> <64751D63-8618-489B-BA02-EC2839053122@mimectl>, <4B1685F7.9060603@isi.edu> <7028E675-20AC-4874-9C2E-D3216BA8EF36@mimectl>, <4B16935B.2020209@isi.edu> , <4B16A4B2.7010809@isi.edu> , <4B16B868.5010104@isi.edu> In-Reply-To: <4B16B868.5010104@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-mimectl: Produced By Microsoft Exchange V8.1.348.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" , "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] closing WGLC 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: Wed, 02 Dec 2009 21:19:17 -0000 (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com ________________________________ From: Joe Touch [touch@ISI.EDU] Sent: Wednesday, December 02, 2009 11:56 AM To: Smith, Donald Cc: Anantha Ramaiah (ananth); tcpm@ietf.org Subject: Re: [tcpm] closing WGLC for TCP-AO > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Donald, > > Please jump to the word "understand" below. > > I've responded linearly, but we need to get on the same page as to > whether you're assuming the rebooted router reuses the port pair or not. Yes, I realize now you assumed port reuse and I was not assuming that. That explains part of our misunderstanding. > > If the ports are NOT reused, then there's a BGP issue to discuss. > > If they ARE reused, then I think we've already covered a useful and > sufficient solution (TCP keepalives). Application specific KAs which are normally fairly long. > > Joe > __________________________ > > From: Joe Touch [touch@ISI.EDU] > > Sent: Wednesday, December 02, 2009 10:32 AM > > To: Smith, Donald > > Cc: Anantha Ramaiah (ananth); tcpm@ietf.org > > Subject: Re: [tcpm] closing WGLC for TCP-AO > > > >> > -----BEGIN PGP SIGNED MESSAGE----- > >> > Hash: SHA1 > >> > > >> > > >> > > >> > Smith, Donald wrote: > >> > ... > >>>> > >> The kind of state that needs to be kept for TCP-AO may make thi= s >>>>>>>>> very > >>>> > >> complicated. The rebooting host needs to establish new >>>>>>>>> connections with > >>>> > >> new traffic keys, but needs to allow the connection to be >>>>>>>>> reset with old > >>>> > >> traffic keys. > >>> > > > >>> > > Not quite, the rebooting host needs to be able to reset the >>>>>>> old session to > >>> >> its peers with the old keys. > >>> > > It doesn't need it's old session reset. > >> > > >> > The state is at the non-rebooting side. > > No the non-rebooting side still "thinks" it has a session >> with the restarting/rebooting peer. > > Right - that's why I said the state is at he non-rebooting side. > > > It is the rebooting side that needs to be able to send an > > authenticated reset to terminate the old peering session. > > (this presumes BGP is trying to restart a connection with the same port > pair - which it really shouldn't at least for 2*MSL, due to TIME_WAIT > rules -- it can't know it wasn't in TIME_WAIT before the reboot). > > (if BGP is NOT restarting a connection with the old port pair, please > ignore this and jump to "understand" below) > > Either side can send the RST and have that effect (presuming it's > accepted). > > Consider two cases of the non-rebooting side, ignoring the effects of > TCP-AO (i.e., a non-TCP-AO connection): > > 1) nonrebooter has data to send or keepalives set > > nonrebooter sends a segment > > rebooter receives a segment while not in ESTABLISHED > > rebooter returns a RST and clears out state > > 2) nonrebooter has no data AND keepalives is not set > > rebooter sends a SYN > > - if the SYN is in-window: > > non-rebooter sends a RST, clear out the state, > goes to CLOSED > > either the RST is received by the rebooter: > > which clears out its state too > > or it's lost: > > the rebooter resends the SYN, > which is handled correctly > > - if the SYN isn't in-window: > > the nonrebooter sends the ACK of the last > data received, without the SYN set > > the rebooter receives the ACK in SYN-SENT state > if in-window: > > this gets silently dropped because > the SYN isn't set > ** TO: this results in a timeout stall > > if not in-window: > > rebooter sends a RST and clears out state > > Note that many of these cause timeout problems (see "TO"). > > Let's consider what happens when TCP-AO is running and the keys are lost > by the rebooter: > > 1) nonrebooter has data to send or keepalives set > > nonrebooter sends a segment > > rebooter silently discards the segment > > nonrebooter times out and flushes its connection locally > > 2) nonrebooter has no data AND keepalives is not set > > rebooter sends a SYN > > nonrebooter silently drops the SYN > > No forward progress > > So basically this is an issue only when keepalives are not set and when > there is no data to send on the nonrebooter side. > > >> > When the rebooting side tries to connect, it will receive a RST back= , > >> > which will have the old keys and be ignored. > > > > No, when the rebooting side tries to connect > > (depending on if GR is enabled) you will see to different behaviors. > > The rebooting router attempts to establish a new session. > > The non-rebooting router allows that connection since this is a valid p= eer. > > I think I may understand better; I think you're assuming that: > > - new connections use new ports, thus they are NOT blocked > by TCP-AO correct. > > - the interference is at the BGP level due to multiple open > connections to the same neighbor ID Correct. > > If that's correct, then we can proceed below. If not, then you're > talking not only about keeping old keys, but keeping TCP connection > state after a reboot. Otherwise, you'd never know which port pair to reus= e. > > IMO, if you don't reuse the port pair, then you might have a BGP issue > (but see below). > > If you do reuse the port pair, you should use TCP keepaliaves and it'll > all work fine (as noted above). > > > The rebooting router sends an open msg with its neighbor ID. > > If using a different port pair, this would work. It works from the standpoint of that a new bgp session can be established. It doesn't work from the single session bgp standpoint. > > > The non-rebooting router sees that is already has that neighbor ID in > > its data base and sends some type of msg usually a notify error msg. > > This depends on the keepalive time, but yes, if the nonrebooting side > hasn't flushed the state this would happen. If GraceFull restart is enabled a new session attempt should trigger tear d= own of the previous session. At least one implementation I have worked on did n= ot preform that way:( > > > They do a 3 or 4 way fin handshake to teardown the NEW session. > > Sounds like you want it to tear down the old session when this happens, > not the new one. Correct per rfc4724 "4.2. Procedures for the Receiving Speaker When the Restarting Speaker rest= arts, the Receiving Speaker may or may not detect the termination of the TC= P session with the Restarting Speaker, depending on the underlying TCP impl= ementation, whether or not [BGP-AUTH] is in use, and the specific circumsta= nces of the restart. In case it does not detect the termination of the old = TCP session and still considers the BGP session as being established, it MU= ST treat the subsequent open connection from the peer as an indication of t= he termination of the old TCP session and act accordingly (when the Gracefu= l Restart Capability has been received from the peer). See Section 8 for a = description of this behavior in terms of the BGP finite state machine. Read more: http://www.faqs.org/rfcs/rfc4724.html#ixzz0YZAF2SIr" >If you did, then the nonrebooting router would issue an > ABORT, send a RST, and clear out its state. The ABORT won't work the rebooting router doesn't have a bgp session with the non-rebooting router (anymore). That would require a LOT more state to make work;) The rst will probably also be ignored but that is ok. As long as the nonrebooting router kills its session and drops the router ID. >The rebooting router would > ignore the RST because it wouldn't match keys. Everything would work > fine at that point. It will ignore the reset because it didn't reuse the src/dst ports. > > ... > >> > The only way the non-rebooting side would receive a RST would be bec= ause > >> > it's still trying to send data, at which point TCP would time-out > >> > anyway. As Ron noted - this can be adjusted with the hold-down timer= s. > > > > That is the issue. The reset will be sent by the rebooting router on > > the first packet from the non-rebooting peer so at a minimum it will > > reset based on the next keepalive packet/timer (usually a 1/3 of the > > hold timer). So based on bcp's if you wait for the hold timer it will b= e > > three times as long before a session can be established. > > So you're relying on the rebooting router to clear out the dup state at > the nonrebooting one. To signal that the nonrebooting router should clear the "dup" state. > > That sounds like a poor implementation decision to me (though, IMO, > there are numerous such problems with BGP, including relying on TCP > connectivity to establish peering availability). > > What you want is new successful connections to *immediately* clear out > old ones. Yes and that is the expected behavior for GR enabled bgp sessions. It is NOT for non-GR enabled bgp sessions. Without GR single session bgp will have to wait for the hold time to expire before reestablishing an new = session. So an authenticated reset would still be helpful in that case. >Otherwise, let the old ones time out naturally if the other > side isn't there. Yes based on hold time and possible other timers. > > This way you recover more quickly when you can, and don't break things > when you can't. > > I.e., this is an application TCP issue, not a TCP-AO issue. We could > note it in TCP-AO, but it would be more useful to address in the KART > WG, IMO. I see where your headed but AFAIK most tcp-auth implementations were specif= icly implemented for BGP. They were 'pushed' out due to blindly spoofed tcp reset within win= dow issue identified by Gont. So in my opinion a tcp-auth or tcp-ao rfc that doesn't address issues with = bgp is less valuable then one that does. Additionally if a router or any device with multiple cpus wanted to do subm= inute HA failover the ability to reuse the previous session would require this type of state be maintained so that KA's or other bgp msgs could be could be responded to with valid authentication. Although I have been using bgp as the main long lived tcp session here that= is because I am familar with bgp. Other long lived tcp sessions would also benefit from thi= s ability. > > Joe > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > > iEYEARECAAYFAksWuGcACgkQE5f5cImnZrsplwCg+2nQbj9TmyVqOFtm1wsSXqv9 > IZkAoLUIJtckJa5lDa9wdHFltr4z7QsZ > =3DY18A > -----END PGP SIGNATURE----- ________________________________ This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From karthikbalaguru79@gmail.com Wed Dec 2 13:27: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 089543A691B for ; Wed, 2 Dec 2009 13:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=0.248, 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 Dg1KlLQabfK5 for ; Wed, 2 Dec 2009 13:27:44 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 527BB3A6912 for ; Wed, 2 Dec 2009 13:27:44 -0800 (PST) Received: by pwi19 with SMTP id 19so503920pwi.29 for ; Wed, 02 Dec 2009 13:27:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=nPbNw6Mo9BLt9Q0CTE47IS4KZKHLuAGNnmff2qwcats=; b=dr6pEema5zDe+8EwzThaVUay1WCXxtnZAV29aleDS2L0W9iS45EH3/S1eAX8LrNW8/ R+lzV8XCRBeV/m1+/I3Vjobn/G+yHvZp2X42+aCtd6mzd6epkP+vtSLeH7XpDdw/vNCd pf6Q4bw0Kh3+WUJfgUHmqlu4mHUG7P5yPd+DI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=LnjoRDirJswslXcYWqjlUaIcu1AvRNH5B4jsglT88lny5NCgZPXHAQ9uHpeqel16PO moJRxSjqQh4bidpOYZkbahf0GQP9zs2XCKEKYE1TTf8+eK9atExBfbv9mtGzJvOxwdG1 MUWCKi8sWCg0PW/3rrJ/mGjCXPIIL+zmbNvi8= MIME-Version: 1.0 Received: by 10.142.9.39 with SMTP id 39mr77060wfi.115.1259789251637; Wed, 02 Dec 2009 13:27:31 -0800 (PST) Date: Thu, 3 Dec 2009 02:57:31 +0530 Message-ID: <53b627ea0912021327t4a929b51va6c16a2a8f5b5d67@mail.gmail.com> From: Karthik Balaguru To: tcpm@ietf.org Content-Type: multipart/alternative; boundary=00504502b45fd5f1c10479c58a35 Subject: [tcpm] Regd TCP SACK Option X-BeenThere: tcpm@ietf.org X-Mailman-Version: 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, 02 Dec 2009 21:27:45 -0000 --00504502b45fd5f1c10479c58a35 Content-Type: text/plain; charset=ISO-8859-1 Hi, With selective acknowledgments, the data receiver can inform the sender about all segments that have arrived successfully, so the sender need retransmit only the segments that have actually been lost. Selective Acknowledgment (SACK) is a strategy which corrects this behavior in the face of multiple dropped segments. But, what is the number of segments to be dropped so that the SACK option will be sent ? Does it depend on any other factor ? In simple terms, Need to know the various triggers that will send the SACK option that can inform the sender to retransmit the lost segments alone. Thx in advans, Karthik Balaguru --00504502b45fd5f1c10479c58a35 Content-Type: text/html; charset=ISO-8859-1

Hi,
With selective acknowledgments, the data receiver
can inform the sender about all segments that have
arrived successfully, so the sender need retransmit
only the segments that have actually been lost.
Selective Acknowledgment (SACK) is a strategy
which corrects this behavior in the face of multiple
dropped segments.

But, what is the number of segments to be
dropped so that the SACK option will be sent ?
Does it depend on any other factor ?

In simple terms, Need to know the various triggers
that will send the SACK option that can inform the
sender to retransmit the lost segments alone.

Thx in advans,
Karthik Balaguru

--00504502b45fd5f1c10479c58a35-- From touch@ISI.EDU Wed Dec 2 15:20: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 4ACC43A692B for ; Wed, 2 Dec 2009 15:20:14 -0800 (PST) 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 ijYxrkIZWGdr for ; Wed, 2 Dec 2009 15:20:13 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id E5FA43A6974 for ; Wed, 2 Dec 2009 15:20:12 -0800 (PST) Received: from [75.213.146.151] (151.sub-75-213-146.myvzw.com [75.213.146.151]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nB2NJKLQ019947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Dec 2009 15:19:24 -0800 (PST) Message-ID: <4B16F5F6.6060303@isi.edu> Date: Wed, 02 Dec 2009 15:19:18 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Smith, Donald" References: <0C53DCFB700D144284A584F54711EC58087D6B17@xmb-sjc-21c.amer.cisco.com> <4B1620E8.4040503@isi.edu>, <0C53DCFB700D144284A584F54711EC58087D6B2F@xmb-sjc-21c.amer.cisco.com> <64751D63-8618-489B-BA02-EC2839053122@mimectl>, <4B1685F7.9060603@isi.edu> <7028E675-20AC-4874-9C2E-D3216BA8EF36@mimectl>, <4B16935B.2020209@isi.edu> , <4B16A4B2.7010809@isi.edu> , <4B16B868.5010104@isi.edu> 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" , "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] closing WGLC 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: Wed, 02 Dec 2009 23:20:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> > If using a different port pair, this would work. > It works from the standpoint of that a new bgp session can be established. > It doesn't work from the single session bgp standpoint. > >> > >>> > > The non-rebooting router sees that is already has that neighbor ID in >>> > > its data base and sends some type of msg usually a notify error msg. >> > >> > This depends on the keepalive time, but yes, if the nonrebooting side >> > hasn't flushed the state this would happen. > > > > If GraceFull restart is enabled a new session attempt should trigger tear down > of the previous session. At least one implementation I have worked on did not > preform that way:( So it seems like graceful restart is what you want, and it's already specified. Would it be sufficient to note this? >>> > > They do a 3 or 4 way fin handshake to teardown the NEW session. >> > >> > Sounds like you want it to tear down the old session when this happens, >> > not the new one. > Correct per rfc4724 > "4.2. Procedures for the Receiving Speaker When the Restarting Speaker restarts, the Receiving Speaker may or may not detect the termination of the TCP session with the Restarting Speaker, depending on the underlying TCP implementation, whether or not [BGP-AUTH] is in use, and the specific circumstances of the restart. In case it does not detect the termination of the old TCP session and still considers the BGP session as being established, it MUST treat the subsequent open connection from the peer as an indication of the termination of the old TCP session and act accordingly (when the Graceful Restart Capability has been received from the peer). See Section 8 for a description of this behavior in terms of the BGP finite state machine. > > Read more: http://www.faqs.org/rfcs/rfc4724.html#ixzz0YZAF2SIr" > >> >If you did, then the nonrebooting router would issue an >> > ABORT, send a RST, and clear out its state. > > The ABORT won't work the rebooting router doesn't have > a bgp session with the non-rebooting router (anymore). I was suggesting the nonrebooting router do the ABORT, not the rebooting one. RFC4724 just says "close", so if that's sufficient, that's fine. ... >> > That sounds like a poor implementation decision to me (though, IMO, >> > there are numerous such problems with BGP, including relying on TCP >> > connectivity to establish peering availability). >> > >> > What you want is new successful connections to *immediately* clear out >> > old ones. > > Yes and that is the expected behavior for GR enabled bgp sessions. > It is NOT for non-GR enabled bgp sessions. Without GR single session bgp > will have to wait for the hold time to expire before reestablishing an new session. > So an authenticated reset would still be helpful in that case. I don't see why the transport layer should be augmented to solve a problem for which a standards-track solution is already available at the application layer, and which makes sufficient sense. ... >> > I.e., this is an application TCP issue, not a TCP-AO issue. We could >> > note it in TCP-AO, but it would be more useful to address in the KART >> > WG, IMO. > > > I see where your headed but AFAIK most tcp-auth implementations were specificly implemented > for BGP. They were 'pushed' out due to blindly spoofed tcp reset within window issue identified by Gont. The issue was identified by Convery and Franz in 2003 - see RFC-4953. > So in my opinion a tcp-auth or tcp-ao rfc that doesn't address issues with bgp is less valuable then > one that does. Fair enough - but IMO that argues for MUST/SHOULD graceful restart, rather than including additional requirements for implementations to recover state after reboot. > Additionally if a router or any device with multiple cpus wanted to do subminute > HA failover the ability to reuse the previous session would > require this type of state be maintained so that KA's or other bgp > msgs could be could be responded to with valid authentication. I'm not sure I follow. You appear to be implying that multiple CPUs are used without a single view of the connection state of the machine - accessible across all CPUs. If that view isn't supported , you have more problems than just TCP-AO. > Although I have been using bgp as the main long lived tcp session here that is because I am > familar with bgp. Other long lived tcp sessions would also benefit from this ability. It is BGP that is erroneously using TCP connectivity as a liveness indicator, and that prefers a nonfunctioning previous connection to a functioning new connection. I don't see why this doc needs to warn against that sort of incorrect application semantics. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksW9fYACgkQE5f5cImnZrsYVgCffHY61wXtDyH5h9U1m+mFQPgg dg8An3ffLIGDJj9au7YWampBfVPZFlOU =v9kV -----END PGP SIGNATURE----- From ekr@networkresonance.com Wed Dec 2 19:26:29 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 CD18628C106 for ; Wed, 2 Dec 2009 19:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.049 X-Spam-Level: X-Spam-Status: No, score=0.049 tagged_above=-999 required=5 tests=[AWL=0.031, 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 hsjw35-fSiVT for ; Wed, 2 Dec 2009 19:26:29 -0800 (PST) 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 283913A6883 for ; Wed, 2 Dec 2009 19:26:29 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 3F7B86C489B; Wed, 2 Dec 2009 19:27:38 -0800 (PST) Date: Wed, 02 Dec 2009 19:27:37 -0800 From: Eric Rescorla To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" 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: <20091203032738.3F7B86C489B@kilo.networkresonance.com> Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] closing WGLC 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: Thu, 03 Dec 2009 03:26:29 -0000 At Tue, 1 Dec 2009 15:42:11 -0600, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote: > > The period for the working group last call on the AO documents > has passed. I didn't see any major issues that were identified. > Even though the response was light, given the large amount of > discussion that's gone into it to reach this point, I think this > is okay to proceed; we'll write the PROTO statements if the > authors can rev the drafts based on any feedback they got. > > One additional question that was open was whether the NAT draft > of Joe's should be rolled in. Since several people supported > this, and none were against it, I think Joe should go ahead and > include it before it gets sent to the IESG. Sorry, I've been pretty swamped and didn't get to this in time. That said, I don't think that NAT should be added. I haven't read the most recent version but don't remember being impressed with the initial drafts I saw. -Ekr From touch@ISI.EDU Wed Dec 2 19:37:20 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 B30C128C10F for ; Wed, 2 Dec 2009 19:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=-0.035, 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 gV0Y0I5NpAXw for ; Wed, 2 Dec 2009 19:37:20 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 0734328C11D for ; Wed, 2 Dec 2009 19:37:20 -0800 (PST) Received: from [192.168.1.43] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nB33aY8b001683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Dec 2009 19:36:36 -0800 (PST) Message-ID: <4B173242.1010709@isi.edu> Date: Wed, 02 Dec 2009 19:36:34 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Eric Rescorla References: <20091203032738.3F7B86C489B@kilo.networkresonance.com> In-Reply-To: <20091203032738.3F7B86C489B@kilo.networkresonance.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] closing WGLC 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: Thu, 03 Dec 2009 03:37:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Rescorla wrote: > At Tue, 1 Dec 2009 15:42:11 -0600, > Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote: >> The period for the working group last call on the AO documents >> has passed. I didn't see any major issues that were identified. >> Even though the response was light, given the large amount of >> discussion that's gone into it to reach this point, I think this >> is okay to proceed; we'll write the PROTO statements if the >> authors can rev the drafts based on any feedback they got. >> >> One additional question that was open was whether the NAT draft >> of Joe's should be rolled in. Since several people supported >> this, and none were against it, I think Joe should go ahead and >> include it before it gets sent to the IESG. > > Sorry, I've been pretty swamped and didn't get to this in time. > > That said, I don't think that NAT should be added. I haven't > read the most recent version but don't remember being impressed > with the initial drafts I saw. A comment based on the draft, which has been available for over 6 weeks and contains only 2 pages of content, would be useful if possible. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksXMkIACgkQE5f5cImnZrttQACdHC74n+6rsFKa6Bv3vzc2iHQd 9QAAnAw52aAfOyfHjVm4jFoLcdw/m3j7 =n+Pl -----END PGP SIGNATURE----- From touch@ISI.EDU Wed Dec 2 19:37: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 0E60B28C126 for ; Wed, 2 Dec 2009 19:37:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[AWL=-0.034, 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 sb2-bCtqI+w7 for ; Wed, 2 Dec 2009 19:37:42 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 4BBAA28C118 for ; Wed, 2 Dec 2009 19:37:42 -0800 (PST) Received: from [192.168.1.43] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nB33bKBu001890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Dec 2009 19:37:22 -0800 (PST) Message-ID: <4B173270.70403@isi.edu> Date: Wed, 02 Dec 2009 19:37:20 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Eric Rescorla References: <20091203032738.3F7B86C489B@kilo.networkresonance.com> In-Reply-To: <20091203032738.3F7B86C489B@kilo.networkresonance.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] closing WGLC 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: Thu, 03 Dec 2009 03:37:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Rescorla wrote: ... > That said, I don't think that NAT should be added. I haven't > read the most recent version but don't remember being impressed > with the initial drafts I saw. Also, it would be useful if you could raise a substantive concern to accompany your impression. ;-) Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksXMnAACgkQE5f5cImnZrscrwCggUu5ffqIG3XcH+FkCrzTMUZl b6MAoNcekXCWyTKsyVHtGl5GWgxnHn7w =Haec -----END PGP SIGNATURE----- From ekr@networkresonance.com Wed Dec 2 21:05: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 0FAEF3A68BA for ; Wed, 2 Dec 2009 21:05:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.048 X-Spam-Level: X-Spam-Status: No, score=0.048 tagged_above=-999 required=5 tests=[AWL=0.030, 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 2Xr8kyL2Ju9f for ; Wed, 2 Dec 2009 21:05:43 -0800 (PST) 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 52F1D3A687E for ; Wed, 2 Dec 2009 21:05:43 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 585F86C495F; Wed, 2 Dec 2009 21:06:52 -0800 (PST) Date: Wed, 02 Dec 2009 21:06:51 -0800 From: Eric Rescorla To: Joe Touch In-Reply-To: <4B173270.70403@isi.edu> References: <20091203032738.3F7B86C489B@kilo.networkresonance.com> <4B173270.70403@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: <20091203050652.585F86C495F@kilo.networkresonance.com> Cc: "tcpm@ietf.org" Subject: Re: [tcpm] closing WGLC 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: Thu, 03 Dec 2009 05:05:44 -0000 At Wed, 02 Dec 2009 19:37:20 -0800, Joe Touch wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Eric Rescorla wrote: > ... > > That said, I don't think that NAT should be added. I haven't > > read the most recent version but don't remember being impressed > > with the initial drafts I saw. > > Also, it would be useful if you could raise a substantive concern to > accompany your impression. ;-) Yes, I'll send comments on it once I have a chance to read it and write some. If you prefer, I can of course just raise any issues in IETF LC, but I thought people might appreciate a heads-up that I likely wasn't in favor. -Ekr From touch@ISI.EDU Wed Dec 2 21:37: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 2299E3A68CD for ; Wed, 2 Dec 2009 21:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=-0.033, 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 TRX6s1K22+qk for ; Wed, 2 Dec 2009 21:37:45 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 39B543A68B0 for ; Wed, 2 Dec 2009 21:37:45 -0800 (PST) Received: from [192.168.1.43] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nB35bMEj003473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Dec 2009 21:37:24 -0800 (PST) Message-ID: <4B174E92.2030702@isi.edu> Date: Wed, 02 Dec 2009 21:37:22 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Eric Rescorla References: <20091203032738.3F7B86C489B@kilo.networkresonance.com> <4B173270.70403@isi.edu> <20091203050652.585F86C495F@kilo.networkresonance.com> In-Reply-To: <20091203050652.585F86C495F@kilo.networkresonance.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] closing WGLC 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: Thu, 03 Dec 2009 05:37:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Rescorla wrote: > At Wed, 02 Dec 2009 19:37:20 -0800, > Joe Touch wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> >> Eric Rescorla wrote: >> ... >>> That said, I don't think that NAT should be added. I haven't >>> read the most recent version but don't remember being impressed >>> with the initial drafts I saw. >> Also, it would be useful if you could raise a substantive concern to >> accompany your impression. ;-) > > Yes, I'll send comments on it once I have a chance to read it and > write some. If you prefer, I can of course just raise any issues > in IETF LC, but I thought people might appreciate a heads-up that > I likely wasn't in favor. It's great that you have such a well formed uninformed position. Feel free to comment when your ready, whenever that is. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksXTpEACgkQE5f5cImnZrvNswCgoE2Iybppufcrzelh2XU7dP9Q siYAoIOag8tGzI1VOTPXG+mJHFrHhFLV =SUkn -----END PGP SIGNATURE----- From achandra@cisco.com Wed Dec 2 21:50: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 80D2E28C0D8 for ; Wed, 2 Dec 2009 21:50:45 -0800 (PST) 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 XGxHGeWys-98 for ; Wed, 2 Dec 2009 21:50:44 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 991FC28C0D6 for ; Wed, 2 Dec 2009 21:50:44 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJLgFkurR7H+/2dsb2JhbAC/VJdvhDEEgWo X-IronPort-AV: E=Sophos;i="4.47,332,1257120000"; d="scan'208";a="56936232" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 03 Dec 2009 05:50:36 +0000 Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nB35oaOW012302; Thu, 3 Dec 2009 05:50:36 GMT Received: (from achandra@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id VAA19696; Wed, 2 Dec 2009 21:49:45 -0800 (PST) Date: Wed, 2 Dec 2009 21:49:45 -0800 From: Chandrashekhar Appanna To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" Message-ID: <20091203054945.GE15658@cisco.com> References: <4B16734C.3050107@gont.com.ar> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Cc: "tcpm@ietf.org" , "Anantha Ramaiah \(ananth\)" , Fernando Gont , Joe Touch Subject: Re: [tcpm] closing WGLC 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: Thu, 03 Dec 2009 05:50:45 -0000 On Wed, Dec 02, 2009 at 08:39:10AM -0600, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote: > There's a big difference between documents that authors think are ready for WGLC but have only seen light discussion in the WG, and documents that have been extensively discussed in hundreds of mail-list posts and hours of WG face-to-face meeting time and other high-bandwidth offline discussion. > > Early retransmit was a good example of the first case; the document was basically done, but we couldn't tell if the WG had read it sufficiently, so the WGLC got extended until we had that confidence. > > AO is an example of the second case; it's benefited from very long sesssions in some of our meetings (Dublin, Minneapolis, San Francisco, etc), and the mailing list traffic attests that a lot of people have read it, raised their issues, and had them addressed in document updates. In this case, the consensus seemed to be formed well before the WGLC, making it more of a "speak now or forever hold your peace" moment, rather than an attempt to make sure sufficient review had been obtained. > > I hope this clears things up for those of you who think this is odd. It's not :). > > The entire process asociated with this draft has been very odd.. on all fronts it has shown exactly how the IETF should not do things. The fact that one vocal and nagging individual can usurp and upset the effort and the ideas that originated with others was definitely odd to me.. I do not intend to debate or argue but since this is an open forum and opnions are being stated, I want to put mine in for the record too. 0.02 :) Chandra. > ________________________________________ > From: Fernando Gont [fernando.gont.netbook.win@gmail.com] On Behalf Of Fernando Gont [fernando@gont.com.ar] > Sent: Wednesday, December 02, 2009 9:01 AM > To: Anantha Ramaiah (ananth) > Cc: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; tcpm@ietf.org; Joe Touch > Subject: Re: [tcpm] closing WGLC for TCP-AO > > Anantha Ramaiah (ananth) wrote: > > > Maybe I missing something here, I haven't seen any responses for this > > WGLC, typically if that is the case, I have seen the urge to ask folks > > to read and even they don't have any comments "I have read it, it is > > fine". No such thing seem to have happened for this case. May be I > > missed some responses. > > +1 > > Kind regards, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From ekr@networkresonance.com Thu Dec 3 09:35: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 2388828C154 for ; Thu, 3 Dec 2009 09:35:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.895 X-Spam-Level: X-Spam-Status: No, score=0.895 tagged_above=-999 required=5 tests=[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, 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 thEMCupDQZm9 for ; Thu, 3 Dec 2009 09:35:00 -0800 (PST) Received: from kilo.networkresonance.com (216.156.83.78.ptr.us.xo.net [216.156.83.78]) by core3.amsl.com (Postfix) with ESMTP id 30A333A6801 for ; Thu, 3 Dec 2009 09:35:00 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 9C20A6C49F7; Thu, 3 Dec 2009 09:36:12 -0800 (PST) Date: Thu, 03 Dec 2009 09:36:12 -0800 From: Eric Rescorla To: Joe Touch In-Reply-To: <4B174E92.2030702@isi.edu> References: <20091203032738.3F7B86C489B@kilo.networkresonance.com> <4B173270.70403@isi.edu> <20091203050652.585F86C495F@kilo.networkresonance.com> <4B174E92.2030702@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: <20091203173612.9C20A6C49F7@kilo.networkresonance.com> Cc: "tcpm@ietf.org" Subject: Re: [tcpm] closing WGLC 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: Thu, 03 Dec 2009 17:35:01 -0000 At Wed, 02 Dec 2009 21:37:22 -0800, Joe Touch wrote: > Eric Rescorla wrote: > > Yes, I'll send comments on it once I have a chance to read it and > > write some. If you prefer, I can of course just raise any issues > > in IETF LC, but I thought people might appreciate a heads-up that > > I likely wasn't in favor. > > It's great that you have such a well formed uninformed position. Joe, this sort of personal attack is really uncalled for. I've been doing other things for the past few weeks and while still swamped only just noticed the last call had ended, remembered I didn't like this draft, and thought it would be good to register *some* objection rather than just sandbagging people in IETF LC. In any case, now that I've had time to sleep on it, I recall what the issue is: it puts way too much stress on the ISN-based uniqueness mechanism. As should be immediately apparent, with TCP-AO if the connection parameters are ever reused an attacker can then replay traffic from one connection to another. However, because the host/port quartet is included in the MAC calculation (and the KDF, but that isn't necessary for this discussion), you cannot cut and paste traffic between connections originated between two different pairs of hosts, even if they use the same underlying master key. Now, you may say that that's bad key hygiene, but it's actually likely to be quite common if (for instance) two sites have multiple adjacencies but use the same key for each one. In any case, the current structure of AO completely prevents such attacks. By contrast, with this extension, if the parameters are ever reused then an attacker can potentially cut-and-paste between connections initiated by two remote hosts, even those not behind the same NAT (because it blocks out the entire IP, not just narrows it to some subrange). Of course, it's reasonable to ask how likely reuse is. Consider the obvious case where Alice and Bob are both behind NATs and they are connecting to Charlie, which has a fixed IP address. I.e. Alice --- NAT ------------------------------ Charlie Bob --- NAT ------------------------------ Thus Alice and Bob have localNAT set and Charlie has remoteNAT set. Now, if Alice and Bob and Charlie all share the same key, then they can clearly impersonate each other, but that's OK in some cases, for instance if they are all operated by the same people (or at least Alice and Bob are). Now, for the protocol parameters: Charlie's side of the connection likely has a constant IP and port, so that doesn't contribute to uniqueness. Alice and Bob's sides are wiped out so they don't. This only leaves the ISNs (note that this is contrary to the Security Considerations analysis, which suggests that it's only a problem if you use the NAT flag on both sides) as security, so at best you have 64 bits of uniqueness, but if the PRNGs aren't strong, it's potentially much worse. Moreover, an attacker who captures some corpus of initial SYNs can potentially probe Charlie from a variety of source addresses/ports in whatever the acceptable range is in an attempt to elicit a correct SYN/ACK. This removes the issue of the client ISN and brings us down to a 2^32 (at best) attack level.[*] This seems to me to undercut the basic AO security guarantees. -Ekr P.S. The entropy analysis in the security considerations seems incorrect. For starters, there is nowhere near 32 bits of entropy in an IP address or port since neither is chosen from a uniform range (especially in the case of server ports). [*] Actually, probably worse, since the standard randomization solutions tend to randomly distribute the starting point only and so you can choose a good starting point and then linearly home in. From lars.eggert@nokia.com Thu Dec 3 09:37: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 AAC6028C142 for ; Thu, 3 Dec 2009 09:37:41 -0800 (PST) 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 2xVFL0DFFU1R for ; Thu, 3 Dec 2009 09:37:40 -0800 (PST) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 0F80F3A672E for ; Thu, 3 Dec 2009 09:37:39 -0800 (PST) Received: from 64-129-13-97.static.twtelecom.net (64-129-13-97.static.twtelecom.net [64.129.13.97] (may be forged)) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id nB3HFCkG011814 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 3 Dec 2009 19:15:15 +0200 (EET) (envelope-from lars.eggert@nokia.com) From: Lars Eggert Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-19-232954089; protocol="application/pkcs7-signature"; micalg=sha1 Date: Thu, 3 Dec 2009 07:15:11 -1000 References: <4B164C00.3060509@ripe.net> To: "tcpm@ietf.org WG" Message-Id: X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [195.148.124.194]); Thu, 03 Dec 2009 19:15:16 +0200 (EET) Cc: "ippm-chairs@tools.ietf.org chair" Subject: [tcpm] Fwd: [ippm] WG interest in draft-constantine-ippm-tcp-throughput-tm-00.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: Thu, 03 Dec 2009 17:37:41 -0000 --Apple-Mail-19-232954089 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, TCPM, you might want to voice your opinion on the IPPM list on this proposed = work item. If they take it on, TCPM will probably occasionally be asked = to comment on the ongoing work. Lars Begin forwarded message: > From: Henk Uijterwaal > Date: December 2, 2009 1:14:08 HST > To: IETF IPPM WG > Subject: [ippm] WG interest in = draft-constantine-ippm-tcp-throughput-tm-00.txt >=20 > IPPM group, >=20 > In Hiroshima, Barry presented possible new work on >=20 > TCP Throughput Testing Methodology > = http://www.ietf.org/id/draft-constantine-ippm-tcp-throughput-tm-00.txt >=20 > We'd like to know if you feel that this is work that the IPPM group > should pick up and, if so, who is interested to contribute to this > document. Please post your thoughts before January 4, 2010. >=20 >=20 > Matt & Henk >=20 > --=20 > = --------------------------------------------------------------------------= ---- > Henk Uijterwaal Email: = henk.uijterwaal(at)ripe.net > RIPE Network Coordination Centre http://www.xs4all.nl/~henku > P.O.Box 10096 Singel 258 Phone: +31.20.5354414 > 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 > The Netherlands The Netherlands Mobile: +31.6.55861746 > = --------------------------------------------------------------------------= ---- >=20 > Nobody ever went broke underestimating the taste of the American = public. > = H.L.Mencken > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm --Apple-Mail-19-232954089 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTIwMzE3MTUxMlowIwYJKoZIhvcNAQkEMRYEFKEivGUXrOecUBCqrn3YLClK79fqMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQCTPy+0wczOsE7n0delZimKGs3Y7guWQloc4qekfaV+VHgb3sFk1S+Pkj0iO4xctQpQFiCX Uv1Y8e9S/tvWI8rKsRnQFRekNq0eEm97zMZP7DlylxZSeEPUUKMbxghjxTuY3/hJti25Yg/MN2e2 o/guqwzeS0crv/KfccAwtM5T0eXy1sJJrGwd3U331Ro+aTatQkUTNmDgXClKkvAiUdeR+Y2frlu7 jL6N7dXb5OiwXCvNCT2bu3bGHHPdWILvjGWxjFgdKFSuXDbPxq01E1+UnuekAHuBMs7xiRfadnpX mRRJpUfq1RHCy7KFm5ftlvPP2cOXitqB31SsB4S6ON+2AAAAAAAA --Apple-Mail-19-232954089-- From touch@ISI.EDU Thu Dec 3 10:15: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 DA8E228C180 for ; Thu, 3 Dec 2009 10:15:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.613 X-Spam-Level: X-Spam-Status: No, score=-2.613 tagged_above=-999 required=5 tests=[AWL=-0.014, 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 nQvtNFVO5u1q for ; Thu, 3 Dec 2009 10:15:21 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 0DE2328C190 for ; Thu, 3 Dec 2009 10:15:18 -0800 (PST) Received: from [192.168.1.43] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nB3IEocO009737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 Dec 2009 10:14:55 -0800 (PST) Message-ID: <4B18001A.9070600@isi.edu> Date: Thu, 03 Dec 2009 10:14:50 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Eric Rescorla References: <20091203032738.3F7B86C489B@kilo.networkresonance.com> <4B173270.70403@isi.edu> <20091203050652.585F86C495F@kilo.networkresonance.com> <4B174E92.2030702@isi.edu> <20091203173612.9C20A6C49F7@kilo.networkresonance.com> In-Reply-To: <20091203173612.9C20A6C49F7@kilo.networkresonance.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] closing WGLC 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: Thu, 03 Dec 2009 18:15:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Rescorla wrote: > At Wed, 02 Dec 2009 21:37:22 -0800, > Joe Touch wrote: >> Eric Rescorla wrote: >>> Yes, I'll send comments on it once I have a chance to read it and >>> write some. If you prefer, I can of course just raise any issues >>> in IETF LC, but I thought people might appreciate a heads-up that >>> I likely wasn't in favor. >> >> It's great that you have such a well formed uninformed position. > > Joe, this sort of personal attack is really uncalled for. > > I've been doing other things for the past few weeks and while still > swamped only just noticed the last call had ended, remembered I > didn't like this draft, and thought it would be good to register > *some* objection rather than just sandbagging people in IETF LC. I object to "I didn't read the draft but..." sorts of comments. They are unprofessional at best, and disrespectful to the list as well as authors. If you have a concern, voice it with content. > In any case, now that I've had time to sleep on it, I recall what > the issue is: it puts way too much stress on the ISN-based > uniqueness mechanism. > > As should be immediately apparent, with TCP-AO if the connection > parameters are ever reused an attacker can then replay traffic from > one connection to another. However, because the host/port quartet is > included in the MAC calculation (and the KDF, but that isn't necessary > for this discussion), you cannot cut and paste traffic between > connections originated between two different pairs of hosts, even if > they use the same underlying master key. Now, you may say that that's > bad key hygiene, but it's actually likely to be quite common if (for > instance) two sites have multiple adjacencies but use the same key for > each one. We cannot correct for poor MKT management, nor should we try. IMO that is the purvue of a KMS. > In any case, the current structure of AO completely > prevents such attacks. By contrast, with this extension, if the > parameters are ever reused then an attacker can potentially > cut-and-paste between connections initiated by two remote hosts, even > those not behind the same NAT (because it blocks out the entire IP, > not just narrows it to some subrange). This is possible when: a) the ISNs are repeated AND b) the nonchanging adr/port is repeated (presuming at least one side doesn't change) Note that an attacker can't know when this happens because omission of the adr/port on one side isn't signalled on the wire. They would have to wait around until the ISNs repeat (which is visible) AND the adr/port pair repeats to ensure their attack would succeed. Agreed that for hosts behind a NAT, the nonchanging adr/port may repeat by reconnecting to a single host. But in order for an attack to succeed, the ISNs of *both sides* would need to reappear. Even if one side were to be reused, that's useless unless the other side also reuses its. So this boils down to the chance that two ISN generators between two machines ever repeat *as a pair*. IMO, that's fairly strong. > Of course, it's reasonable to ask how likely reuse is. Consider > the obvious case where Alice and Bob are both behind NATs and they are > connecting to Charlie, which has a fixed IP address. I.e. > > > Alice --- NAT ------------------------------ > Charlie > Bob --- NAT ------------------------------ > > > Thus Alice and Bob have localNAT set and Charlie has remoteNAT set. > > Now, if Alice and Bob and Charlie all share the same key, then they > can clearly impersonate each other, but that's OK in some cases, > for instance if they are all operated by the same people (or at > least Alice and Bob are). > > Now, for the protocol parameters: Charlie's side of the connection > likely has a constant IP and port, so that doesn't contribute to > uniqueness. Alice and Bob's sides are wiped out so they don't. > This only leaves the ISNs (note that this is contrary to the > Security Considerations analysis, which suggests that it's only > a problem if you use the NAT flag on both sides) as security, > so at best you have 64 bits of uniqueness, but if the PRNGs > aren't strong, it's potentially much worse. We can point out that the uniqueness is essentially only 64 bits even when used on only one side. > Moreover, an attacker > who captures some corpus of initial SYNs can potentially probe > Charlie from a variety of source addresses/ports in whatever > the acceptable range is in an attempt to elicit a correct > SYN/ACK. This removes the issue of the client ISN and brings > us down to a 2^32 (at best) attack level.[*] Your analysis presumes that sending repeated SYNs will elicit ISNs in a known sequence. If they're created arbitrarily, esp. using a hash function (see RFC 1948), then this attack isn't realistic AFAICT. A client could easily detect an attempt of such an attack because it would involve repeated receipt of a SYN with the same socket pair and the same ISN - I would hope that an alarm could go off before 2^32 were tried. We could add a note in the security considerations to address that issue, which might be relevant regardless of whether NAT support is included. > This seems to me to undercut the basic AO security guarantees. > > -Ekr > > P.S. The entropy analysis in the security considerations seems > incorrect. For starters, there is nowhere near 32 bits of entropy > in an IP address or port since neither is chosen from a uniform > range (especially in the case of server ports). We'll update that. However, if that's true, then even the basic AO has only the entropy of the ISNs, and *maybe* the entropy of the source port. Noting that many implementations select from among only the dynamic range, that entropy is fairly small (14 bits) at best. Gont's analysis suggests that it's not even all that much, given the way in which source ports are selected. So basically we're relying on the entropy of the ISNs anyway. > [*] Actually, probably worse, since the standard randomization > solutions tend to randomly distribute the starting point only > and so you can choose a good starting point and then linearly > home in. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksYABkACgkQE5f5cImnZrtC/QCg1aZwnHoGhElcD8j7AeWlBTeZ E4oAoLxc/ttkkyfyY2kUw9F35gTplhqD =4i+Q -----END PGP SIGNATURE----- From A.Hoenes@TR-Sys.de Thu Dec 3 10:46: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 05C2B3A6359 for ; Thu, 3 Dec 2009 10:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.817 X-Spam-Level: * X-Spam-Status: No, score=1.817 tagged_above=-999 required=5 tests=[AWL=0.566, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f47vY7k2Xmtk for ; Thu, 3 Dec 2009 10:46:35 -0800 (PST) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 446503A67A5 for ; Thu, 3 Dec 2009 10:46:34 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA257525926; Thu, 3 Dec 2009 19:45:26 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id TAA25053; Thu, 3 Dec 2009 19:45:25 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200912031845.TAA25053@TR-Sys.de> To: tcpm@ietf.org Date: Thu, 3 Dec 2009 19:45:24 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] closing WGLC 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: Thu, 03 Dec 2009 18:46:36 -0000 At Wed, 2 Dec 2009 21:49:45 -0800, Chandrashekhar Appanna wrote: > The entire process asociated with this draft has been very odd.. on > all fronts it has shown exactly how the IETF should not do things. > The fact that one vocal and nagging individual can usurp and upset > the effort and the ideas that originated with others was definitely > odd to me.. I do not intend to debate or argue but since this is > an open forum and opnions are being stated, I want to put mine in > for the record too. > > 0.02 :) > Chandra. +1 +1 +1 I also have been disappointed very much by the procedures and stopped spending cycles for this effort more than a year ago, after all suggestions -- even those having been acked before -- did not get acted upon orderly. Ironically, whereas the draft (after eight update cycles) still calls out being "Simple AO" in its page headers (and pretends having a single author in the page footers), the protocol has become an involved replication of functionality already present in other IETF protocols, hiding the parallels to these by painfully avoiding to use established terms like "security association", using the euphemism "key ID" for the SPI, etc. ... It appears to me that "acceptable" (to the author) discussion of the draft essentially was limited to an "inner circle"; heated debates on WG meetings were only cursory sketched in the minutes and never brought to the list; the short on-list debates during the short time between publication of the AO draft updates (precisely aligned with the IETF cutoff date, or even later) and the subsequent IETF meetings did not have great impact of the next version, which has not been published until everybody with other day jobs almost had forgotten the on-list discussions 4 months earlier. Also waiting for IETF LC to step in ... Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From ekr@networkresonance.com Thu Dec 3 10:52: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 57F853A68D6 for ; Thu, 3 Dec 2009 10:52:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.195 X-Spam-Level: * X-Spam-Status: No, score=1.195 tagged_above=-999 required=5 tests=[AWL=-0.300, 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, J_CHICKENPOX_19=0.6, 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 4hB06ym7Msxw for ; Thu, 3 Dec 2009 10:52:09 -0800 (PST) Received: from kilo.networkresonance.com (216.156.83.78.ptr.us.xo.net [216.156.83.78]) by core3.amsl.com (Postfix) with ESMTP id 262C43A68C1 for ; Thu, 3 Dec 2009 10:52:09 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id E22976C4A23; Thu, 3 Dec 2009 10:53:21 -0800 (PST) Date: Thu, 03 Dec 2009 10:53:21 -0800 From: Eric Rescorla To: Joe Touch In-Reply-To: <4B18001A.9070600@isi.edu> References: <20091203032738.3F7B86C489B@kilo.networkresonance.com> <4B173270.70403@isi.edu> <20091203050652.585F86C495F@kilo.networkresonance.com> <4B174E92.2030702@isi.edu> <20091203173612.9C20A6C49F7@kilo.networkresonance.com> <4B18001A.9070600@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: <20091203185321.E22976C4A23@kilo.networkresonance.com> Cc: "tcpm@ietf.org" Subject: Re: [tcpm] closing WGLC 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: Thu, 03 Dec 2009 18:52:10 -0000 At Thu, 03 Dec 2009 10:14:50 -0800, Joe Touch wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Eric Rescorla wrote: > > At Wed, 02 Dec 2009 21:37:22 -0800, > > Joe Touch wrote: > > I've been doing other things for the past few weeks and while still > > swamped only just noticed the last call had ended, remembered I > > didn't like this draft, and thought it would be good to register > > *some* objection rather than just sandbagging people in IETF LC. > > I object to "I didn't read the draft but..." sorts of comments. They are > unprofessional at best, and disrespectful to the list as well as > authors. Joe, to be blunt, you're hardly my guidepost on how to act professional and respectful. > If you have a concern, voice it with content. As I have. The draft is broken for the reasons I indicated. > > In any case, now that I've had time to sleep on it, I recall what > > the issue is: it puts way too much stress on the ISN-based > > uniqueness mechanism. > > > > As should be immediately apparent, with TCP-AO if the connection > > parameters are ever reused an attacker can then replay traffic from > > one connection to another. However, because the host/port quartet is > > included in the MAC calculation (and the KDF, but that isn't necessary > > for this discussion), you cannot cut and paste traffic between > > connections originated between two different pairs of hosts, even if > > they use the same underlying master key. Now, you may say that that's > > bad key hygiene, but it's actually likely to be quite common if (for > > instance) two sites have multiple adjacencies but use the same key for > > each one. > > We cannot correct for poor MKT management, nor should we try. IMO that > is the purvue of a KMS. This is a fine key management practice. The problem is that the draft weakens AO's security guarantees. > > In any case, the current structure of AO completely > > prevents such attacks. By contrast, with this extension, if the > > parameters are ever reused then an attacker can potentially > > cut-and-paste between connections initiated by two remote hosts, even > > those not behind the same NAT (because it blocks out the entire IP, > > not just narrows it to some subrange). > > This is possible when: > > a) the ISNs are repeated > AND > b) the nonchanging adr/port is repeated (presuming at least one > side doesn't change) > > Note that an attacker can't know when this happens because omission of > the adr/port on one side isn't signalled on the wire. Unless they have other information about the network structure, which isn't at all unlikely. > They would have to > wait around until the ISNs repeat (which is visible) AND the adr/port > pair repeats to ensure their attack would succeed. > > Agreed that for hosts behind a NAT, the nonchanging adr/port may repeat > by reconnecting to a single host. But in order for an attack to succeed, > the ISNs of *both sides* would need to reappear. Even if one side were > to be reused, that's useless unless the other side also reuses its. > > So this boils down to the chance that two ISN generators between two > machines ever repeat *as a pair*. IMO, that's fairly strong. No, that's not correct, because the attacker can force a repeat on the client side by retransmitting the client's ISN, as I indicated below. > > Moreover, an attacker > > who captures some corpus of initial SYNs can potentially probe > > Charlie from a variety of source addresses/ports in whatever > > the acceptable range is in an attempt to elicit a correct > > SYN/ACK. This removes the issue of the client ISN and brings > > us down to a 2^32 (at best) attack level.[*] > > Your analysis presumes that sending repeated SYNs will elicit ISNs in a > known sequence. If they're created arbitrarily, esp. using a hash > function (see RFC 1948), then this attack isn't realistic AFAICT. You misunderstand the 1948 algorithm, which simply adds a random (but fixed for each socketpair) offset to the ISN sequence: ISN = M + F(localhost, localport, remotehost, remoteport). Repeated probes indeed to produce ISNs in a specific sequence. Moreover, the random start behavior is a feature for the attacker because they can try scattered source ports and thus access sparse initial starting points and thus reduce their search space. > A client could easily detect an attempt of such an attack because it > would involve repeated receipt of a SYN with the same socket pair and > the same ISN - I would hope that an alarm could go off before 2^32 were > tried. I prefer to have my security based on something other than hope. > > This seems to me to undercut the basic AO security guarantees. > > > > -Ekr > > > > P.S. The entropy analysis in the security considerations seems > > incorrect. For starters, there is nowhere near 32 bits of entropy > > in an IP address or port since neither is chosen from a uniform > > range (especially in the case of server ports). > > We'll update that. However, if that's true, then even the basic AO has > only the entropy of the ISNs, and *maybe* the entropy of the source > port. Noting that many implementations select from among only the > dynamic range, that entropy is fairly small (14 bits) at best. Gont's > analysis suggests that it's not even all that much, given the way in > which source ports are selected. > > So basically we're relying on the entropy of the ISNs anyway. Yes, AO relies on the entropy of the ISNs but the security guarantees in case they are weak are much better than with this draft. Chairs: You said that "Since several people supported this, and none were against it." I am against it and I've posted my reasons why. Given that it sounds like support was modest at best, I think that's sufficient reason to say there's not consensus for including this functionality in the version sent to the IESG. -Ekr From lars.eggert@nokia.com Thu Dec 3 11:01: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 06C3C3A68F3 for ; Thu, 3 Dec 2009 11:01:12 -0800 (PST) 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 xm4yShlumVin for ; Thu, 3 Dec 2009 11:01:11 -0800 (PST) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id CBEB33A68E4 for ; Thu, 3 Dec 2009 11:01:10 -0800 (PST) Received: from 64-129-13-97.static.twtelecom.net (64-129-13-97.static.twtelecom.net [64.129.13.97] (may be forged)) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id nB3J0pTu016171 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 3 Dec 2009 21:00:54 +0200 (EET) (envelope-from lars.eggert@nokia.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-23-239292791; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: Date: Thu, 3 Dec 2009 09:00:50 -1000 Message-Id: <500C5C63-E2E9-41C4-8971-8D7B8F2B0CA7@nokia.com> References: To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [195.148.124.194]); Thu, 03 Dec 2009 21:00:55 +0200 (EET) Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] closing WGLC 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: Thu, 03 Dec 2009 19:01:12 -0000 --Apple-Mail-23-239292791 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, speaking as an individual contributor. I believe the two drafts are ready for publication (modulo some minor = editorial nits, see e.g. Wes' email.) There is no question in my mind that we can continue to tweak the two = docs forever, and maybe we'll even manage to substantially improve them. = But I don't think that would the most productive use of our combined = time. What we have is good enough to be published as PS, and needs to be = published ASAP so people have a standards-track replacement for TCP-MD5. Lars= --Apple-Mail-23-239292791 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTIwMzE5MDA1MVowIwYJKoZIhvcNAQkEMRYEFIorx30ZYKDNIB7fwF1OUVwm+r1dMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQB6N5P9tjVdXy9wnKlIrhjexYUMTtmEFRxkUxZv+0uS8qPWnbXlppT+lSFIBPk2d4hxTKGy NS58uRTEEDgWDucd7vyHKreWiqFwFXdCNvv3F3wsbvvTmj3uWtL1MbrbYsyck3vmuZnFLPSxiKVX u0gdwnqnCbyTuQtEBMDgB+FDJyvBaxqF0snaCN6d1SBD8SlAUL9M9hIbeuWzpGy2eKAQrd4pv+km IvdYtiPBY0TJJKbf7oefLk/xc3daE8bU3toPU3yFi7sXU7MLlUetSZC0eSpY1t9GInKfqqMJb/pU KaTeO0aSiHC+knMs3qBkE9qkAMXybp3qoXRc88MQ2iyNAAAAAAAA --Apple-Mail-23-239292791-- From ekr@networkresonance.com Thu Dec 3 11:05:53 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 31C073A68E4 for ; Thu, 3 Dec 2009 11:05:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.045 X-Spam-Level: * X-Spam-Status: No, score=1.045 tagged_above=-999 required=5 tests=[AWL=0.150, 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, 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 fuuuSUj8T+48 for ; Thu, 3 Dec 2009 11:05:52 -0800 (PST) Received: from kilo.networkresonance.com (216.156.83.78.ptr.us.xo.net [216.156.83.78]) by core3.amsl.com (Postfix) with ESMTP id 8C85C3A6782 for ; Thu, 3 Dec 2009 11:05:52 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 078676C4A31; Thu, 3 Dec 2009 11:07:04 -0800 (PST) Date: Thu, 03 Dec 2009 11:07:04 -0800 From: Eric Rescorla To: Lars Eggert In-Reply-To: <500C5C63-E2E9-41C4-8971-8D7B8F2B0CA7@nokia.com> References: <500C5C63-E2E9-41C4-8971-8D7B8F2B0CA7@nokia.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: <20091203190705.078676C4A31@kilo.networkresonance.com> Cc: Joe Touch , "tcpm@ietf.org" Subject: Re: [tcpm] closing WGLC 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: Thu, 03 Dec 2009 19:05:53 -0000 At Thu, 3 Dec 2009 09:00:50 -1000, Lars Eggert wrote: > > Hi, > > speaking as an individual contributor. > > I believe the two drafts are ready for publication (modulo some minor editorial nits, see e.g. Wes' email.) > > There is no question in my mind that we can continue to tweak the > two docs forever, and maybe we'll even manage to substantially > improve them. But I don't think that would the most productive use > of our combined time. What we have is good enough to be published as > PS, and needs to be published ASAP so people have a standards-track > replacement for TCP-MD5. This does not apply to the NAT document, AFAIK. TCP-MD5 does not support NATs. It's purely a feature enhancement. I don't see why it needs to be rushed, and in view of the evident security problems, published at all. -Ekr From wesley.m.eddy@nasa.gov Thu Dec 3 11:08: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 0B9283A68B8 for ; Thu, 3 Dec 2009 11:08:31 -0800 (PST) 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 BDP5xWKyk7eB for ; Thu, 3 Dec 2009 11:08:30 -0800 (PST) Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by core3.amsl.com (Postfix) with ESMTP id 2A0673A65A5 for ; Thu, 3 Dec 2009 11:08:29 -0800 (PST) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 62EBB783F9; Thu, 3 Dec 2009 13:08:21 -0600 (CST) Received: from ndjshub02.ndc.nasa.gov (ndjshub02-pub.ndc.nasa.gov [198.117.1.161]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id nB3J8LGC004454; Thu, 3 Dec 2009 13:08:21 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub02.ndc.nasa.gov ([198.117.1.161]) with mapi; Thu, 3 Dec 2009 13:08:21 -0600 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: Eric Rescorla , Joe Touch Date: Thu, 3 Dec 2009 13:08:19 -0600 Thread-Topic: [tcpm] closing WGLC for TCP-AO Thread-Index: Acp0SbPFJ3NlYxRkSO+xAtEONHs/CwAAM0rw Message-ID: References: <20091203032738.3F7B86C489B@kilo.networkresonance.com> <4B173270.70403@isi.edu> <20091203050652.585F86C495F@kilo.networkresonance.com> <4B174E92.2030702@isi.edu> <20091203173612.9C20A6C49F7@kilo.networkresonance.com> <4B18001A.9070600@isi.edu> <20091203185321.E22976C4A23@kilo.networkresonance.com> In-Reply-To: <20091203185321.E22976C4A23@kilo.networkresonance.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-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-12-03_12:2009-11-30, 2009-12-03, 2009-12-03 signatures=0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] closing WGLC 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: Thu, 03 Dec 2009 19:08:31 -0000 >-----Original Message----- >From: Eric Rescorla [mailto:ekr@networkresonance.com] >Sent: Thursday, December 03, 2009 1:53 PM >To: Joe Touch >Cc: Eric Rescorla; Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; >tcpm@ietf.org >Subject: Re: [tcpm] closing WGLC for TCP-AO > >Chairs: You said that "Since several people supported >this, and none were against it." I am against it and I've posted >my reasons why. Given that it sounds like support was modest at >best, I think that's sufficient reason to say there's not >consensus for including this functionality in the version >sent to the IESG. > Agreed; since there are apparently issues that will require further detailed discussion, for the sake of moving the base AO protocol forward in the near term, let's bookmark this in the WG as a possible future extension to be considered, but move AO forward without it for the moment. We should take time to properly discuss the NAT extension in TCPM rather than get heated with each other about it now. Thanks for sharing your concerns at this juncture rather than waiting for IETF LC; we should start a new thread to continue the NAT topic since it's no longer related to finishing the WGLC. -- Wes Eddy MTI Systems From touch@ISI.EDU Thu Dec 3 11:24: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 334E228C168 for ; Thu, 3 Dec 2009 11:24:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=-0.313, BAYES_00=-2.599, J_CHICKENPOX_19=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 FumSkOUSfFAn for ; Thu, 3 Dec 2009 11:24:29 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 5D4EA28C0E5 for ; Thu, 3 Dec 2009 11:24:29 -0800 (PST) Received: from [192.168.1.43] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nB3JO8wL001568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 Dec 2009 11:24:10 -0800 (PST) Message-ID: <4B181058.60104@isi.edu> Date: Thu, 03 Dec 2009 11:24:08 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Eric Rescorla References: <20091203032738.3F7B86C489B@kilo.networkresonance.com> <4B173270.70403@isi.edu> <20091203050652.585F86C495F@kilo.networkresonance.com> <4B174E92.2030702@isi.edu> <20091203173612.9C20A6C49F7@kilo.networkresonance.com> <4B18001A.9070600@isi.edu> <20091203185321.E22976C4A23@kilo.networkresonance.com> In-Reply-To: <20091203185321.E22976C4A23@kilo.networkresonance.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] closing WGLC 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: Thu, 03 Dec 2009 19:24:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Rescorla wrote: ... >>> Moreover, an attacker >>> who captures some corpus of initial SYNs can potentially probe >>> Charlie from a variety of source addresses/ports in whatever >>> the acceptable range is in an attempt to elicit a correct >>> SYN/ACK. This removes the issue of the client ISN and brings >>> us down to a 2^32 (at best) attack level.[*] >> Your analysis presumes that sending repeated SYNs will elicit ISNs in a >> known sequence. If they're created arbitrarily, esp. using a hash >> function (see RFC 1948), then this attack isn't realistic AFAICT. > > You misunderstand the 1948 algorithm, which simply adds a random > (but fixed for each socketpair) offset to the ISN sequence: > > ISN = M + F(localhost, localport, remotehost, remoteport). > > Repeated probes indeed to produce ISNs in a specific sequence. M is a 4ms timer. You'd need the timer to wrap around. Can you explan why you think this presents a vulnerability? Further F is intended to include more than just the presented arguments: It is vital that F not be computable from the outside, or an attacker could still guess at sequence numbers from the initial sequence number used for some other connection. We therefore suggest that F be a cryptographic hash function of the connection-id and some secret data. MD5 [9] is a good choice, since the code is widely available. The secret data can either be a true random number [10], or it can be the combination of some per-host secret and the boot time of the machine. The boot time is included to ensure that the secret is changed on occasion. Other data, such as the host's IP address and name, may be included in the hash as well; this eases administration by permitting a network of workstations to share the same secret data while still giving them separate sequence number spaces. Our recommendation, in fact, is to use all three of these items: as random a number as the hardware can generate, an administratively- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ installed pass phrase, and the machine's IP address. This allows for local choice on how secure the secret is. This would not be repeatable for a given set of inputs. ... >> A client could easily detect an attempt of such an attack because it >> would involve repeated receipt of a SYN with the same socket pair and >> the same ISN - I would hope that an alarm could go off before 2^32 were >> tried. > > I prefer to have my security based on something other than hope. Would a recommendation (SHOULD) to put in an "excessive repeated SYN" alarm be sufficient? >> So basically we're relying on the entropy of the ISNs anyway. > > Yes, AO relies on the entropy of the ISNs but the security guarantees > in case they are weak are much better than with this draft. This is the crux of your argument - that ISNs alone are insufficient, but you haven't shown how adding the addrs and ports really adds much. In fact, it was *you* who suggested adding the ISNs (see your post of 3/11/2008 to the design team), and *you* who is pointing out that the addrs/ports don't add entropy. By your argument, TCP-AO isn't as secure as you'd like (which may be the case), but TCP-AO with NAT isn't substantially *less* secure. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksYEFgACgkQE5f5cImnZrsETACeK9yYH3NNY2hzFOXunICH3d7u eLMAoK9C5l5C7Jb0a9qjgQDNYPXfmK55 =I2VG -----END PGP SIGNATURE----- From dab@weston.borman.com Thu Dec 3 11:30:20 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 BE5C628C1A1 for ; Thu, 3 Dec 2009 11:30:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEn8MET1-Tlt for ; Thu, 3 Dec 2009 11:30:20 -0800 (PST) Received: from frantic.weston.borman.com (frantic-dmz.weston.BORMAN.COM [206.196.54.22]) by core3.amsl.com (Postfix) with ESMTP id CC1D428C17F for ; Thu, 3 Dec 2009 11:30:19 -0800 (PST) Received: from weston-59.weston.borman.com (weston-59.weston.borman.com [206.196.45.59]) by frantic.weston.borman.com (8.12.5/8.12.5) with ESMTP id nB3JU7Yu020833; Thu, 3 Dec 2009 13:30:08 -0600 (CST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: David Borman In-Reply-To: Date: Thu, 3 Dec 2009 13:30:06 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20091203032738.3F7B86C489B@kilo.networkresonance.com> <4B173270.70403@isi.edu> <20091203050652.585F86C495F@kilo.networkresonance.com> <4B174E92.2030702@isi.edu> <20091203173612.9C20A6C49F7@kilo.networkresonance.com> <4B18001A.9070600@isi.edu> <20091203185321.E22976C4A23@kilo.networkresonance.com> To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" X-Mailer: Apple Mail (2.1077) Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] closing WGLC 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: Thu, 03 Dec 2009 19:30:20 -0000 I agree, we should move AO forward without NAT. The NAT document can = continue to be discussed, and if/when agreement is reached, at that time = we'll have the option of either publishing it as a separate document, or = making a rev of AO to add the NAT information, but we don't need to = decide that right now. -David Borman, TCPM WG co-chair On Dec 3, 2009, at 1:08 PM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE = CORP] wrote: >> -----Original Message----- >> From: Eric Rescorla [mailto:ekr@networkresonance.com] >> Sent: Thursday, December 03, 2009 1:53 PM >> To: Joe Touch >> Cc: Eric Rescorla; Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; >> tcpm@ietf.org >> Subject: Re: [tcpm] closing WGLC for TCP-AO >>=20 >> Chairs: You said that "Since several people supported >> this, and none were against it." I am against it and I've posted >> my reasons why. Given that it sounds like support was modest at >> best, I think that's sufficient reason to say there's not >> consensus for including this functionality in the version >> sent to the IESG. >>=20 >=20 >=20 > Agreed; since there are apparently issues that will require > further detailed discussion, for the sake of moving the base > AO protocol forward in the near term, let's bookmark this in > the WG as a possible future extension to be considered, but > move AO forward without it for the moment. >=20 > We should take time to properly discuss the NAT extension > in TCPM rather than get heated with each other about it now. > Thanks for sharing your concerns at this juncture rather > than waiting for IETF LC; we should start a new thread to > continue the NAT topic since it's no longer related to > finishing the WGLC. >=20 > -- > Wes Eddy > MTI Systems >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From touch@ISI.EDU Thu Dec 3 11:40: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 9B6E63A688A for ; Thu, 3 Dec 2009 11:40:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=-0.003, 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 sfc7c-Gz4cTZ for ; Thu, 3 Dec 2009 11:40:36 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id E045D3A680E for ; Thu, 3 Dec 2009 11:40:36 -0800 (PST) Received: from [192.168.1.43] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nB3JeJ8N006852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 Dec 2009 11:40:21 -0800 (PST) Message-ID: <4B181423.9080005@isi.edu> Date: Thu, 03 Dec 2009 11:40:19 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Alfred_=3F?= References: <200912031845.TAA25053@TR-Sys.de> In-Reply-To: <200912031845.TAA25053@TR-Sys.de> 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] closing WGLC 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: Thu, 03 Dec 2009 19:40:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alfred ? wrote: ... > Ironically, whereas the draft (after eight update cycles) still > calls out being "Simple AO" in its page headers (and pretends having > a single author in the page footers), Thanks - that'll be updated. ... > It appears to me that "acceptable" (to the author) discussion of the > draft essentially was limited to an "inner circle"; heated debates on > WG meetings were only cursory sketched in the minutes and never brought > to the list; I can provide a list of detailed posts with long lists of action items raised at the meetings that were sent to the list if you like. I appreciate that you may have missed them, having decided to drop out of the discussion, but that doesn't mean they weren't sent to the list on many occasions. > the short on-list debates during the short time between > publication of the AO draft updates (precisely aligned with the IETF > cutoff date, or even later) and the subsequent IETF meetings did not > have great impact of the next version, which has not been published > until everybody with other day jobs almost had forgotten the on-list > discussions 4 months earlier. I kept a list of issues raised and resolutions, and updated the doc accordingly. Those updates were included in the forward of the doc until recently - as they became prohibitively large. I can provide them if needed. > Also waiting for IETF LC to step in ... WG LC has a purpose. You and EKR were silent during it. Now you want to use IETF LC as a substitute? Check the process rules - I know I will. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksYFCMACgkQE5f5cImnZruArgCcC4ShPmZMBwEGBCKRXNOuCj2L x1kAni4SFExbNVPqO5qkU706bx89Wzcw =AQso -----END PGP SIGNATURE----- From lars.eggert@nokia.com Thu Dec 3 12:29: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 EA6653A68EA for ; Thu, 3 Dec 2009 12:29:24 -0800 (PST) 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 dPGxgoPdkJLz for ; Thu, 3 Dec 2009 12:29:24 -0800 (PST) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id AF9673A68C2 for ; Thu, 3 Dec 2009 12:29:23 -0800 (PST) Received: from [10.1.3.153] (64-129-14-254.static.twtelecom.net [64.129.14.254] (may be forged)) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id nB3KT14h019665 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 3 Dec 2009 22:29:03 +0200 (EET) (envelope-from lars.eggert@nokia.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-27-244576947; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <20091203190705.078676C4A31@kilo.networkresonance.com> Date: Thu, 3 Dec 2009 10:28:54 -1000 Message-Id: <79B69D7B-66E5-4904-B97C-73638B8AF780@nokia.com> References: <500C5C63-E2E9-41C4-8971-8D7B8F2B0CA7@nokia.com> <20091203190705.078676C4A31@kilo.networkresonance.com> To: Eric Rescorla X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [212.213.221.39]); Thu, 03 Dec 2009 22:29:07 +0200 (EET) Cc: Joe Touch , "tcpm@ietf.org" Subject: Re: [tcpm] closing WGLC 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: Thu, 03 Dec 2009 20:29:25 -0000 --Apple-Mail-27-244576947 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2009-12-3, at 9:07, Eric Rescorla wrote: > This does not apply to the NAT document, AFAIK. TCP-MD5 does not = support > NATs. It's purely a feature enhancement. I don't see why it needs to > be rushed, and in view of the evident security problems, published > at all. agreed. For the NAT stuff, I sent an earlier message (during WGLC). = Based on the current discussion, it's not clear that it can be added = quickly, because it seems to require some more discussion. Begin forwarded message: > From: "Eggert Lars (Nokia-NRC/Espoo)" > Date: November 23, 2009 8:50:37 HST > To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" = > Cc: "tcpm@ietf.org" , Joe Touch > Subject: Re: [tcpm] working group status 11/17/09 >=20 > Hi, >=20 > without wearing any hats: if it can be added very quickly, i.e., = O(days), I'd be mildly in favor. Otherwise, let's just ship what we have = now. >=20 > Lars Lars= --Apple-Mail-27-244576947 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTIwMzIwMjg1NVowIwYJKoZIhvcNAQkEMRYEFJsAr7MS6Yu2ZShGJzenogaSVHR1MIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQBols7DRJk1lTNcB0kZcMwB8AQtvIk+u52T2HLx1L+ouB2EEdJP99/IBn+xmC5iYcY3y2Dy iEiobmzJ+hxV/e0/lH/y9NxA1WpLMnymWvr82mCmpKYeCR2Nb27yRdq5PgiP651A70f8HMxRudq7 Jr/0PCsBm1x9G2/Fl0f4w1aO4/ZcB8qJb+pqWco+7WJKl5GPnH8L2cnswtOeYrtiSJsf2VZ12lv9 pQmJuqMU+W0YhNn10NK+a5a8VzZjpcnj8ACu6KZw+DqYWClrLkConLid8MgsaXafknOZxSwsdTNp ewGxVk6k2pWp3GpdHaVALDvGnpsO7pQoht0Om1AGivFDAAAAAAAA --Apple-Mail-27-244576947-- From Donald.Smith@qwest.com Thu Dec 3 13:36:21 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 DBD593A657C for ; Thu, 3 Dec 2009 13:36:21 -0800 (PST) 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 1AMbWOwZUIEi for ; Thu, 3 Dec 2009 13:36:21 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id 0141B3A6858 for ; Thu, 3 Dec 2009 13:36:20 -0800 (PST) Received: from suomp60i.qintra.com (suomp60i.qintra.com [151.117.69.27]) by suomp64i.qwest.com (8.14.0/8.14.0) with ESMTP id nB3La8J5025169; Thu, 3 Dec 2009 15:36:08 -0600 (CST) Received: from qtdenexhtm20.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.0/8.14.0) with ESMTP id nB3La3fK023141; Thu, 3 Dec 2009 15:36:03 -0600 (CST) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm20.AD.QINTRA.COM ([151.119.91.229]) with mapi; Thu, 3 Dec 2009 14:36:02 -0700 From: "Smith, Donald" To: Lars Eggert , Eric Rescorla Content-Class: urn:content-classes:message Date: Thu, 3 Dec 2009 14:35:53 -0700 Thread-Topic: [tcpm] closing WGLC for TCP-AO Thread-Index: Acp0V0wiRU3kew2pRdWA2bHqf48XOQACJ2coAAArUyo= Message-ID: References: <500C5C63-E2E9-41C4-8971-8D7B8F2B0CA7@nokia.com> <20091203190705.078676C4A31@kilo.networkresonance.com>, <79B69D7B-66E5-4904-B97C-73638B8AF780@nokia.com> In-Reply-To: <79B69D7B-66E5-4904-B97C-73638B8AF780@nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-mimectl: Produced By Microsoft Exchange V8.1.348.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] closing WGLC 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: Thu, 03 Dec 2009 21:36:21 -0000 I object to this due to concerns previously expressed specifically connecti= onless resets =3D=3D spoofed resets. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com ________________________________ From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of Lars Egger= t [lars.eggert@nokia.com] Sent: Thursday, December 03, 2009 1:28 PM To: Eric Rescorla Cc: Joe Touch; tcpm@ietf.org Subject: Re: [tcpm] closing WGLC for TCP-AO Hi, On 2009-12-3, at 9:07, Eric Rescorla wrote: > This does not apply to the NAT document, AFAIK. TCP-MD5 does not support > NATs. It's purely a feature enhancement. I don't see why it needs to > be rushed, and in view of the evident security problems, published > at all. agreed. For the NAT stuff, I sent an earlier message (during WGLC). Based o= n the current discussion, it's not clear that it can be added quickly, beca= use it seems to require some more discussion. Begin forwarded message: > From: "Eggert Lars (Nokia-NRC/Espoo)" > Date: November 23, 2009 8:50:37 HST > To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" > Cc: "tcpm@ietf.org" , Joe Touch > Subject: Re: [tcpm] working group status 11/17/09 > > Hi, > > without wearing any hats: if it can be added very quickly, i.e., O(days),= I'd be mildly in favor. Otherwise, let's just ship what we have now. > > Lars Lars ________________________________ This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From wesley.m.eddy@nasa.gov Thu Dec 3 13:48: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 711753A6A86 for ; Thu, 3 Dec 2009 13:48:07 -0800 (PST) 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=[AWL=0.000, 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 O2lemmVf49Oj for ; Thu, 3 Dec 2009 13:48:06 -0800 (PST) Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by core3.amsl.com (Postfix) with ESMTP id 680B83A6A77 for ; Thu, 3 Dec 2009 13:48:06 -0800 (PST) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id DFA78148018; Thu, 3 Dec 2009 15:47:57 -0600 (CST) Received: from ndjshub01.ndc.nasa.gov (ndjshub01-pub.ndc.nasa.gov [198.117.1.160]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id nB3Llvk8010558; Thu, 3 Dec 2009 15:47:57 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub01.ndc.nasa.gov ([198.117.1.160]) with mapi; Thu, 3 Dec 2009 15:47:57 -0600 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: "Smith, Donald" , Lars Eggert , Eric Rescorla Date: Thu, 3 Dec 2009 15:47:56 -0600 Thread-Topic: [tcpm] closing WGLC for TCP-AO Thread-Index: Acp0V0wiRU3kew2pRdWA2bHqf48XOQACJ2coAAArUyoAAEpmQA== Message-ID: References: <500C5C63-E2E9-41C4-8971-8D7B8F2B0CA7@nokia.com> <20091203190705.078676C4A31@kilo.networkresonance.com>, <79B69D7B-66E5-4904-B97C-73638B8AF780@nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-12-03_14:2009-11-30, 2009-12-03, 2009-12-03 signatures=0 Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] closing WGLC 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: Thu, 03 Dec 2009 21:48:07 -0000 Just to clarify, your reply isn't objecting to the decision to not include NAT extensions, is it? Based on the second line, it seems to be about the thread Joe is trying to converge with you on: http://www.ietf.org/mail-archive/web/tcpm/current/msg05058.html Are his proposals there about noting the issue and how it can be addressed via BGP graceful restart reasonable? -- Wes Eddy MTI Systems >-----Original Message----- >From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of >Smith, Donald >Sent: Thursday, December 03, 2009 4:36 PM >To: Lars Eggert; Eric Rescorla >Cc: tcpm@ietf.org; Joe Touch >Subject: Re: [tcpm] closing WGLC for TCP-AO > >I object to this due to concerns previously expressed specifically >connectionless resets =3D=3D spoofed resets. > >(coffee !=3D sleep) & (!coffee =3D=3D sleep) > Donald.Smith@qwest.com >________________________________ >From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of Lars >Eggert [lars.eggert@nokia.com] >Sent: Thursday, December 03, 2009 1:28 PM >To: Eric Rescorla >Cc: Joe Touch; tcpm@ietf.org >Subject: Re: [tcpm] closing WGLC for TCP-AO > >Hi, > >On 2009-12-3, at 9:07, Eric Rescorla wrote: >> This does not apply to the NAT document, AFAIK. TCP-MD5 does not >support >> NATs. It's purely a feature enhancement. I don't see why it needs to >> be rushed, and in view of the evident security problems, published >> at all. > >agreed. For the NAT stuff, I sent an earlier message (during WGLC). >Based on the current discussion, it's not clear that it can be added >quickly, because it seems to require some more discussion. > >Begin forwarded message: >> From: "Eggert Lars (Nokia-NRC/Espoo)" >> Date: November 23, 2009 8:50:37 HST >> To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" > >> Cc: "tcpm@ietf.org" , Joe Touch >> Subject: Re: [tcpm] working group status 11/17/09 >> >> Hi, >> >> without wearing any hats: if it can be added very quickly, i.e., >O(days), I'd be mildly in favor. Otherwise, let's just ship what we have >now. >> >> Lars > >Lars > >________________________________ >This communication is the property of Qwest and may contain confidential >or >privileged information. Unauthorized use of this communication is >strictly >prohibited and may be unlawful. If you have received this communication >in error, please immediately notify the sender by reply e-mail and >destroy >all copies of the communication and any attachments. >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www.ietf.org/mailman/listinfo/tcpm From Donald.Smith@qwest.com Thu Dec 3 14:09:53 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 D73D928C18F for ; Thu, 3 Dec 2009 14:09:53 -0800 (PST) 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 3oTtNT2u-+6z for ; Thu, 3 Dec 2009 14:09:53 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id DEC363A6A46 for ; Thu, 3 Dec 2009 14:09:52 -0800 (PST) Received: from sudnp796.qintra.com (sudnp796.qintra.com [151.116.2.212]) by suomp64i.qwest.com (8.14.0/8.14.0) with ESMTP id nB3M9hl2014099; Thu, 3 Dec 2009 16:09:43 -0600 (CST) Received: from qtdenexhtm20.AD.QINTRA.COM (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.0/8.14.0) with ESMTP id nB3M9ZT1008001; Thu, 3 Dec 2009 15:09:38 -0700 (MST) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm20.AD.QINTRA.COM ([151.119.91.229]) with mapi; Thu, 3 Dec 2009 15:09:36 -0700 From: "Smith, Donald" To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" , Lars Eggert , Eric Rescorla Content-Class: urn:content-classes:message Date: Thu, 3 Dec 2009 15:09:27 -0700 Thread-Topic: [tcpm] closing WGLC for TCP-AO Thread-Index: Acp0V0wiRU3kew2pRdWA2bHqf48XOQACJ2coAAArUyoAAEpmQAAA3JHUAAAFKKg= Message-ID: <96E9340E-84DA-4D5A-9987-7E2070396153@mimectl> References: <500C5C63-E2E9-41C4-8971-8D7B8F2B0CA7@nokia.com> <20091203190705.078676C4A31@kilo.networkresonance.com>, <79B69D7B-66E5-4904-B97C-73638B8AF780@nokia.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-mimectl: Produced By Microsoft Exchange V8.1.348.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] closing WGLC 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: Thu, 03 Dec 2009 22:09:53 -0000 No sorry I wasn't clear this is just related to the connectionless reset is= sue. Not related to NAT inclusion at this time. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com ________________________________ From: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] [wesley.m.eddy@nasa.g= ov] Sent: Thursday, December 03, 2009 2:47 PM To: Smith, Donald; Lars Eggert; Eric Rescorla Cc: tcpm@ietf.org; Joe Touch Subject: RE: [tcpm] closing WGLC for TCP-AO Just to clarify, your reply isn't objecting to the decision to not include NAT extensions, is it? Based on the second line, it seems to be about the thread Joe is trying to converge with you on: http://www.ietf.org/mail-archive/web/tcpm/current/msg05058.html Are his proposals there about noting the issue and how it can be addressed via BGP graceful restart reasonable? -- Wes Eddy MTI Systems >-----Original Message----- >From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of >Smith, Donald >Sent: Thursday, December 03, 2009 4:36 PM >To: Lars Eggert; Eric Rescorla >Cc: tcpm@ietf.org; Joe Touch >Subject: Re: [tcpm] closing WGLC for TCP-AO > >I object to this due to concerns previously expressed specifically >connectionless resets =3D=3D spoofed resets. > >(coffee !=3D sleep) & (!coffee =3D=3D sleep) > Donald.Smith@qwest.com >________________________________ >From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of Lars >Eggert [lars.eggert@nokia.com] >Sent: Thursday, December 03, 2009 1:28 PM >To: Eric Rescorla >Cc: Joe Touch; tcpm@ietf.org >Subject: Re: [tcpm] closing WGLC for TCP-AO > >Hi, > >On 2009-12-3, at 9:07, Eric Rescorla wrote: >> This does not apply to the NAT document, AFAIK. TCP-MD5 does not >support >> NATs. It's purely a feature enhancement. I don't see why it needs to >> be rushed, and in view of the evident security problems, published >> at all. > >agreed. For the NAT stuff, I sent an earlier message (during WGLC). >Based on the current discussion, it's not clear that it can be added >quickly, because it seems to require some more discussion. > >Begin forwarded message: >> From: "Eggert Lars (Nokia-NRC/Espoo)" >> Date: November 23, 2009 8:50:37 HST >> To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" > >> Cc: "tcpm@ietf.org" , Joe Touch >> Subject: Re: [tcpm] working group status 11/17/09 >> >> Hi, >> >> without wearing any hats: if it can be added very quickly, i.e., >O(days), I'd be mildly in favor. Otherwise, let's just ship what we have >now. >> >> Lars > >Lars > >________________________________ >This communication is the property of Qwest and may contain confidential >or >privileged information. Unauthorized use of this communication is >strictly >prohibited and may be unlawful. If you have received this communication >in error, please immediately notify the sender by reply e-mail and >destroy >all copies of the communication and any attachments. >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www.ietf.org/mailman/listinfo/tcpm ________________________________ This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From perfgeek@mac.com Thu Dec 3 19:38: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 C3CFD3A6886 for ; Thu, 3 Dec 2009 19:38:37 -0800 (PST) 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 Npr26nDIvHmY for ; Thu, 3 Dec 2009 19:38:36 -0800 (PST) Received: from asmtpout012.mac.com (asmtpout012.mac.com [17.148.16.87]) by core3.amsl.com (Postfix) with ESMTP id 0022F3A67F6 for ; Thu, 3 Dec 2009 19:38:30 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [192.168.1.101] (76-220-56-223.lightspeed.sntcca.sbcglobal.net [76.220.56.223]) by asmtp012.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KU30014RZFX9Z80@asmtp012.mac.com> for tcpm@ietf.org; Thu, 03 Dec 2009 19:38:22 -0800 (PST) Message-id: From: rick jones To: Lars Eggert In-reply-to: Date: Thu, 03 Dec 2009 19:38:21 -0800 References: <4B164C00.3060509@ripe.net> X-Mailer: Apple Mail (2.936) Cc: "tcpm@ietf.org WG" , "ippm-chairs@tools.ietf.org chair" Subject: Re: [tcpm] Fwd: [ippm] WG interest in draft-constantine-ippm-tcp-throughput-tm-00.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, 04 Dec 2009 03:38:37 -0000 On Dec 3, 2009, at 9:15 AM, Lars Eggert wrote: > Hi, TCPM, > > you might want to voice your opinion on the IPPM list on this > proposed work item. If they take it on, TCPM will probably > occasionally be asked to comment on the ongoing work. I need to go back and look at it again more closely, but thus far my only comment would be the draft seems to have an overly expressed fondness for iperf :) rick jones http://www.netperf.org/ Wisdom teeth are impacted, people are affected by the effects of events From touch@ISI.EDU Thu Dec 3 22:43:20 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 561E63A6932 for ; Thu, 3 Dec 2009 22:43:20 -0800 (PST) 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 gOfpnoIH0K2D for ; Thu, 3 Dec 2009 22:43:18 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 61DEB3A68B3 for ; Thu, 3 Dec 2009 22:43:18 -0800 (PST) Received: from [75.211.53.25] (25.sub-75-211-53.myvzw.com [75.211.53.25]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id nB46g9Oj002698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 Dec 2009 22:42:12 -0800 (PST) Message-ID: <4B18AF3F.1000208@isi.edu> Date: Thu, 03 Dec 2009 22:42:07 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Lars Eggert References: <500C5C63-E2E9-41C4-8971-8D7B8F2B0CA7@nokia.com> <20091203190705.078676C4A31@kilo.networkresonance.com> <79B69D7B-66E5-4904-B97C-73638B8AF780@nokia.com> In-Reply-To: <79B69D7B-66E5-4904-B97C-73638B8AF780@nokia.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MailScanner-ID: nB46g9Oj002698 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] closing WGLC 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: Fri, 04 Dec 2009 06:43:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lars Eggert wrote: > Hi, > > On 2009-12-3, at 9:07, Eric Rescorla wrote: >> This does not apply to the NAT document, AFAIK. TCP-MD5 does not support >> NATs. It's purely a feature enhancement. That could be said of key changeover coordination, establishment of per-connection ISN-based traffic keys, or even the idea of agile algorithms. These are all things we added *because they weren't in TCP MD5*. >> I don't see why it needs to >> be rushed, and in view of the evident security problems, published >> at all. I'd like to take some time on the list to discuss these, because so far all that has been claimed is that the traffic keys are somewhat weaker, but not necessarily weak enough to present a real issue yet. I.e., I don't want to rush to put this in, but I don't see why we would rush to keep it out either. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksYrz8ACgkQE5f5cImnZrs+NgCeO/r96odyLabjArBOvP7NgMfZ /A0An3q86VK/pk8LBerDJc8qYeKlVmw2 =YvjI -----END PGP SIGNATURE----- From ekr@networkresonance.com Fri Dec 4 07:12: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 11A7E3A6894 for ; Fri, 4 Dec 2009 07:12:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.347 X-Spam-Level: X-Spam-Status: No, score=0.347 tagged_above=-999 required=5 tests=[AWL=-0.271, 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, J_CHICKENPOX_19=0.6, 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 C23jGKKHmJaS for ; Fri, 4 Dec 2009 07:12:56 -0800 (PST) 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 C06BD3A684A for ; Fri, 4 Dec 2009 07:12:53 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id C58536C4C6F; Fri, 4 Dec 2009 07:14:10 -0800 (PST) Date: Fri, 04 Dec 2009 07:14:10 -0800 From: Eric Rescorla To: Joe Touch In-Reply-To: <4B181058.60104@isi.edu> References: <20091203032738.3F7B86C489B@kilo.networkresonance.com> <4B173270.70403@isi.edu> <20091203050652.585F86C495F@kilo.networkresonance.com> <4B174E92.2030702@isi.edu> <20091203173612.9C20A6C49F7@kilo.networkresonance.com> <4B18001A.9070600@isi.edu> <20091203185321.E22976C4A23@kilo.networkresonance.com> <4B181058.60104@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: <20091204151410.C58536C4C6F@kilo.networkresonance.com> Cc: "tcpm@ietf.org" Subject: Re: [tcpm] closing WGLC 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: Fri, 04 Dec 2009 15:12:57 -0000 At Thu, 03 Dec 2009 11:24:08 -0800, Joe Touch wrote: > > You misunderstand the 1948 algorithm, which simply adds a random > > (but fixed for each socketpair) offset to the ISN sequence: > > > > ISN = M + F(localhost, localport, remotehost, remoteport). > > > > Repeated probes indeed to produce ISNs in a specific sequence. > > M is a 4ms timer. You'd need the timer to wrap around. Can you explan > why you think this presents a vulnerability? But again, you don't. You just scatter around the source address/port space until you find a reply ISN within a reasonable time of where you want to be and then you wait. Remember that you have 16 bits of port to play with, so you can generally get a starting point within 65k timer ticks. > Further F is intended to include more than just the presented arguments: > > It is vital that F not be computable from the outside, or an attacker > could still guess at sequence numbers from the initial sequence > number used for some other connection. We therefore suggest that F > be a cryptographic hash function of the connection-id and some secret > data. MD5 [9] is a good choice, since the code is widely available. > The secret data can either be a true random number [10], or it can be > the combination of some per-host secret and the boot time of the > machine. The boot time is included to ensure that the secret is > changed on occasion. Other data, such as the host's IP address and > name, may be included in the hash as well; this eases administration > by permitting a network of workstations to share the same secret data > while still giving them separate sequence number spaces. Our > recommendation, in fact, is to use all three of these items: as > random a number as the hardware can generate, an administratively- > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > installed pass phrase, and the machine's IP address. This allows for > local choice on how secure the secret is. > > This would not be repeatable for a given set of inputs. Again, this produces a secret *offset* to the ordinary timer. Otherwise, you couldn't guarantee timer monotonicity for a given connection_id. > >> A client could easily detect an attempt of such an attack because it > >> would involve repeated receipt of a SYN with the same socket pair and > >> the same ISN - I would hope that an alarm could go off before 2^32 were > >> tried. > > > > I prefer to have my security based on something other than hope. > > Would a recommendation (SHOULD) to put in an "excessive repeated SYN" > alarm be sufficient? This seems like a nontrivial recommendation to follow. > >> So basically we're relying on the entropy of the ISNs anyway. > > > > Yes, AO relies on the entropy of the ISNs but the security guarantees > > in case they are weak are much better than with this draft. > > This is the crux of your argument - that ISNs alone are insufficient, > but you haven't shown how adding the addrs and ports really adds much. > In fact, it was *you* who suggested adding the ISNs (see your post of > 3/11/2008 to the design team), and *you* who is pointing out that the > addrs/ports don't add entropy. > > By your argument, TCP-AO isn't as secure as you'd like (which may be the > case), but TCP-AO with NAT isn't substantially *less* secure. TCP-AO isn't as secure as I would like. I thought I made that pretty clear from the beginning. However, the consequences of TCP-AO repeats only include retransmitting packets within a given connection. That's not true here. Stepping up a level: I don't understand what the motivation for this is: TCP-AO is basically good for a fairly limited set of use cases where people are worried about DoS and so they can't use TLS and they feel IPsec is too heavyweight. To my knowledge, that set consists of basically one application: BGP connections. What are the large set of behind-NAT applications which have a need for TCP-AO? -Ekr From touch@ISI.EDU Fri Dec 4 13:26: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 836D93A6949 for ; Fri, 4 Dec 2009 13:26:59 -0800 (PST) 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 mMO18wnRQM2Q for ; Fri, 4 Dec 2009 13:26:58 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id D27E33A67F3 for ; Fri, 4 Dec 2009 13:26:58 -0800 (PST) Received: from [75.209.133.24] (24.sub-75-209-133.myvzw.com [75.209.133.24]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id nB4LPxkU003630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 4 Dec 2009 13:26:02 -0800 (PST) Message-ID: <4B197E64.70509@isi.edu> Date: Fri, 04 Dec 2009 13:25:56 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Eric Rescorla References: <20091203032738.3F7B86C489B@kilo.networkresonance.com> <4B173270.70403@isi.edu> <20091203050652.585F86C495F@kilo.networkresonance.com> <4B174E92.2030702@isi.edu> <20091203173612.9C20A6C49F7@kilo.networkresonance.com> <4B18001A.9070600@isi.edu> <20091203185321.E22976C4A23@kilo.networkresonance.com> <4B181058.60104@isi.edu> <20091204151410.C58536C4C6F@kilo.networkresonance.com> In-Reply-To: <20091204151410.C58536C4C6F@kilo.networkresonance.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MailScanner-ID: nB4LPxkU003630 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] closing WGLC 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: Fri, 04 Dec 2009 21:26:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Eric, It might be useful to separate the issues you're raising: - - concerns about ISN entropy - - concerns about whether NAT support is needed If NATs are supported, it seems like we're just at the mercy of the entropy of the ISNs no matter what we do anyway. So there are two options, AFAICT: 1. include support for NATs 2. do NOT include support for NATs The second case means that NATs are not protectable at all using TCP-AO. However, TCP-AO has been intended as supporting general use all along; this isn't just about any known current uses. I don't see why we should prohibit this, unless we believe it would compromise non-NAT connections. Can we cover this concern with some directives, e.g.: (if you prefer a different directive, please suggest one): NAT support MUST NOT change on a given connection, i.e., the MKT used at connection start either supports NAT or not, and that support MUST match subsequent MKTs used with that connection. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksZfmMACgkQE5f5cImnZrspNACfXu55CRMfNqXvLeGmhqmqbrrj y28AoK9Q2p2i9LB3Ez7CrhUITUKM1csi =X5Uw -----END PGP SIGNATURE----- From dwing@cisco.com Fri Dec 4 16:14: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 730653A6867 for ; Fri, 4 Dec 2009 16:14:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.384 X-Spam-Level: X-Spam-Status: No, score=-6.384 tagged_above=-999 required=5 tests=[AWL=0.215, 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 R8X+ZMAs20MM for ; Fri, 4 Dec 2009 16:14:08 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 7B4183A679C for ; Fri, 4 Dec 2009 16:14:08 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAB80GUurRN+K/2dsb2JhbACKJLR6lyuEMwSNHw X-IronPort-AV: E=Sophos;i="4.47,344,1257120000"; d="scan'208";a="72130896" Received: from sj-core-4.cisco.com ([171.68.223.138]) by rtp-iport-1.cisco.com with ESMTP; 05 Dec 2009 00:13:54 +0000 Received: from dwingwxp01 ([10.32.240.195]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nB50DuqG021586; Sat, 5 Dec 2009 00:13:56 GMT From: "Dan Wing" To: "'Eric Rescorla'" , "'Joe Touch'" References: <20091203032738.3F7B86C489B@kilo.networkresonance.com><4B173270.70403@isi.edu><20091203050652.585F86C495F@kilo.networkresonance.com><4B174E92.2030702@isi.edu><20091203173612.9C20A6C49F7@kilo.networkresonance.com><4B18001A.9070600@isi.edu><20091203185321.E22976C4A23@kilo.networkresonance.com><4B181058.60104@isi.edu> <20091204151410.C58536C4C6F@kilo.networkresonance.com> Date: Fri, 4 Dec 2009 16:13:53 -0800 Message-ID: <057e01ca753f$d45cee50$5ba36b80@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acp09E3T8F37zl/lSl6+sRk+Xca9kwASxZ0w In-Reply-To: <20091204151410.C58536C4C6F@kilo.networkresonance.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: tcpm@ietf.org Subject: Re: [tcpm] closing WGLC 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, 05 Dec 2009 00:14:09 -0000 ... > Stepping up a level: I don't understand what the motivation > for this is: TCP-AO is basically good for a fairly limited set > of use cases where people are worried about DoS and so they > can't use TLS and they feel IPsec is too heavyweight. To my > knowledge, that set consists of basically one application: BGP > connections. What are the large set of behind-NAT applications > which have a need for TCP-AO? TCP-AO could be useful for long-lived connections from applications like SIP or XMPP. Those TCP clients are often behind NATs. Today, it also isn't that IPsec is 'too heavy'; applications are unaware of IPsec is providing encryption underneath the application. The new IPsec API would fix that - once it's available. At which point we would be back to just the 'IPsec is heavy' complaint, think. -d From ekr@networkresonance.com Sat Dec 5 08:38: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 CE75A3A6930 for ; Sat, 5 Dec 2009 08:38:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.056 X-Spam-Level: X-Spam-Status: No, score=0.056 tagged_above=-999 required=5 tests=[AWL=0.038, 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 aHFQhIDpE21k for ; Sat, 5 Dec 2009 08:38:15 -0800 (PST) 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 26B613A68F6 for ; Sat, 5 Dec 2009 08:38:15 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 0BCE16C4E6C; Sat, 5 Dec 2009 08:39:37 -0800 (PST) Date: Sat, 05 Dec 2009 08:39:36 -0800 From: Eric Rescorla To: "Dan Wing" In-Reply-To: <057e01ca753f$d45cee50$5ba36b80@cisco.com> References: <20091203032738.3F7B86C489B@kilo.networkresonance.com> <4B173270.70403@isi.edu> <20091203050652.585F86C495F@kilo.networkresonance.com> <4B174E92.2030702@isi.edu> <20091203173612.9C20A6C49F7@kilo.networkresonance.com> <4B18001A.9070600@isi.edu> <20091203185321.E22976C4A23@kilo.networkresonance.com> <4B181058.60104@isi.edu> <20091204151410.C58536C4C6F@kilo.networkresonance.com> <057e01ca753f$d45cee50$5ba36b80@cisco.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: <20091205163938.0BCE16C4E6C@kilo.networkresonance.com> Cc: tcpm@ietf.org, 'Joe Touch' Subject: Re: [tcpm] closing WGLC 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, 05 Dec 2009 16:38:16 -0000 At Fri, 4 Dec 2009 16:13:53 -0800, Dan Wing wrote: > > ... > > Stepping up a level: I don't understand what the motivation > > for this is: TCP-AO is basically good for a fairly limited set > > of use cases where people are worried about DoS and so they > > can't use TLS and they feel IPsec is too heavyweight. To my > > knowledge, that set consists of basically one application: BGP > > connections. What are the large set of behind-NAT applications > > which have a need for TCP-AO? > > TCP-AO could be useful for long-lived connections from applications > like SIP or XMPP. Those TCP clients are often behind NATs. Those applications use TLS. I am unaware of any widespread demand that those applications have for resistance to connection level termination resistance. -Ekr From dwing@cisco.com Sat Dec 5 11:44: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 0DD303A6856 for ; Sat, 5 Dec 2009 11:44:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.389 X-Spam-Level: X-Spam-Status: No, score=-6.389 tagged_above=-999 required=5 tests=[AWL=0.210, 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 rWzrCM2hhKrD for ; Sat, 5 Dec 2009 11:44:39 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id BA45B3A677D for ; Sat, 5 Dec 2009 11:44:39 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYFAM9GGkurRN+K/2dsb2JhbACIfoEWtCaWZYQzBA X-IronPort-AV: E=Sophos;i="4.47,347,1257120000"; d="scan'208";a="114675538" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 05 Dec 2009 19:44:30 +0000 Received: from dwingwxp01 ([10.32.240.195]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nB5JiUAh025262; Sat, 5 Dec 2009 19:44:30 GMT From: "Dan Wing" To: "'Eric Rescorla'" References: <20091203032738.3F7B86C489B@kilo.networkresonance.com><4B173270.70403@isi.edu><20091203050652.585F86C495F@kilo.networkresonance.com><4B174E92.2030702@isi.edu><20091203173612.9C20A6C49F7@kilo.networkresonance.com><4B18001A.9070600@isi.edu><20091203185321.E22976C4A23@kilo.networkresonance.com><4B181058.60104@isi.edu><20091204151410.C58536C4C6F@kilo.networkresonance.com><057e01ca753f$d45cee50$5ba36b80@cisco.com> <20091205163938.0BCE16C4E6C@kilo.networkresonance.com> Date: Sat, 5 Dec 2009 11:44:30 -0800 Message-ID: <062e01ca75e3$5ccf5cc0$5ba36b80@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acp1yVIdFv3TseM0Qdi278rzU7DfPgAGc1rw In-Reply-To: <20091205163938.0BCE16C4E6C@kilo.networkresonance.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: tcpm@ietf.org, 'Joe Touch' Subject: Re: [tcpm] closing WGLC 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, 05 Dec 2009 19:44:41 -0000 > At Fri, 4 Dec 2009 16:13:53 -0800, > Dan Wing wrote: > > > > ... > > > Stepping up a level: I don't understand what the motivation > > > for this is: TCP-AO is basically good for a fairly limited set > > > of use cases where people are worried about DoS and so they > > > can't use TLS and they feel IPsec is too heavyweight. To my > > > knowledge, that set consists of basically one application: BGP > > > connections. What are the large set of behind-NAT applications > > > which have a need for TCP-AO? > > > > TCP-AO could be useful for long-lived connections from applications > > like SIP or XMPP. Those TCP clients are often behind NATs. > > Those applications use TLS. I am unaware of any widespread > demand that those applications have for resistance to connection > level termination resistance. I am also unaware of widespread demand. However, extending TCP-AO to support NAT, so that TLS can benefit from the same sort of protection as DTLS, seems like it would create that demand. Those applications are unlikely to switch to IPsec-over-UDP merely to gain such functionality. -d From ananth@cisco.com Mon Dec 7 23:25: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 7862E3A6995 for ; Mon, 7 Dec 2009 23:25:37 -0800 (PST) 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 pFLx1VAEn9IS for ; Mon, 7 Dec 2009 23:25:36 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 9842F3A67FA for ; Mon, 7 Dec 2009 23:25:36 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOiNHUurRN+J/2dsb2JhbADAdpZ6hDIEjSM X-IronPort-AV: E=Sophos;i="4.47,360,1257120000"; d="scan'208";a="115799084" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 08 Dec 2009 07:25:26 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nB87PQAT022001; Tue, 8 Dec 2009 07:25:26 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Dec 2009 23:25:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Dec 2009 23:25:24 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC580884B4FB@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <20091204151410.C58536C4C6F@kilo.networkresonance.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] closing WGLC for TCP-AO Thread-Index: Acp09E6UWHnFizwETdiMa4CSTs/mPAC4meYA References: <20091203032738.3F7B86C489B@kilo.networkresonance.com><4B173270.70403@isi.edu><20091203050652.585F86C495F@kilo.networkresonance.com><4B174E92.2030702@isi.edu><20091203173612.9C20A6C49F7@kilo.networkresonance.com><4B18001A.9070600@isi.edu><20091203185321.E22976C4A23@kilo.networkresonance.com><4B181058.60104@isi.edu> <20091204151410.C58536C4C6F@kilo.networkresonance.com> From: "Anantha Ramaiah (ananth)" To: "Eric Rescorla" , "Joe Touch" X-OriginalArrivalTime: 08 Dec 2009 07:25:26.0294 (UTC) FILETIME=[9CA0D360:01CA77D7] Cc: tcpm@ietf.org Subject: Re: [tcpm] closing WGLC 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: Tue, 08 Dec 2009 07:25:37 -0000 [catching up again] > > Stepping up a level: I don't understand what the motivation=20 > for this is: > TCP-AO is basically good for a fairly limited set of use cases where > people are worried about DoS and so they can't use TLS and they feel > IPsec is too heavyweight. To my knowledge, that set consists=20 > of basically > one application: BGP connections. Exactly, this is the point which I was trying to emphasize as well when I suggested an explicit "Applicability statement" to be put in place. This gives advice/guidance to implementers as to why and when TCP-AO should be used. TCP-secure draft has an AS put in place for similar reasons. I don't see why we should not put an AS for TCP-AO whose usage (practically speaking) is fairly restricted? > What are the large set of behind-NAT > applications which have a need for TCP-AO? None, to my knowledge. -Anantha >=20 > -Ekr > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 From Donald.Smith@qwest.com Tue Dec 8 07:50: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 99A9628C162 for ; Tue, 8 Dec 2009 07:50:07 -0800 (PST) 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 IH8sGrLe8kgf for ; Tue, 8 Dec 2009 07:50:06 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by core3.amsl.com (Postfix) with ESMTP id 7C0F128C15B for ; Tue, 8 Dec 2009 07:50:06 -0800 (PST) Received: from suomp60i.qintra.com (suomp60i.qintra.com [151.117.69.27]) by sudnp799.qwest.com (8.14.0/8.14.0) with ESMTP id nB8Fnska001592; Tue, 8 Dec 2009 08:49:54 -0700 (MST) Received: from qtdenexhtm21.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.0/8.14.0) with ESMTP id nB8FnmMU009282; Tue, 8 Dec 2009 09:49:48 -0600 (CST) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm21.AD.QINTRA.COM ([151.119.91.230]) with mapi; Tue, 8 Dec 2009 08:49:48 -0700 From: "Smith, Donald" To: "Anantha Ramaiah (ananth)" , Eric Rescorla , Joe Touch Content-Class: urn:content-classes:message Date: Tue, 8 Dec 2009 08:49:44 -0700 Thread-Topic: [tcpm] closing WGLC for TCP-AO Thread-Index: Acp09E6UWHnFizwETdiMa4CSTs/mPAC4meYAABGUwNgAAEGteA== Message-ID: <0D048097-25EE-4946-9C88-B0E699EE8EC4@mimectl> References: <20091203032738.3F7B86C489B@kilo.networkresonance.com><4B173270.70403@isi.edu><20091203050652.585F86C495F@kilo.networkresonance.com><4B174E92.2030702@isi.edu><20091203173612.9C20A6C49F7@kilo.networkresonance.com><4B18001A.9070600@isi.edu><20091203185321.E22976C4A23@kilo.networkresonance.com><4B181058.60104@isi.edu> <20091204151410.C58536C4C6F@kilo.networkresonance.com>, <0C53DCFB700D144284A584F54711EC580884B4FB@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC580884B4FB@xmb-sjc-21c.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-mimectl: Produced By Microsoft Exchange V8.1.348.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] closing WGLC 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: Tue, 08 Dec 2009 15:50:07 -0000 Until Connection_less_resets !=3D Spoofed_resets I know a lot of people can't use this for bgp which seems to be one of the = main reasons this was written. In a separate email with Joe, I recommended a SHOULD for "maintain enough s= tate across reboot to be able to send authenticated resets". Not a MUST but as a SHOULD or even a MAY then engine= ers can point to the standard and in their RFC process require this state a= cross reboot if they need it. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com ________________________________ From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of Anantha Ra= maiah (ananth) [ananth@cisco.com] Sent: Tuesday, December 08, 2009 12:25 AM To: Eric Rescorla; Joe Touch Cc: tcpm@ietf.org Subject: Re: [tcpm] closing WGLC for TCP-AO [catching up again] > > Stepping up a level: I don't understand what the motivation > for this is: > TCP-AO is basically good for a fairly limited set of use cases where > people are worried about DoS and so they can't use TLS and they feel > IPsec is too heavyweight. To my knowledge, that set consists > of basically > one application: BGP connections. Exactly, this is the point which I was trying to emphasize as well when I suggested an explicit "Applicability statement" to be put in place. This gives advice/guidance to implementers as to why and when TCP-AO should be used. TCP-secure draft has an AS put in place for similar reasons. I don't see why we should not put an AS for TCP-AO whose usage (practically speaking) is fairly restricted? > What are the large set of behind-NAT > applications which have a need for TCP-AO? None, to my knowledge. -Anantha > > -Ekr > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm ________________________________ This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From fernando.gont.netbook.win@gmail.com Tue Dec 8 12:29: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 9C8D63A68CB for ; Tue, 8 Dec 2009 12:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[AWL=0.298, 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 DZW7EB9FfLfb for ; Tue, 8 Dec 2009 12:29:25 -0800 (PST) Received: from mail-yw0-f111.google.com (mail-yw0-f111.google.com [209.85.211.111]) by core3.amsl.com (Postfix) with ESMTP id A70E53A68C2 for ; Tue, 8 Dec 2009 12:29:25 -0800 (PST) Received: by ywh9 with SMTP id 9so617702ywh.18 for ; Tue, 08 Dec 2009 12:29:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=SIUwxC6u6YmD1whcH6u9L98GabBeaniCVSZalhKzusc=; b=GhgJSjB10Crzw9WQKCbUql7McSRPNjP1N0JbC87bbgp3M2PGIRI+/X5ndtBdQCd4Zr dx3i3YKHPd1W1CQWArt4Ba5u+JH7MusuP9ynIOThga46DBdydYbgSnXZAcEGCmloOMly xyGa/hWZT4f3YjHYa/jR1Wooh5XOxpUm4Akq0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=NesrupJvExwlmavwVDhxrkXbILJ5haNg8AO35t+7EjHh7iSBKmEiOWx89OfYYdwxmd +OPJ9WBp3KGsTjqRdbU+w2Jfj+UHsKxNYfVmHVj5GdwJYAw6DW/zOxt9qncGEk4c0tc4 9HGct2wXKv+/qUge07LAg2x42jeIdNDFFIL6o= Received: by 10.151.88.28 with SMTP id q28mr14600029ybl.337.1260304150270; Tue, 08 Dec 2009 12:29:10 -0800 (PST) Received: from ?192.168.1.100? (205-133-17-190.fibertel.com.ar [190.17.133.205]) by mx.google.com with ESMTPS id 4sm2521222ywd.44.2009.12.08.12.29.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 08 Dec 2009 12:29:09 -0800 (PST) Sender: Fernando Gont Message-ID: <4B1EB713.3080307@gont.com.ar> Date: Tue, 08 Dec 2009 17:29:07 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <20091203032738.3F7B86C489B@kilo.networkresonance.com><4B173270.70403@isi.edu><20091203050652.585F86C495F@kilo.networkresonance.com><4B174E92.2030702@isi.edu><20091203173612.9C20A6C49F7@kilo.networkresonance.com><4B18001A.9070600@isi.edu><20091203185321.E22976C4A23@kilo.networkresonance.com><4B181058.60104@isi.edu> <20091204151410.C58536C4C6F@kilo.networkresonance.com> <0C53DCFB700D144284A584F54711EC580884B4FB@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC580884B4FB@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org, Joe Touch Subject: Re: [tcpm] closing WGLC 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: Tue, 08 Dec 2009 20:29:26 -0000 Anantha Ramaiah (ananth) wrote: > Exactly, this is the point which I was trying to emphasize as well when > I suggested an explicit "Applicability statement" to be put in place. > This gives advice/guidance to implementers as to why and when TCP-AO > should be used. TCP-secure draft has an AS put in place for similar > reasons. I don't see why we should not put an AS for TCP-AO whose usage > (practically speaking) is fairly restricted? Actually, not including an AS in TCP-AO would be rather ironic. We have an AS in tcp-secure, which describes mitigations every real-world stack wants to have enabled. Therefore, not having an AS in TCP-AO (whose usage is fairly restricted) would be "incongruent". 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 wesley.m.eddy@nasa.gov Tue Dec 8 12:42: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 F0DDD3A68EC for ; Tue, 8 Dec 2009 12:41:59 -0800 (PST) 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 JCE8pmCRlHYS for ; Tue, 8 Dec 2009 12:41:59 -0800 (PST) Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by core3.amsl.com (Postfix) with ESMTP id 01D2E3A67B1 for ; Tue, 8 Dec 2009 12:41:58 -0800 (PST) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 3EA331480E2; Tue, 8 Dec 2009 14:41:48 -0600 (CST) Received: from ndjshub02.ndc.nasa.gov (ndjshub02-pub.ndc.nasa.gov [198.117.1.161]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id nB8KfcsE001069; Tue, 8 Dec 2009 14:41:47 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub02.ndc.nasa.gov ([198.117.1.161]) with mapi; Tue, 8 Dec 2009 14:41:43 -0600 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: Fernando Gont , "Anantha Ramaiah (ananth)" Date: Tue, 8 Dec 2009 14:41:42 -0600 Thread-Topic: [tcpm] closing WGLC for TCP-AO Thread-Index: Acp4RSDnSsKY+hh9QGeRRnpLq7ix9gAANspQ Message-ID: References: <20091203032738.3F7B86C489B@kilo.networkresonance.com><4B173270.70403@isi.edu><20091203050652.585F86C495F@kilo.networkresonance.com><4B174E92.2030702@isi.edu><20091203173612.9C20A6C49F7@kilo.networkresonance.com><4B18001A.9070600@isi.edu><20091203185321.E22976C4A23@kilo.networkresonance.com><4B181058.60104@isi.edu> <20091204151410.C58536C4C6F@kilo.networkresonance.com> <0C53DCFB700D144284A584F54711EC580884B4FB@xmb-sjc-21c.amer.cisco.com> <4B1EB713.3080307@gont.com.ar> In-Reply-To: <4B1EB713.3080307@gont.com.ar> 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.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-12-08_08:2009-11-30, 2009-12-08, 2009-12-08 signatures=0 Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] closing WGLC 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: Tue, 08 Dec 2009 20:42:00 -0000 I think we could pretty easily craft an applicability statement; the essence of one is already started in the abstract: 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. So we'd just need to flesh that out in a new section for an Applicability Statement and be more explicit about how IPsec and TLS relate (or don't), which the Introduction already partially covers too. What do you think Joe? -- Wes Eddy MTI Systems >-----Original Message----- >From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of >Fernando Gont >Sent: Tuesday, December 08, 2009 3:29 PM >To: Anantha Ramaiah (ananth) >Cc: tcpm@ietf.org; Joe Touch >Subject: Re: [tcpm] closing WGLC for TCP-AO > >Anantha Ramaiah (ananth) wrote: > >> Exactly, this is the point which I was trying to emphasize as well >when >> I suggested an explicit "Applicability statement" to be put in place. >> This gives advice/guidance to implementers as to why and when TCP-AO >> should be used. TCP-secure draft has an AS put in place for similar >> reasons. I don't see why we should not put an AS for TCP-AO whose >usage >> (practically speaking) is fairly restricted? > >Actually, not including an AS in TCP-AO would be rather ironic. > >We have an AS in tcp-secure, which describes mitigations every >real-world stack wants to have enabled. > >Therefore, not having an AS in TCP-AO (whose usage is fairly restricted) >would be "incongruent". > >Thanks, >-- >Fernando Gont >e-mail: fernando@gont.com.ar || fgont@acm.org >PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www.ietf.org/mailman/listinfo/tcpm From touch@ISI.EDU Tue Dec 8 13:21: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 49AEB3A693B for ; Tue, 8 Dec 2009 13:21:00 -0800 (PST) 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 UMIbgG11Yf6x for ; Tue, 8 Dec 2009 13:20:59 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 615463A691C for ; Tue, 8 Dec 2009 13:20:59 -0800 (PST) Received: from [10.2.4.232] (usfws1.systemmetrics.com [66.135.227.114]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nB8LK8JD024672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Dec 2009 13:20:14 -0800 (PST) Message-ID: <4B1EC307.3060207@isi.edu> Date: Tue, 08 Dec 2009 13:20:07 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" References: <20091203032738.3F7B86C489B@kilo.networkresonance.com><4B173270.70403@isi.edu><20091203050652.585F86C495F@kilo.networkresonance.com><4B174E92.2030702@isi.edu><20091203173612.9C20A6C49F7@kilo.networkresonance.com><4B18001A.9070600@isi.edu><20091203185321.E22976C4A23@kilo.networkresonance.com><4B181058.60104@isi.edu> <20091204151410.C58536C4C6F@kilo.networkresonance.com> <0C53DCFB700D144284A584F54711EC580884B4FB@xmb-sjc-21c.amer.cisco.com> <4B1EB713.3080307@gont.com.ar> 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" , "Anantha Ramaiah \(ananth\)" , Fernando Gont Subject: Re: [tcpm] closing WGLC 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: Tue, 08 Dec 2009 21:21:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote: > I think we could pretty easily craft an applicability > statement; the essence of one is already started in the > abstract: > > 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. > > So we'd just need to flesh that out in a new section > for an Applicability Statement and be more explicit > about how IPsec and TLS relate (or don't), which the > Introduction already partially covers too. > > What do you think Joe? I think this is all about two things: - - the desire for a header before the paragraph below that actually says "Applicability Statement": 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]. - - the desire for one more sentence or two explaining the difference between TCP-AO and TLS - - the desire to move the some (or all) of the discussion in 2.1 into the AS section This is all easy to do. However, I would not assume that this would say "use TCP-AO only for BGP". Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksewwcACgkQE5f5cImnZru5XACgrgAW2GMW7DRTbaSVEeV7RGLg 63gAn37+mWOILqRlX5CCXuB6NVwwzJ38 =aQOR -----END PGP SIGNATURE----- From touch@ISI.EDU Tue Dec 8 13:26: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 B430C3A699D for ; Tue, 8 Dec 2009 13:26:59 -0800 (PST) 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 ROvGOs-pSBzX for ; Tue, 8 Dec 2009 13:26:59 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id A6C823A694A for ; Tue, 8 Dec 2009 13:26:58 -0800 (PST) Received: from [10.2.4.232] (usfws1.systemmetrics.com [66.135.227.114]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nB8LP6Zr025775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Dec 2009 13:25:17 -0800 (PST) Message-ID: <4B1EC431.90105@isi.edu> Date: Tue, 08 Dec 2009 13:25:05 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Joe Touch References: <20091203032738.3F7B86C489B@kilo.networkresonance.com><4B173270.70403@isi.edu><20091203050652.585F86C495F@kilo.networkresonance.com><4B174E92.2030702@isi.edu><20091203173612.9C20A6C49F7@kilo.networkresonance.com><4B18001A.9070600@isi.edu><20091203185321.E22976C4A23@kilo.networkresonance.com><4B181058.60104@isi.edu> <20091204151410.C58536C4C6F@kilo.networkresonance.com> <0C53DCFB700D144284A584F54711EC580884B4FB@xmb-sjc-21c.amer.cisco.com> <4B1EB713.3080307@gont.com.ar> <4B1EC307.3060207@isi.edu> In-Reply-To: <4B1EC307.3060207@isi.edu> 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" , "Anantha Ramaiah \(ananth\)" , Fernando Gont Subject: Re: [tcpm] closing WGLC 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: Tue, 08 Dec 2009 21:26:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ... > I think this is all about two things: Before anyone jumps, yes, there were three things listed; they fall into two groups: - - wanting a header - - wanting things moved around under that header, with one additional point PS: the TLS point can trivially be made in one sentence by referring to RFC 4953. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksexDEACgkQE5f5cImnZrtGTgCeJPhg3F3wl97pSFS7bqxJYVa0 U1QAn1Fme4XHCno3/OT+1QY2EJNhcHxv =aT/1 -----END PGP SIGNATURE----- From ekr@networkresonance.com Tue Dec 8 20:55: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 3227B3A67E9 for ; Tue, 8 Dec 2009 20:55:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.054 X-Spam-Level: X-Spam-Status: No, score=0.054 tagged_above=-999 required=5 tests=[AWL=0.036, 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 UTPr2Yy1OzWH for ; Tue, 8 Dec 2009 20:55:31 -0800 (PST) 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 5EB513A67D1 for ; Tue, 8 Dec 2009 20:55:30 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 09D416C5706; Tue, 8 Dec 2009 20:57:12 -0800 (PST) Date: Tue, 08 Dec 2009 20:57:12 -0800 From: Eric Rescorla To: Joe Touch In-Reply-To: <4B1EC307.3060207@isi.edu> References: <20091203032738.3F7B86C489B@kilo.networkresonance.com> <4B173270.70403@isi.edu> <20091203050652.585F86C495F@kilo.networkresonance.com> <4B174E92.2030702@isi.edu> <20091203173612.9C20A6C49F7@kilo.networkresonance.com> <4B18001A.9070600@isi.edu> <20091203185321.E22976C4A23@kilo.networkresonance.com> <4B181058.60104@isi.edu> <20091204151410.C58536C4C6F@kilo.networkresonance.com> <0C53DCFB700D144284A584F54711EC580884B4FB@xmb-sjc-21c.amer.cisco.com> <4B1EB713.3080307@gont.com.ar> <4B1EC307.3060207@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: <20091209045713.09D416C5706@kilo.networkresonance.com> Cc: "tcpm@ietf.org" , "Anantha Ramaiah \(ananth\)" , Fernando Gont Subject: Re: [tcpm] closing WGLC 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: Wed, 09 Dec 2009 04:55:32 -0000 At Tue, 08 Dec 2009 13:20:07 -0800, Joe Touch wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote: > > I think we could pretty easily craft an applicability > > statement; the essence of one is already started in the > > abstract: > > > > 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. > > > > So we'd just need to flesh that out in a new section > > for an Applicability Statement and be more explicit > > about how IPsec and TLS relate (or don't), which the > > Introduction already partially covers too. > > > > What do you think Joe? > > I think this is all about two things: > > - - the desire for a header before the paragraph below that actually says > "Applicability Statement": > > 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]. > > - - the desire for one more sentence or two explaining the difference > between TCP-AO and TLS > > - - the desire to move the some (or all) of the discussion in 2.1 into the > AS section > > This is all easy to do. > > However, I would not assume that this would say "use TCP-AO only for BGP". I would assume not either. Rather, we should tell people what it does and let them make their own decisions about what it's good for. I would suggest something like: The primary feature that this document offers that TLS does not is that it operates at the transport layer whereas TLS operates above the transport layer. Thus, while TLS provides for data integrity it is not resistant to DoS attacks on the transport layer; in fact it is especially sensitive because any damage to the byte stream results in a MAC failure and connection termination. By contrast, TLS currently offers a far richer set of key management and authentication primitives and is thus a superior choice when DoS is not a concern. -Ekr From wesley.m.eddy@nasa.gov Tue Dec 8 22:13: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 8A11728C146 for ; Tue, 8 Dec 2009 22:13:39 -0800 (PST) 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 ib-e45hMOMRm for ; Tue, 8 Dec 2009 22:13:37 -0800 (PST) Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [198.117.1.122]) by core3.amsl.com (Postfix) with ESMTP id 7F0723A6ABA for ; Tue, 8 Dec 2009 22:13:36 -0800 (PST) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id B8C01A8035; Wed, 9 Dec 2009 00:13:24 -0600 (CST) Received: from ndjshub02.ndc.nasa.gov (ndjshub02-pub.ndc.nasa.gov [198.117.1.161]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id nB96DPXW007010; Wed, 9 Dec 2009 00:13:25 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub02.ndc.nasa.gov ([198.117.1.161]) with mapi; Wed, 9 Dec 2009 00:13:25 -0600 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: Joe Touch Date: Wed, 9 Dec 2009 00:13:23 -0600 Thread-Topic: [tcpm] closing WGLC for TCP-AO Thread-Index: Acp4TSeoLb3TLff8TZaj8sbKGE/0BQASFwZY Message-ID: References: <20091203032738.3F7B86C489B@kilo.networkresonance.com><4B173270.70403@isi.edu><20091203050652.585F86C495F@kilo.networkresonance.com><4B174E92.2030702@isi.edu><20091203173612.9C20A6C49F7@kilo.networkresonance.com><4B18001A.9070600@isi.edu><20091203185321.E22976C4A23@kilo.networkresonance.com><4B181058.60104@isi.edu> <20091204151410.C58536C4C6F@kilo.networkresonance.com> <0C53DCFB700D144284A584F54711EC580884B4FB@xmb-sjc-21c.amer.cisco.com> <4B1EB713.3080307@gont.com.ar> <4B1EC307.3060207@isi.edu>,<4B1EC431.90105@isi.edu> In-Reply-To: <4B1EC431.90105@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-12-09_04:2009-11-30, 2009-12-09, 2009-12-09 signatures=0 Cc: "tcpm@ietf.org" , "Anantha Ramaiah \(ananth\)" , Fernando Gont Subject: Re: [tcpm] closing WGLC 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: Wed, 09 Dec 2009 06:13:40 -0000 It sounds like people are asking for a clear header with the relevant text = arranged under it, since the tcpsecure document was referenced as an exampl= e. I fully agree on including a pointer to 4953; it would be good to use as a = reference following the text Eric sent. ________________________________________ From: Joe Touch [touch@ISI.EDU] Sent: Tuesday, December 08, 2009 4:25 PM To: Joe Touch Cc: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; Fernando Gont; Anantha= Ramaiah (ananth); tcpm@ietf.org Subject: Re: [tcpm] closing WGLC for TCP-AO -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ... > I think this is all about two things: Before anyone jumps, yes, there were three things listed; they fall into two groups: - - wanting a header - - wanting things moved around under that header, with one additional poin= t PS: the TLS point can trivially be made in one sentence by referring to RFC 4953. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksexDEACgkQE5f5cImnZrtGTgCeJPhg3F3wl97pSFS7bqxJYVa0 U1QAn1Fme4XHCno3/OT+1QY2EJNhcHxv =3DaT/1 -----END PGP SIGNATURE-----= From ananth@cisco.com Tue Dec 8 22:25: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 B01BA3A6859 for ; Tue, 8 Dec 2009 22:25:29 -0800 (PST) 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 gOfsZuNDCOOt for ; Tue, 8 Dec 2009 22:24:49 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id C9AE13A68E3 for ; Tue, 8 Dec 2009 22:24:46 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABPRHkurR7H+/2dsb2JhbAC/WJdAhCwEjSA X-IronPort-AV: E=Sophos;i="4.47,366,1257120000"; d="scan'208";a="227888301" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 09 Dec 2009 06:24:36 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nB96Oaqo029718; Wed, 9 Dec 2009 06:24:36 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Dec 2009 22:24:36 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Dec 2009 22:24:34 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC580884BA47@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <4B1EC307.3060207@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] closing WGLC for TCP-AO Thread-Index: Acp4TE7yL6vPUlX5SreQ67/qw1gJ4wAShHrQ References: <20091203032738.3F7B86C489B@kilo.networkresonance.com><4B173270.70403@isi.edu><20091203050652.585F86C495F@kilo.networkresonance.com><4B174E92.2030702@isi.edu><20091203173612.9C20A6C49F7@kilo.networkresonance.com><4B18001A.9070600@isi.edu><20091203185321.E22976C4A23@kilo.networkresonance.com><4B181058.60104@isi.edu> <20091204151410.C58536C4C6F@kilo.networkresonance.com> <0C53DCFB700D144284A584F54711EC580884B4FB@xmb-sjc-21c.amer.cisco.com> <4B1EB713.3080307@gont.com.ar> <4B1EC307.3060207@isi.edu> From: "Anantha Ramaiah (ananth)" To: "Joe Touch" , "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" X-OriginalArrivalTime: 09 Dec 2009 06:24:36.0218 (UTC) FILETIME=[476D2DA0:01CA7898] Cc: tcpm@ietf.org, Fernando Gont Subject: Re: [tcpm] closing WGLC 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: Wed, 09 Dec 2009 06:25:30 -0000 >=20 > I think this is all about two things: >=20 > - - the desire for a header before the paragraph below that=20 > actually says "Applicability Statement": >=20 > 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=20 > 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,=20 Now, "as has been suggested" comes across dubious. Where it has been suggested, a reference would help or more qualification of the above statement is desired. The reason being, a reader would appreciate either a self-contained paragraph on why AO was desired (some of the reasons are the same as why TCP-MD5 was needed in the first place) why IPsec cannot be used, why SO-BGP cannot address this issue, or just quote references to documents where such an analysis has already been done. So the AS should spell out these things, IMO. > or in cases > where keys need to be tightly coordinated with individual transport > sessions [Be07]. This above statement is fine since it has a reference attached to it. -Anantha From root@core3.amsl.com Tue Dec 8 23:00:04 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 A30393A6783; Tue, 8 Dec 2009 23:00:03 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091209070003.A30393A6783@core3.amsl.com> Date: Tue, 8 Dec 2009 23:00:03 -0800 (PST) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-icmp-attacks-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: Wed, 09 Dec 2009 07:00:04 -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 : ICMP attacks against TCP Author(s) : F. Gont Filename : draft-ietf-tcpm-icmp-attacks-07.txt Pages : 39 Date : 2009-12-08 This document discusses the use of the Internet Control Message Protocol (ICMP) to perform a variety of attacks against the Transmission Control Protocol (TCP) and other similar protocols. Additionally, describes a number of widely implemented modifications to TCP's handling of ICMP error messages that help to mitigate these issues. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-icmp-attacks-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-icmp-attacks-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-08225617.I-D@ietf.org> --NextPart-- From wesley.m.eddy@nasa.gov Wed Dec 9 06:44: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 7EF183A6850 for ; Wed, 9 Dec 2009 06:44:55 -0800 (PST) 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=[AWL=0.000, 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 ApqJYlStNFDX for ; Wed, 9 Dec 2009 06:44:54 -0800 (PST) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id 959063A6877 for ; Wed, 9 Dec 2009 06:44:54 -0800 (PST) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 99CB2328349 for ; Wed, 9 Dec 2009 08:44:42 -0600 (CST) 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 nB9Eihat000555 for ; Wed, 9 Dec 2009 08:44:43 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub06.ndc.nasa.gov ([198.117.4.165]) with mapi; Wed, 9 Dec 2009 08:44:42 -0600 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: "tcpm@ietf.org" Date: Wed, 9 Dec 2009 08:44:40 -0600 Thread-Topic: [tcpm] I-D Action:draft-ietf-tcpm-icmp-attacks-07.txt Thread-Index: Acp4nWFuHYtRDY17SJCMl55q+sa6jQAP5ikA Message-ID: References: <20091209070003.A30393A6783@core3.amsl.com> In-Reply-To: <20091209070003.A30393A6783@core3.amsl.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-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-12-09_09:2009-11-30, 2009-12-09, 2009-12-09 signatures=0 Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-icmp-attacks-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: Wed, 09 Dec 2009 14:44:55 -0000 Fernando has updated this in response to the comments that were collected during WGLC. The diff looks like it addresses the comments from Joe and Donald, but if you could check that in the next week as we write the PROTO, that would be good. -- Wes Eddy MTI Systems >-----Original Message----- >From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of >Internet-Drafts@ietf.org >Sent: Wednesday, December 09, 2009 2:00 AM >To: i-d-announce@ietf.org >Cc: tcpm@ietf.org >Subject: [tcpm] I-D Action:draft-ietf-tcpm-icmp-attacks-07.txt > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the TCP Maintenance and Minor Extensions >Working Group of the IETF. > > > Title : ICMP attacks against TCP > Author(s) : F. Gont > Filename : draft-ietf-tcpm-icmp-attacks-07.txt > Pages : 39 > Date : 2009-12-08 > >This document discusses the use of the Internet Control Message >Protocol (ICMP) to perform a variety of attacks against the >Transmission Control Protocol (TCP) and other similar protocols. >Additionally, describes a number of widely implemented modifications >to TCP's handling of ICMP error messages that help to mitigate these >issues. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-tcpm-icmp-attacks-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. From Andrew.Lange@alcatel-lucent.com Wed Dec 9 11:14: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 6F0123A6841 for ; Wed, 9 Dec 2009 11:14:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EF0kPiPCTOWn for ; Wed, 9 Dec 2009 11:14:16 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by core3.amsl.com (Postfix) with ESMTP id E59CA3A6A4A for ; Wed, 9 Dec 2009 11:14:15 -0800 (PST) Received: from horh1.usa.alcatel.com (h172-22-218-55.lucent.com [172.22.218.55]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id nB9JE4m4008360; Wed, 9 Dec 2009 13:14:04 -0600 (CST) Received: from usdalsbhs02.ad3.ad.alcatel.com (usdalsbhs02.pdc.alcatel-lucent.com [172.22.216.13]) by horh1.usa.alcatel.com (8.13.8/emsr) with ESMTP id nB9JE3MX002031; Wed, 9 Dec 2009 13:14:03 -0600 (CST) Received: from neo-67.vpn.ind.alcatel.com ([172.22.216.4]) by usdalsbhs02.ad3.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 13:14:03 -0600 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-3-758478182 From: Andrew Lange In-Reply-To: <4B18AF3F.1000208@isi.edu> Date: Wed, 9 Dec 2009 11:13:55 -0800 Message-Id: References: <500C5C63-E2E9-41C4-8971-8D7B8F2B0CA7@nokia.com><20091203190705.078676C4A31@kilo.networkresonance.com><79B69D7B-66E5-4904-B97C-73638B8AF780@nokia.com> <4B18AF3F.1000208@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1077) X-OriginalArrivalTime: 09 Dec 2009 19:14:03.0259 (UTC) FILETIME=[C52094B0:01CA7903] X-Scanned-By: MIMEDefang 2.57 on 172.22.12.27 Cc: tcpm@ietf.org Subject: Re: [tcpm] closing WGLC 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: Wed, 09 Dec 2009 19:14:17 -0000 --Apple-Mail-3-758478182 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Joe, I find your protestations about "rushing to keep NAT out" rather = disingenuous. The WG agreed, including yourself, in Stockholm that NAT = would be moved out of -AO and into a separate draft for further = consideration. The purpose of this move was not to continue to = conflate the two issues of -AO and NAT support for -AO. Continuing to = press the point goes directly against the intent of the move to a = separate document. This issue is indicative of how poorly this entire = process has gone.=20 The one constant that is consistently identified as being the cause of = this going badly is the most vocal of the -AO document editors. There = is a clear conflict at this point between the editor as an author and as = someone who can update the document to reflect WG consensus. I would = like to move that the WG remove that editor and ask the co-editors to = take a more active role in putting the final touches on this document. = Things will go much more smoothly, and more accurately reflect the WG's = combined opinion if we put and end to this obvious conflict-of-interest. Andrew On Dec 3, 2009, at 10:42 PM, Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 >=20 >=20 > Lars Eggert wrote: > > Hi, > > > > On 2009-12-3, at 9:07, Eric Rescorla wrote: > >> This does not apply to the NAT document, AFAIK. TCP-MD5 does not = support > >> NATs. It's purely a feature enhancement. >=20 > That could be said of key changeover coordination, establishment of > per-connection ISN-based traffic keys, or even the idea of agile > algorithms. These are all things we added *because they weren't in TCP = MD5*. >=20 > >> I don't see why it needs to > >> be rushed, and in view of the evident security problems, published > >> at all. >=20 > I'd like to take some time on the list to discuss these, because so = far > all that has been claimed is that the traffic keys are somewhat = weaker, > but not necessarily weak enough to present a real issue yet. >=20 > I.e., I don't want to rush to put this in, but I don't see why we = would > rush to keep it out either. >=20 > Joe >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) >=20 > iEYEARECAAYFAksYrz8ACgkQE5f5cImnZrs+NgCeO/r96odyLabjArBOvP7NgMfZ > /A0An3q86VK/pk8LBerDJc8qYeKlVmw2 > =3DYvjI > -----END PGP SIGNATURE----- > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 --Apple-Mail-3-758478182 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

The one constant that is = consistently identified as being the cause of this going badly is the = most vocal of the -AO document editors.  There is a clear conflict = at this point between the editor as an author and as someone who can = update the document to reflect WG consensus.  I would like to move = that the WG remove that editor and ask the co-editors to take a more = active role in putting the final touches on this document.  Things = will go much more smoothly, and more accurately reflect the WG's = combined opinion if we put and end to this obvious = conflict-of-interest.

Andrew

=

On Dec 3, 2009, at 10:42 PM, Joe Touch = wrote:

-----BEGIN = PGP SIGNED MESSAGE-----
Hash: SHA1



Lars Eggert wrote:
> Hi,
>
> On 2009-12-3, at 9:07, Eric Rescorla wrote:
>> This does not apply to the NAT document, AFAIK. TCP-MD5 does = not support
>> NATs. It's purely a feature enhancement.

That could be said of key changeover coordination, establishment of
per-connection ISN-based traffic keys, or even the idea of agile
algorithms. These are all things we added *because they weren't in TCP = MD5*.

>> I don't see why it needs to
>> be rushed, and in view of the evident security problems, = published
>> at all.

I'd like to take some time on the list to discuss these, because so = far
all that has been claimed is that the traffic keys are somewhat = weaker,
but not necessarily weak enough to present a real issue yet.

I.e., I don't want to rush to put this in, but I don't see why we = would
rush to keep it out either.

Joe

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAksYrz8ACgkQE5f5cImnZrs+NgCeO/r96odyLabjArBOvP7NgMfZ
/A0An3q86VK/pk8LBerDJc8qYeKlVmw2
=3DYvjI
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/m= ailman/listinfo/tcpm


= --Apple-Mail-3-758478182-- From wesley.m.eddy@nasa.gov Wed Dec 9 11:53: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 7084328C1D3 for ; Wed, 9 Dec 2009 11:53:36 -0800 (PST) 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 ceqpuraqW47p for ; Wed, 9 Dec 2009 11:53:35 -0800 (PST) Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [198.117.1.122]) by core3.amsl.com (Postfix) with ESMTP id 68FFF28C1CA for ; Wed, 9 Dec 2009 11:53:35 -0800 (PST) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 6EE4CA8469; Wed, 9 Dec 2009 13:53:23 -0600 (CST) 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 nB9JrOd8028799; Wed, 9 Dec 2009 13:53:24 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub03.ndc.nasa.gov ([198.117.4.162]) with mapi; Wed, 9 Dec 2009 13:53:23 -0600 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: Andrew Lange , Joe Touch Date: Wed, 9 Dec 2009 13:53:22 -0600 Thread-Topic: [tcpm] closing WGLC for TCP-AO Thread-Index: Acp5A9S8QfiHLqNISsaq/4uHMo90dAABAWqQ Message-ID: References: <500C5C63-E2E9-41C4-8971-8D7B8F2B0CA7@nokia.com><20091203190705.078676C4A31@kilo.networkresonance.com><79B69D7B-66E5-4904-B97C-73638B8AF780@nokia.com> <4B18AF3F.1000208@isi.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-12-09_14:2009-11-30, 2009-12-09, 2009-12-09 signatures=0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] closing WGLC 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: Wed, 09 Dec 2009 19:53:36 -0000 Last week both TCPM co-chairs indicated that the path forward is to leave NAT out for now: http://www.ietf.org/mail-archive/web/tcpm/current/msg05074.html http://www.ietf.org/mail-archive/web/tcpm/current/msg05072.html I think Joe is already working on a document update, and assumed that it won't include NAT, but that he's just continuing the thread while the topic is fresh in people's minds ... I think since the expected update (including the WG consensus to leave out NAT, for now) is in-progress and then the document will be sent to the IESG for publication, shuffling editors isn't called for and would only slow completion of the document down. To avoid any confusion, it seems like a good idea to table the NAT discussion for now and revive it later if there's desire, after the document has progressed. -- Wes Eddy MTI Systems >-----Original Message----- >From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of >Andrew Lange >Sent: Wednesday, December 09, 2009 2:14 PM >To: Joe Touch >Cc: tcpm@ietf.org >Subject: Re: [tcpm] closing WGLC for TCP-AO > >Joe, > >I find your protestations about "rushing to keep NAT out" rather >disingenuous. The WG agreed, including yourself, in Stockholm that NAT >would be moved out of -AO and into a separate draft for further >consideration. The purpose of this move was not to continue to >conflate the two issues of -AO and NAT support for -AO. Continuing to >press the point goes directly against the intent of the move to a >separate document. This issue is indicative of how poorly this entire >process has gone. > >The one constant that is consistently identified as being the cause of >this going badly is the most vocal of the -AO document editors. There >is a clear conflict at this point between the editor as an author and as >someone who can update the document to reflect WG consensus. I would >like to move that the WG remove that editor and ask the co-editors to >take a more active role in putting the final touches on this document. >Things will go much more smoothly, and more accurately reflect the WG's >combined opinion if we put and end to this obvious conflict-of-interest. > >Andrew > > >On Dec 3, 2009, at 10:42 PM, Joe Touch wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Lars Eggert wrote: > > Hi, > > > > On 2009-12-3, at 9:07, Eric Rescorla wrote: > >> This does not apply to the NAT document, AFAIK. TCP-MD5 does >not support > >> NATs. It's purely a feature enhancement. > > That could be said of key changeover coordination, establishment >of > per-connection ISN-based traffic keys, or even the idea of agile > algorithms. These are all things we added *because they weren't in >TCP MD5*. > > >> I don't see why it needs to > >> be rushed, and in view of the evident security problems, >published > >> at all. > > I'd like to take some time on the list to discuss these, because >so far > all that has been claimed is that the traffic keys are somewhat >weaker, > but not necessarily weak enough to present a real issue yet. > > I.e., I don't want to rush to put this in, but I don't see why we >would > rush to keep it out either. > > Joe > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > > iEYEARECAAYFAksYrz8ACgkQE5f5cImnZrs+NgCeO/r96odyLabjArBOvP7NgMfZ > /A0An3q86VK/pk8LBerDJc8qYeKlVmw2 > =3DYvjI > -----END PGP SIGNATURE----- > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > From wesley.m.eddy@nasa.gov Wed Dec 9 12:03: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 0AFAB3A6848 for ; Wed, 9 Dec 2009 12:03:17 -0800 (PST) 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 MSTkIK9o0ycz for ; Wed, 9 Dec 2009 12:03:16 -0800 (PST) Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [198.117.1.122]) by core3.amsl.com (Postfix) with ESMTP id 3DA953A695E for ; Wed, 9 Dec 2009 12:03:14 -0800 (PST) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 7EA84A842B for ; Wed, 9 Dec 2009 14:03:02 -0600 (CST) Received: from ndjshub04.ndc.nasa.gov (ndjshub04.ndc.nasa.gov [198.117.4.163]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id nB9K33J0010319 for ; Wed, 9 Dec 2009 14:03:03 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub04.ndc.nasa.gov ([198.117.4.163]) with mapi; Wed, 9 Dec 2009 14:03:02 -0600 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: "tcpm@ietf.org" Date: Wed, 9 Dec 2009 14:03:00 -0600 Thread-Topic: poll for consensus on Middlebox Discover draft as a TCPM WG item Thread-Index: Acp5CpYcCRL5jBRETIycbH++oNIH/g== 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.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-12-09_14:2009-11-30, 2009-12-09, 2009-12-09 signatures=0 Subject: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG item X-BeenThere: tcpm@ietf.org X-Mailman-Version: 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, 09 Dec 2009 20:03:17 -0000 TCPM has been discussing draft-knutsen-tcpm-middlebox-discovery for some time now, and the latest copy: http://tools.ietf.org/html/draft-knutsen-tcpm-middlebox-discovery-03 includes many revisions based on feedback from the working group. At this point, the authors have asked if it can become a TCPM working group item, targeted for Experimental (although the draft currently says "Informational"; intended-status can be discussed further). Please respond to this email whether you think: (1) the Middlebox Discovery Option SHOULD become a TCPM working group document, and you would support work on it or (2) the Middlebox Discovery Option SHOULD NOT become a TCPM working group document If possible, responses in the next two weeks, by 12/23, will be appreciated. -- Wes Eddy MTI Systems From cait@asomi.com Wed Dec 9 12:39: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 2446C3A6A4B for ; Wed, 9 Dec 2009 12:39:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xhun2jhTWAsy for ; Wed, 9 Dec 2009 12:39:17 -0800 (PST) Received: from mail3.sea5.speakeasy.net (mail3.sea5.speakeasy.net [69.17.117.5]) by core3.amsl.com (Postfix) with ESMTP id 3E45B3A6A58 for ; Wed, 9 Dec 2009 12:39:17 -0800 (PST) Received: (qmail 32391 invoked from network); 9 Dec 2009 20:39:05 -0000 Received: from wmail2.sea5.speakeasy.net ([69.17.117.158]) (envelope-sender ) by mail3.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 9 Dec 2009 20:39:05 -0000 Received: from wmail.speakeasy.net (localhost [127.0.0.1]) by wmail2.sea5.speakeasy.net (Postfix) with ESMTP id C3B117F852; Wed, 9 Dec 2009 12:39:05 -0800 (PST) Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-Mailer: AtMail - 63.146.69.42 - cait@asomi.com Date: Wed, 09 Dec 2009 12:39:05 PST X-Origin: 63.146.69.42 Message-Id: <6220.1260391145@asomi.com> To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" , "tcpm@ietf.org" From: Caitlin Bestler Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG item X-BeenThere: tcpm@ietf.org X-Mailman-Version: 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, 09 Dec 2009 20:39:18 -0000 (2) the Middlebox Discovery Option SHOULD NOT become a TCPM working group= document As stated in the Abstract, "The option has no effect if an appropriate midd= lebox is not on the path". As drafted this is not a proposal for "middlebox" discovery, but a method f= or vendor-specific clients to find vendor-specific middleboxes. There is value in having a discovery protocol that follows the same path th= at any TCP segment would follow. However, because the TCP option space is limited, such an opt= ion should only be considered when it defines a method of being discovered that *any* middl= ebox could support. Then it would be useful as a general network diagnostic tool, and = not merely the specialized uses described in the current draft. Caitlin Bestler cait@asomi.com From shore@arsc.edu Wed Dec 9 12:47: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 456963A696F for ; Wed, 9 Dec 2009 12:47:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 2FFDE5pQD6eo for ; Wed, 9 Dec 2009 12:47:47 -0800 (PST) Received: from arsc.edu (mail1.arsc.edu [IPv6:2001:480:150:75::229]) by core3.amsl.com (Postfix) with ESMTP id 5F04F3A65A6 for ; Wed, 9 Dec 2009 12:47:44 -0800 (PST) Received: from viking-e0.arsc.edu (viking-e0.arsc.edu [IPv6:2001:480:150:860:223:32ff:feda:4a52]) by arsc.edu (20090828.ARSC) with ESMTP id nB9KlQ8u015322; Wed, 9 Dec 2009 11:47:27 -0900 (AKST) Message-Id: From: Melinda Shore To: Caitlin Bestler In-Reply-To: <6220.1260391145@asomi.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 9 Dec 2009 11:47:26 -0900 References: <6220.1260391145@asomi.com> X-Mailer: Apple Mail (2.936) X-CanIt-Geo: No geolocation information available for 2001:480:150:860:223:32ff:feda:4a52 X-CanItPRO-Stream: default X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on IPv6:2001:480:150:75::167 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG item X-BeenThere: tcpm@ietf.org X-Mailman-Version: 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, 09 Dec 2009 20:47:48 -0000 On Dec 9, 2009, at 11:39 AM, Caitlin Bestler wrote: > (2) the Middlebox Discovery Option SHOULD NOT become a TCPM > working group document [ ... ] > but a method for vendor-specific > clients to find vendor-specific middleboxes. Hear, hear. > There is value in having a discovery protocol that follows the same > path that any TCP segment > would follow. I'd extend that to any IP packet. Doing it in-band with TCP is easier than doing it more generally, but probably the most common place to run into middlebox issues is with media (UDP) streams used with session- oriented protocols. Maybe a v6 header option. Melinda From andrew.knutsen@bluecoat.com Wed Dec 9 13:00:53 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 948983A6B05 for ; Wed, 9 Dec 2009 13:00:53 -0800 (PST) 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 oaoMy2ArtEMK for ; Wed, 9 Dec 2009 13:00:52 -0800 (PST) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id B15153A66B4 for ; Wed, 9 Dec 2009 13:00:52 -0800 (PST) Received: from exchfront1.internal.cacheflow.com (exchfront1 [10.2.2.114]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id nB9L0f0n005405; Wed, 9 Dec 2009 13:00:41 -0800 (PST) Received: from [10.150.1.134] ([10.150.1.134]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 13:00:35 -0800 Message-ID: <4B200FF4.6020005@bluecoat.com> Date: Wed, 09 Dec 2009 13:00:36 -0800 From: Andrew Knutsen User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Caitlin Bestler References: <6220.1260391145@asomi.com> In-Reply-To: <6220.1260391145@asomi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Dec 2009 21:00:35.0917 (UTC) FILETIME=[A772C7D0:01CA7912] Cc: "tcpm@ietf.org" Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG item X-BeenThere: tcpm@ietf.org X-Mailman-Version: 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, 09 Dec 2009 21:00:53 -0000 A standard device capability code could be defined for "*any*" middlebox. However the ability to discover devices with particular capabilities is also useful/needed, and until those types are standardized they will all be vendor-specific. One step at a time. Andrew Caitlin Bestler wrote: > (2) the Middlebox Discovery Option SHOULD NOT become a TCPM working group document > > As stated in the Abstract, "The option has no effect if an appropriate middlebox is not on the path". > > As drafted this is not a proposal for "middlebox" discovery, but a method for vendor-specific > clients to find vendor-specific middleboxes. > > There is value in having a discovery protocol that follows the same path that any TCP segment > would follow. However, because the TCP option space is limited, such an option should only > be considered when it defines a method of being discovered that *any* middlebox could > support. Then it would be useful as a general network diagnostic tool, and not merely the > specialized uses described in the current draft. > > > > > > Caitlin Bestler > cait@asomi.com > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From andrew.knutsen@bluecoat.com Wed Dec 9 13:03:21 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 B63743A67A1 for ; Wed, 9 Dec 2009 13:03:21 -0800 (PST) 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 ikVyGsguOQEV for ; Wed, 9 Dec 2009 13:03:21 -0800 (PST) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id F1EDC3A6951 for ; Wed, 9 Dec 2009 13:03:20 -0800 (PST) Received: from exchfront1.internal.cacheflow.com (exchfront1 [10.2.2.114]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id nB9L2vQ3005869; Wed, 9 Dec 2009 13:02:57 -0800 (PST) Received: from [10.150.1.134] ([10.150.1.134]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 13:02:52 -0800 Message-ID: <4B20107C.7090402@bluecoat.com> Date: Wed, 09 Dec 2009 13:02:52 -0800 From: Andrew Knutsen User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Melinda Shore References: <6220.1260391145@asomi.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Dec 2009 21:02:52.0229 (UTC) FILETIME=[F8B25750:01CA7912] Cc: "tcpm@ietf.org" Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG item X-BeenThere: tcpm@ietf.org X-Mailman-Version: 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, 09 Dec 2009 21:03:21 -0000 The draft discusses why this must be a TCP option. An IP option could also be defined, but it would address a different problem. Andrew Melinda Shore wrote: > On Dec 9, 2009, at 11:39 AM, Caitlin Bestler wrote: >> (2) the Middlebox Discovery Option SHOULD NOT become a TCPM working >> group document > > [ ... ] > >> but a method for vendor-specific >> clients to find vendor-specific middleboxes. > > Hear, hear. > >> There is value in having a discovery protocol that follows the same >> path that any TCP segment >> would follow. > > I'd extend that to any IP packet. Doing it in-band > with TCP is easier than doing it more generally, but > probably the most common place to run into middlebox > issues is with media (UDP) streams used with session- > oriented protocols. Maybe a v6 header option. > > Melinda > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From touch@ISI.EDU Wed Dec 9 13:47: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 492313A691A for ; Wed, 9 Dec 2009 13:47:31 -0800 (PST) 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 cSgJm1bksZyI for ; Wed, 9 Dec 2009 13:47:30 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 926E73A680F for ; Wed, 9 Dec 2009 13:47:30 -0800 (PST) Received: from [10.2.4.232] (usfws1.systemmetrics.com [66.135.227.114]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id nB9LkVOv016907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Dec 2009 13:46:34 -0800 (PST) Message-ID: <4B201AB7.1090809@isi.edu> Date: Wed, 09 Dec 2009 13:46:31 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Andrew Lange References: <500C5C63-E2E9-41C4-8971-8D7B8F2B0CA7@nokia.com><20091203190705.078676C4A31@kilo.networkresonance.com><79B69D7B-66E5-4904-B97C-73638B8AF780@nokia.com> <4B18AF3F.1000208@isi.edu> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MailScanner-ID: nB9LkVOv016907 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] closing WGLC 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: Wed, 09 Dec 2009 21:47:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Lange wrote: > Joe, > > I find your protestations about "rushing to keep NAT out" rather > disingenuous. The WG agreed, including yourself, in Stockholm that NAT > would be moved out of -AO and into a separate draft for further > consideration. The purpose of this move was not to continue to > conflate the two issues of -AO and NAT support for -AO. Continuing to > press the point goes directly against the intent of the move to a > separate document. The decoupling was intended for last call, which has long since closed. How it affects the doc as we move forward was something the WG had already agreed to discuss, and we're discussing it. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksgGrcACgkQE5f5cImnZrvmTACdG3bg+pKT4zs5Uvgb6rL3shr0 WUgAn0mwTtAwK6vuKhYIDXKETp3MU1uC =htig -----END PGP SIGNATURE----- From Donald.Smith@qwest.com Wed Dec 9 14:22: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 BFA7128C1D7 for ; Wed, 9 Dec 2009 14:22:29 -0800 (PST) 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 qrGTjClvaD2P for ; Wed, 9 Dec 2009 14:22:27 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id E27F128C1CD for ; Wed, 9 Dec 2009 14:22:25 -0800 (PST) Received: from sudnp796.qintra.com (sudnp796.qintra.com [151.116.2.212]) by suomp64i.qwest.com (8.14.0/8.14.0) with ESMTP id nB9MMD96016340; Wed, 9 Dec 2009 16:22:13 -0600 (CST) Received: from qtdenexhtm22.AD.QINTRA.COM (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.0/8.14.0) with ESMTP id nB9MM7v9016620; Wed, 9 Dec 2009 15:22:07 -0700 (MST) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm22.AD.QINTRA.COM ([151.119.91.231]) with mapi; Wed, 9 Dec 2009 15:22:07 -0700 From: "Smith, Donald" To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" , "tcpm@ietf.org" Content-Class: urn:content-classes:message Date: Wed, 9 Dec 2009 15:22:06 -0700 Thread-Topic: [tcpm] I-D Action:draft-ietf-tcpm-icmp-attacks-07.txt Thread-Index: Acp4nWFuHYtRDY17SJCMl55q+sa6jQAP5ikAABA6uCoAAAlf4w== Message-ID: References: <20091209070003.A30393A6783@core3.amsl.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-mimectl: Produced By Microsoft Exchange V8.1.348.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-icmp-attacks-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: Wed, 09 Dec 2009 22:22:30 -0000 I provided some additional comments directly to Fernando. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com ________________________________ From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of Eddy, Wesl= ey M. (GRC-MS00)[ASRC AEROSPACE CORP] [wesley.m.eddy@nasa.gov] Sent: Wednesday, December 09, 2009 7:44 AM To: tcpm@ietf.org Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-icmp-attacks-07.txt Fernando has updated this in response to the comments that were collected during WGLC. The diff looks like it addresses the comments from Joe and Donald, but if you could check that in the next week as we write the PROTO, that would be good. -- Wes Eddy MTI Systems >-----Original Message----- >From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of >Internet-Drafts@ietf.org >Sent: Wednesday, December 09, 2009 2:00 AM >To: i-d-announce@ietf.org >Cc: tcpm@ietf.org >Subject: [tcpm] I-D Action:draft-ietf-tcpm-icmp-attacks-07.txt > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the TCP Maintenance and Minor Extensions >Working Group of the IETF. > > > Title : ICMP attacks against TCP > Author(s) : F. Gont > Filename : draft-ietf-tcpm-icmp-attacks-07.txt > Pages : 39 > Date : 2009-12-08 > >This document discusses the use of the Internet Control Message >Protocol (ICMP) to perform a variety of attacks against the >Transmission Control Protocol (TCP) and other similar protocols. >Additionally, describes a number of widely implemented modifications >to TCP's handling of ICMP error messages that help to mitigate these >issues. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-tcpm-icmp-attacks-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. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm ________________________________ This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From perfgeek@mac.com Wed Dec 9 19:11:20 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 EAE363A6359 for ; Wed, 9 Dec 2009 19:11:19 -0800 (PST) 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 vb8WSRcHud0V for ; Wed, 9 Dec 2009 19:11:18 -0800 (PST) Received: from asmtpout021.mac.com (asmtpout021.mac.com [17.148.16.96]) by core3.amsl.com (Postfix) with ESMTP id C08B53A694F for ; Wed, 9 Dec 2009 19:11:17 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [192.168.1.101] (76-220-56-223.lightspeed.sntcca.sbcglobal.net [76.220.56.223]) by asmtp021.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KUF00B7X26E0100@asmtp021.mac.com> for tcpm@ietf.org; Wed, 09 Dec 2009 19:11:07 -0800 (PST) Message-id: <3AEE4E4B-0470-4093-8803-825DF9890C34@mac.com> From: rick jones To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" In-reply-to: Date: Wed, 09 Dec 2009 19:11:00 -0800 References: X-Mailer: Apple Mail (2.936) Cc: "tcpm@ietf.org" Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG item X-BeenThere: tcpm@ietf.org X-Mailman-Version: 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, 10 Dec 2009 03:11:20 -0000 How many angelic options are we going to try to get to dance at once on the header of a TCP SYN segment? > There may be situations where other options are required in the SYN > packet which do not leave enough room for all of the target data > necessary for the desired device capability to be advertised. In > these cases, a shorter alternate device capability may be defined > which signals the request to further negotiate the capability after > the handshake completes. This will impact performance by introducing > an extra round-trip during connection set-up, but this may be the > only way to perform the negotiation within the limited TCP option > space available. An additional round-trip?? Not being at all certain I've been around the list/wg long enough to cast a vote, I'll simply say it sounds dodgy to me. rick jones Wisdom teeth are impacted, people are affected by the effects of events From andrew.knutsen@bluecoat.com Wed Dec 9 21:01: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 620AA3A696C for ; Wed, 9 Dec 2009 21:01:36 -0800 (PST) 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 JvP34leNnf-B for ; Wed, 9 Dec 2009 21:01:35 -0800 (PST) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id 928EB3A6839 for ; Wed, 9 Dec 2009 21:01:35 -0800 (PST) Received: from exchfront1.internal.cacheflow.com (exchfront1 [10.2.2.114]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id nBA51N1n001422; Wed, 9 Dec 2009 21:01:23 -0800 (PST) Received: from [10.150.1.68] ([10.150.1.68]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 21:01:18 -0800 Message-ID: <4B20809D.5060402@bluecoat.com> Date: Wed, 09 Dec 2009 21:01:17 -0800 From: Andrew Knutsen User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: rick jones References: <3AEE4E4B-0470-4093-8803-825DF9890C34@mac.com> In-Reply-To: <3AEE4E4B-0470-4093-8803-825DF9890C34@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Dec 2009 05:01:18.0451 (UTC) FILETIME=[CEF03430:01CA7955] Cc: "tcpm@ietf.org" Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG item X-BeenThere: tcpm@ietf.org X-Mailman-Version: 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, 10 Dec 2009 05:01:36 -0000 I'll just say again that this solution has been deployed by several vendors for several years (using several invalid option kinds). The only way to avoid the problems mentioned below (and others, elsewhere) is to force them (us) all to change, probably at the cost of competitive advantage, and possibly by making more fundamental changes in TCP itself. We agree that standardization in this area is a worthwhile goal, however it is most likely to be accomplished incrementally. The current proposal represents a first step in that direction. Andrew rick jones wrote: > How many angelic options are we going to try to get to dance at once > on the header of a TCP SYN segment? > >> There may be situations where other options are required in the SYN >> packet which do not leave enough room for all of the target data >> necessary for the desired device capability to be advertised. In >> these cases, a shorter alternate device capability may be defined >> which signals the request to further negotiate the capability after >> the handshake completes. This will impact performance by introducing >> an extra round-trip during connection set-up, but this may be the >> only way to perform the negotiation within the limited TCP option >> space available. > An additional round-trip?? > > Not being at all certain I've been around the list/wg long enough to > cast a vote, I'll simply say it sounds dodgy to me. > > rick jones > Wisdom teeth are impacted, people are affected by the effects of events > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From wesley.m.eddy@nasa.gov Thu Dec 10 07:19: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 3B18C3A683B for ; Thu, 10 Dec 2009 07:19:28 -0800 (PST) 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 f7pHqYdZ00U2 for ; Thu, 10 Dec 2009 07:19:27 -0800 (PST) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id 383563A67EE for ; Thu, 10 Dec 2009 07:19:27 -0800 (PST) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 18E75328632; Thu, 10 Dec 2009 09:19:15 -0600 (CST) Received: from ndjshub04.ndc.nasa.gov (ndjshub04.ndc.nasa.gov [198.117.4.163]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id nBAFJGEb004123; Thu, 10 Dec 2009 09:19:16 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub04.ndc.nasa.gov ([198.117.4.163]) with mapi; Thu, 10 Dec 2009 09:19:14 -0600 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: Andrew Knutsen , rick jones Date: Thu, 10 Dec 2009 09:19:13 -0600 Thread-Topic: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG item Thread-Index: Acp5VdOf8U5O1ZtsSsO+l9Vd1gBTSwAU2IZw Message-ID: References: <3AEE4E4B-0470-4093-8803-825DF9890C34@mac.com> <4B20809D.5060402@bluecoat.com> In-Reply-To: <4B20809D.5060402@bluecoat.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-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-12-10_11:2009-11-30, 2009-12-10, 2009-12-10 signatures=0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG item X-BeenThere: tcpm@ietf.org X-Mailman-Version: 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, 10 Dec 2009 15:19:28 -0000 Speaking as an individual (not a WG co-chair), it was an eye-opener for me to discover that there are N vendors, each of which is doing something similar to this, and they're picking their own TCP option numbers (not getting them properly allocated and documented). That's "really bad". It basically turns the space of what we think are unused options numbers into a minefield of somewhat-used options numbers. In the sense that this proposal is a possible step towards fixing that in the long term, I can support it. It's possible that there are other approaches to fixing the situation; if so, maybe we should be talking about those too. Does anyone else feel like there's a potential for the options space to be poisoned by the current middlebox discovery practices? -- Wes Eddy MTI Systems >-----Original Message----- >From: Andrew Knutsen [mailto:andrew.knutsen@bluecoat.com] >Sent: Thursday, December 10, 2009 12:01 AM >To: rick jones >Cc: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; tcpm@ietf.org >Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a >TCPM WG item > > > I'll just say again that this solution has been deployed by several >vendors for several years (using several invalid option kinds). The only >way to avoid the problems mentioned below (and others, elsewhere) is to >force them (us) all to change, probably at the cost of competitive >advantage, and possibly by making more fundamental changes in TCP >itself. We agree that standardization in this area is a worthwhile goal, >however it is most likely to be accomplished incrementally. The current >proposal represents a first step in that direction. > >Andrew > >rick jones wrote: >> How many angelic options are we going to try to get to dance at once >> on the header of a TCP SYN segment? >> >>> There may be situations where other options are required in the SYN >>> packet which do not leave enough room for all of the target data >>> necessary for the desired device capability to be advertised. In >>> these cases, a shorter alternate device capability may be defined >>> which signals the request to further negotiate the capability after >>> the handshake completes. This will impact performance by introducing >>> an extra round-trip during connection set-up, but this may be the >>> only way to perform the negotiation within the limited TCP option >>> space available. >> An additional round-trip?? >> >> Not being at all certain I've been around the list/wg long enough to >> cast a vote, I'll simply say it sounds dodgy to me. >> >> rick jones >> Wisdom teeth are impacted, people are affected by the effects of >events >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm From perfgeek@mac.com Thu Dec 10 08:42: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 1109D3A6A0D for ; Thu, 10 Dec 2009 08:42:02 -0800 (PST) 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 s+eB0UnFX3EU for ; Thu, 10 Dec 2009 08:42:01 -0800 (PST) Received: from asmtpout017.mac.com (asmtpout017.mac.com [17.148.16.92]) by core3.amsl.com (Postfix) with ESMTP id 1692E3A69DA for ; Thu, 10 Dec 2009 08:42:01 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [192.168.1.101] (76-220-56-223.lightspeed.sntcca.sbcglobal.net [76.220.56.223]) by asmtp017.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KUG0043I3PN6660@asmtp017.mac.com> for tcpm@ietf.org; Thu, 10 Dec 2009 08:41:48 -0800 (PST) Message-id: <9917F8C2-EBDE-4ECF-ABB4-3D5A0C3CCA28@mac.com> From: rick jones To: Andrew Knutsen In-reply-to: <4B20809D.5060402@bluecoat.com> Date: Thu, 10 Dec 2009 08:41:46 -0800 References: <3AEE4E4B-0470-4093-8803-825DF9890C34@mac.com> <4B20809D.5060402@bluecoat.com> X-Mailer: Apple Mail (2.936) Cc: "tcpm@ietf.org" Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG item X-BeenThere: tcpm@ietf.org X-Mailman-Version: 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, 10 Dec 2009 16:42:02 -0000 On Dec 9, 2009, at 9:01 PM, Andrew Knutsen wrote: > I'll just say again that this solution has been deployed by > several vendors for several years (using several invalid option > kinds). The only way to avoid the problems mentioned below (and > others, elsewhere) is to force them (us) all to change, probably at > the cost of competitive advantage, and possibly by making more > fundamental changes in TCP itself. We agree that standardization in > this area is a worthwhile goal, however it is most likely to be > accomplished incrementally. The current proposal represents a first > step in that direction. Have any end-system/client TCP stacks actually adopted these several vendors' invalid option kinds thusfar? Getting more fundamental, and perhaps initiating one of my "Emily Litella" moments, it sounds like transparent middlebox discovery is trying to allow such boxes to be "Shimmer" - is it supposed to be *transparent* ? Then it would seem that this is making it visible. Is it supposed to be a proxy? Then it should be done explicitly by the application(s). It sounds like this is an attempt to make it a little of both. rick jones Wisdom teeth are impacted, people are affected by the effects of events http://snltranscripts.jt.org/75/75ishimmer.phtml or for the more audiovisually oriented: http://www.hulu.com/watch/61320/saturday-night-live-shimmer-floor-wax From andrew.knutsen@bluecoat.com Thu Dec 10 09: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 375A93A6B1F for ; Thu, 10 Dec 2009 09:41:28 -0800 (PST) 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 PSSxE7Gz5w2y for ; Thu, 10 Dec 2009 09:41:27 -0800 (PST) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id 147553A69AC for ; Thu, 10 Dec 2009 09:41:27 -0800 (PST) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id nBAHdUAg023974; Thu, 10 Dec 2009 09:41:15 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Dec 2009 09:40:01 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG item Thread-Index: Acp5t7ehnStZ9mU2R5Gcd+l/sGTqiQABqOlo References: <3AEE4E4B-0470-4093-8803-825DF9890C34@mac.com> <4B20809D.5060402@bluecoat.com> <9917F8C2-EBDE-4ECF-ABB4-3D5A0C3CCA28@mac.com> From: "Knutsen, Andrew" To: "rick jones" Cc: tcpm@ietf.org Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG item X-BeenThere: tcpm@ietf.org X-Mailman-Version: 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, 10 Dec 2009 17:41:28 -0000 =20 This technology is generally implemented in proxies, although some = proxies are co-located on client systems. =20 There are two kinds of proxies: explicit and transparent. Clients = only need to be configured for explicit proxies. =20 The current use of this option is generally to make tunnels, as = described in the draft and also the middlebox rfc referenced. In this = case, there are four devices involved, and two "proxy discoveries". Each = discovery can be either explicit or transparent. The option is used by = the tunnel endpoint near the client ("edge") to find the endpoint near = the server ("core"). Discovery of the edge by the client is a seperate = issue, and generally does not use a TCP option. =20 Andrew ________________________________ From: rick jones [mailto:perfgeek@mac.com] Sent: Thu 12/10/2009 8:41 AM To: Knutsen, Andrew Cc: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; tcpm@ietf.org Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a = TCPM WG item On Dec 9, 2009, at 9:01 PM, Andrew Knutsen wrote: > I'll just say again that this solution has been deployed by=20 > several vendors for several years (using several invalid option=20 > kinds). The only way to avoid the problems mentioned below (and=20 > others, elsewhere) is to force them (us) all to change, probably at=20 > the cost of competitive advantage, and possibly by making more=20 > fundamental changes in TCP itself. We agree that standardization in=20 > this area is a worthwhile goal, however it is most likely to be=20 > accomplished incrementally. The current proposal represents a first=20 > step in that direction. Have any end-system/client TCP stacks actually adopted these several=20 vendors' invalid option kinds thusfar? Getting more fundamental, and perhaps initiating one of my "Emily=20 Litella" moments, it sounds like transparent middlebox discovery is=20 trying to allow such boxes to be "Shimmer" - is it supposed to be=20 *transparent* ? Then it would seem that this is making it visible. Is=20 it supposed to be a proxy? Then it should be done explicitly by the=20 application(s). It sounds like this is an attempt to make it a little=20 of both. rick jones Wisdom teeth are impacted, people are affected by the effects of events http://snltranscripts.jt.org/75/75ishimmer.phtml or for the more=20 audiovisually oriented: http://www.hulu.com/watch/61320/saturday-night-live-shimmer-floor-wax From matt.mathis@gmail.com Fri Dec 11 10:48: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 DDB383A67F0 for ; Fri, 11 Dec 2009 10:48:34 -0800 (PST) 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.001, 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 mnXaUnSQg8ay for ; Fri, 11 Dec 2009 10:48:32 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id BD57F3A67D4 for ; Fri, 11 Dec 2009 10:48:26 -0800 (PST) Received: by bwz23 with SMTP id 23so853670bwz.29 for ; Fri, 11 Dec 2009 10:48:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Xxwt12wBSJOiCdxcAZs7Og0v69LylOZYdK0TszdGNUk=; b=B9DvxF8ik3YMsfphJFVMZnsg2h0ije6DFqTlxyfzftgAR8O6bYAHkSyqUe5kCBmdVi GpY29xgrGVt16TYlgniAOYms0lwkvu/EZNxTujNzG9uKD8pF7zizG4H2b/utMuZZq00I /d+tsJMRj3YoBU4SEcqvtA6jk+Y6YDYD0F2L0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=B09qc2g1/2/wcNruiOzzsS5u4+RjDk1jiF8NK2jQSzTHOiNrxF5jfgi88+0z7r1AO0 3CN5enAAc71zr2KLIwTtqYPCkGqe0UyLoM01+T41yfWR5eXJ5ELb2n+kF4moPuJgP8eb t6encqIBqMnMy7yHwGBTb4BRTkQKi8EwEcgls= MIME-Version: 1.0 Received: by 10.204.34.209 with SMTP id m17mr1015152bkd.34.1260557290944; Fri, 11 Dec 2009 10:48:10 -0800 (PST) In-Reply-To: References: <3AEE4E4B-0470-4093-8803-825DF9890C34@mac.com> <4B20809D.5060402@bluecoat.com> Date: Fri, 11 Dec 2009 13:48:10 -0500 Message-ID: From: Matt Mathis To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" Content-Type: multipart/alternative; boundary=00032555992e8bba7e047a785dcf Cc: "tcpm@ietf.org" Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG item X-BeenThere: tcpm@ietf.org X-Mailman-Version: 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, 11 Dec 2009 18:48:35 -0000 --00032555992e8bba7e047a785dcf Content-Type: text/plain; charset=ISO-8859-1 Can we get some of the vendors to 'fess up to this? (Or is anybody willing to point fingers?) If there is more than one, I think we (tcpm) had better not stand in the way of an attempt at standardisation, and should perhaps take the opposite stance: the guilty parties MUST attempt to standardise what they are doing, and get the proper IANA option codes. It would be much better to have this done out in the open, in tcpm and the IETF. Thanks, --MM-- ------------------------------------------- Matt Mathis http://staff.psc.edu/mathis Work:412.268.3319 Home/Cell:412.654.7529 ------------------------------------------- Evil is defined by mortals who think they know "The Truth" and use force to apply it to others. On Thu, Dec 10, 2009 at 10:19 AM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote: > Speaking as an individual (not a WG co-chair), it was an eye-opener > for me to discover that there are N vendors, each of which is doing > something similar to this, and they're picking their own TCP option > numbers (not getting them properly allocated and documented). > > That's "really bad". It basically turns the space of what we think > are unused options numbers into a minefield of somewhat-used options > numbers. In the sense that this proposal is a possible step towards > fixing that in the long term, I can support it. > > It's possible that there are other approaches to fixing the situation; > if so, maybe we should be talking about those too. Does anyone else > feel like there's a potential for the options space to be poisoned > by the current middlebox discovery practices? > > -- > Wes Eddy > MTI Systems > > > >-----Original Message----- > >From: Andrew Knutsen [mailto:andrew.knutsen@bluecoat.com] > >Sent: Thursday, December 10, 2009 12:01 AM > >To: rick jones > >Cc: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; tcpm@ietf.org > >Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a > >TCPM WG item > > > > > > I'll just say again that this solution has been deployed by several > >vendors for several years (using several invalid option kinds). The only > >way to avoid the problems mentioned below (and others, elsewhere) is to > >force them (us) all to change, probably at the cost of competitive > >advantage, and possibly by making more fundamental changes in TCP > >itself. We agree that standardization in this area is a worthwhile goal, > >however it is most likely to be accomplished incrementally. The current > >proposal represents a first step in that direction. > > > >Andrew > > > >rick jones wrote: > >> How many angelic options are we going to try to get to dance at once > >> on the header of a TCP SYN segment? > >> > >>> There may be situations where other options are required in the SYN > >>> packet which do not leave enough room for all of the target data > >>> necessary for the desired device capability to be advertised. In > >>> these cases, a shorter alternate device capability may be defined > >>> which signals the request to further negotiate the capability after > >>> the handshake completes. This will impact performance by introducing > >>> an extra round-trip during connection set-up, but this may be the > >>> only way to perform the negotiation within the limited TCP option > >>> space available. > >> An additional round-trip?? > >> > >> Not being at all certain I've been around the list/wg long enough to > >> cast a vote, I'll simply say it sounds dodgy to me. > >> > >> rick jones > >> Wisdom teeth are impacted, people are affected by the effects of > >events > >> > >> _______________________________________________ > >> 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 > --00032555992e8bba7e047a785dcf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Can we get some of the vendors to 'fess up to this?=A0 (Or is anybody w= illing to point fingers?) If there is more than one, I think we (tcpm) had = better not stand in the way of an attempt at standardisation, and should pe= rhaps take the opposite stance: the guilty parties MUST attempt to standard= ise what they are doing, and get the proper IANA option codes.

It would be much better to have this done out in the open, in tcpm and = the IETF.

Thanks,
--MM--
-----------------------= --------------------
Matt Mathis =A0 =A0 =A0http://staff.psc.edu/mathis
Work:412.268.3319 =A0 Home/Cell:412.654.7529
---------------------------= ----------------
Evil is defined by mortals who think they know
"= ;The Truth" and use force to apply it to others.


On Thu, Dec 10, 2009 at 10:19 AM, Eddy, = Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] <wesley.m.eddy@nasa.gov> wrote:=
Speaking as an in= dividual (not a WG co-chair), it was an eye-opener
for me to discover that there are N vendors, each of which is doing
something similar to this, and they're picking their own TCP option
numbers (not getting them properly allocated and documented).

That's "really bad". =A0It basically turns the space of what = we think
are unused options numbers into a minefield of somewhat-used options
numbers. =A0In the sense that this proposal is a possible step towards
fixing that in the long term, I can support it.

It's possible that there are other approaches to fixing the situation;<= br> if so, maybe we should be talking about those too. =A0Does anyone else
feel like there's a potential for the options space to be poisoned
by the current middlebox discovery practices?

--
Wes Eddy
MTI Systems


>-----Original Message-----
>From: Andrew Knutsen [mailto:andrew.knutsen@bluecoat.com]
>Sent: Thursday, December 10, 2009 12:01 AM
>To: rick jones
>Cc: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; tcpm@ietf.org
>Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a=
>TCPM WG item
>
>
> =A0 =A0I'll just say again that this solution has been deployed by= several
>vendors for several years (using several invalid option kinds). The onl= y
>way to avoid the problems mentioned below (and others, elsewhere) is to=
>force them (us) all to change, probably at the cost of competitive
>advantage, and possibly by making more fundamental changes in TCP
>itself. We agree that standardization in this area is a worthwhile goal= ,
>however it is most likely to be accomplished incrementally. =A0The curr= ent
>proposal represents a first step in that direction.
>
>Andrew
>
>rick jones wrote:
>> How many angelic options are we going to try to get to dance at on= ce
>> on the header of a TCP SYN segment?
>>
>>> There may be situations where other options are required in th= e SYN
>>> packet which do not leave enough room for all of the target da= ta
>>> necessary for the desired device capability to be advertised. = In
>>> these cases, a shorter alternate device capability may be defi= ned
>>> which signals the request to further negotiate the capability = after
>>> the handshake completes. This will impact performance by intro= ducing
>>> an extra round-trip during connection set-up, but this may be = the
>>> only way to perform the negotiation within the limited TCP opt= ion
>>> space available.
>> An additional round-trip??
>>
>> Not being at all certain I've been around the list/wg long eno= ugh to
>> cast a vote, I'll simply say it sounds dodgy to me.
>>
>> rick jones
>> Wisdom teeth are impacted, people are affected by the effects of >events
>>
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm

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

--00032555992e8bba7e047a785dcf-- From andrew.knutsen@bluecoat.com Fri Dec 11 11:15:33 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 8AFE63A67F0 for ; Fri, 11 Dec 2009 11:15:33 -0800 (PST) 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.001, 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 yinQjtR4owVl for ; Fri, 11 Dec 2009 11:15:30 -0800 (PST) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id 68FB03A6816 for ; Fri, 11 Dec 2009 11:15:30 -0800 (PST) Received: from exchfront1.internal.cacheflow.com (exchfront1 [10.2.2.114]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id nBBJDYOO017405; Fri, 11 Dec 2009 11:15:17 -0800 (PST) Received: from [10.9.84.250] ([10.9.84.250]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Dec 2009 11:13:47 -0800 Message-ID: <4B229A12.7030504@bluecoat.com> Date: Fri, 11 Dec 2009 11:14:26 -0800 From: Andrew Knutsen User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Matt Mathis References: <3AEE4E4B-0470-4093-8803-825DF9890C34@mac.com> <4B20809D.5060402@bluecoat.com> In-Reply-To: Content-Type: multipart/mixed; boundary="------------000907030702050904010507" X-OriginalArrivalTime: 11 Dec 2009 19:13:47.0599 (UTC) FILETIME=[109E8DF0:01CA7A96] Cc: "tcpm@ietf.org" Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG item X-BeenThere: tcpm@ietf.org X-Mailman-Version: 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, 11 Dec 2009 19:15:33 -0000 This is a multi-part message in MIME format. --------------000907030702050904010507 Content-Type: multipart/alternative; boundary="------------050901010503070702080707" --------------050901010503070702080707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I've attached a email from August with this info. Andrew Matt Mathis wrote: > Can we get some of the vendors to 'fess up to this? (Or is anybody > willing to point fingers?) If there is more than one, I think we > (tcpm) had better not stand in the way of an attempt at > standardisation, and should perhaps take the opposite stance: the > guilty parties MUST attempt to standardise what they are doing, and > get the proper IANA option codes. > > It would be much better to have this done out in the open, in tcpm and > the IETF. > > Thanks, > --MM-- > ------------------------------------------- > Matt Mathis http://staff.psc.edu/mathis > Work:412.268.3319 Home/Cell:412.654.7529 > ------------------------------------------- > Evil is defined by mortals who think they know > "The Truth" and use force to apply it to others. > > > On Thu, Dec 10, 2009 at 10:19 AM, Eddy, Wesley M. (GRC-MS00)[ASRC > AEROSPACE CORP] > wrote: > > Speaking as an individual (not a WG co-chair), it was an eye-opener > for me to discover that there are N vendors, each of which is doing > something similar to this, and they're picking their own TCP option > numbers (not getting them properly allocated and documented). > > That's "really bad". It basically turns the space of what we think > are unused options numbers into a minefield of somewhat-used options > numbers. In the sense that this proposal is a possible step towards > fixing that in the long term, I can support it. > > It's possible that there are other approaches to fixing the situation; > if so, maybe we should be talking about those too. Does anyone else > feel like there's a potential for the options space to be poisoned > by the current middlebox discovery practices? > > -- > Wes Eddy > MTI Systems > > > >-----Original Message----- > >From: Andrew Knutsen [mailto:andrew.knutsen@bluecoat.com > ] > >Sent: Thursday, December 10, 2009 12:01 AM > >To: rick jones > >Cc: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; > tcpm@ietf.org > >Subject: Re: [tcpm] poll for consensus on Middlebox Discover > draft as a > >TCPM WG item > > > > > > I'll just say again that this solution has been deployed by > several > >vendors for several years (using several invalid option kinds). > The only > >way to avoid the problems mentioned below (and others, elsewhere) > is to > >force them (us) all to change, probably at the cost of competitive > >advantage, and possibly by making more fundamental changes in TCP > >itself. We agree that standardization in this area is a > worthwhile goal, > >however it is most likely to be accomplished incrementally. The > current > >proposal represents a first step in that direction. > > > >Andrew > > > >rick jones wrote: > >> How many angelic options are we going to try to get to dance at > once > >> on the header of a TCP SYN segment? > >> > >>> There may be situations where other options are required in > the SYN > >>> packet which do not leave enough room for all of the target data > >>> necessary for the desired device capability to be advertised. In > >>> these cases, a shorter alternate device capability may be defined > >>> which signals the request to further negotiate the capability > after > >>> the handshake completes. This will impact performance by > introducing > >>> an extra round-trip during connection set-up, but this may be the > >>> only way to perform the negotiation within the limited TCP option > >>> space available. > >> An additional round-trip?? > >> > >> Not being at all certain I've been around the list/wg long > enough to > >> cast a vote, I'll simply say it sounds dodgy to me. > >> > >> rick jones > >> Wisdom teeth are impacted, people are affected by the effects of > >events > >> > >> _______________________________________________ > >> 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 > > --------------050901010503070702080707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
    I've attached a email from August with this info.

Andrew

Matt Mathis wrote:
Can we get some of the vendors to 'fess up to this?  (Or is anybody willing to point fingers?) If there is more than one, I think we (tcpm) had better not stand in the way of an attempt at standardisation, and should perhaps take the opposite stance: the guilty parties MUST attempt to standardise what they are doing, and get the proper IANA option codes.

It would be much better to have this done out in the open, in tcpm and the IETF.

Thanks,
--MM--
-------------------------------------------
Matt Mathis      http://staff.psc.edu/mathis
Work:412.268.3319   Home/Cell:412.654.7529
-------------------------------------------
Evil is defined by mortals who think they know
"The Truth" and use force to apply it to others.


On Thu, Dec 10, 2009 at 10:19 AM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] <wesley.m.eddy@nasa.gov> wrote:
Speaking as an individual (not a WG co-chair), it was an eye-opener
for me to discover that there are N vendors, each of which is doing
something similar to this, and they're picking their own TCP option
numbers (not getting them properly allocated and documented).

That's "really bad".  It basically turns the space of what we think
are unused options numbers into a minefield of somewhat-used options
numbers.  In the sense that this proposal is a possible step towards
fixing that in the long term, I can support it.

It's possible that there are other approaches to fixing the situation;
if so, maybe we should be talking about those too.  Does anyone else
feel like there's a potential for the options space to be poisoned
by the current middlebox discovery practices?

--
Wes Eddy
MTI Systems


>-----Original Message-----
>From: Andrew Knutsen [mailto:andrew.knutsen@bluecoat.com]
>Sent: Thursday, December 10, 2009 12:01 AM
>To: rick jones
>Cc: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; tcpm@ietf.org
>Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a
>TCPM WG item
>
>
>    I'll just say again that this solution has been deployed by several
>vendors for several years (using several invalid option kinds). The only
>way to avoid the problems mentioned below (and others, elsewhere) is to
>force them (us) all to change, probably at the cost of competitive
>advantage, and possibly by making more fundamental changes in TCP
>itself. We agree that standardization in this area is a worthwhile goal,
>however it is most likely to be accomplished incrementally.  The current
>proposal represents a first step in that direction.
>
>Andrew
>
>rick jones wrote:
>> How many angelic options are we going to try to get to dance at once
>> on the header of a TCP SYN segment?
>>
>>> There may be situations where other options are required in the SYN
>>> packet which do not leave enough room for all of the target data
>>> necessary for the desired device capability to be advertised. In
>>> these cases, a shorter alternate device capability may be defined
>>> which signals the request to further negotiate the capability after
>>> the handshake completes. This will impact performance by introducing
>>> an extra round-trip during connection set-up, but this may be the
>>> only way to perform the negotiation within the limited TCP option
>>> space available.
>> An additional round-trip??
>>
>> Not being at all certain I've been around the list/wg long enough to
>> cast a vote, I'll simply say it sounds dodgy to me.
>>
>> rick jones
>> Wisdom teeth are impacted, people are affected by the effects of
>events
>>
>> _______________________________________________
>> 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


--------------050901010503070702080707-- --------------000907030702050904010507 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Attached Message" Received: from webmail.internal.cacheflow.com ([216.52.23.20]) by bcs-mail03.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Aug 2009 15:52:54 -0700 Received: from whisker.bluecoat.com ([216.52.23.28]) by webmail.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Aug 2009 15:52:54 -0700 Received: from p01c11m062.mxlogic.net (mxl144v247.mxlogic.net [208.65.144.247]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n7DMqrKx017832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 13 Aug 2009 15:52:53 -0700 (PDT) Received: from unknown [64.170.98.32] (EHLO mail.ietf.org) by p01c11m062.mxlogic.net (mxl_mta-6.3.0-4) with ESMTP id 449948a4.0.3055581.00-034.3902949.p01c11m062.mxlogic.net (envelope-from ); Thu, 13 Aug 2009 16:52:52 -0600 (MDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C97B3A6D0C; Thu, 13 Aug 2009 15:52:47 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17FC83A6D0C for ; Thu, 13 Aug 2009 15:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 zr5UcFjGQBZH for ; Thu, 13 Aug 2009 15:52:43 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id 487853A692B for ; Thu, 13 Aug 2009 15:52:43 -0700 (PDT) Received: from exchfront1.internal.cacheflow.com (exchfront1 [10.2.2.114]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n7DMp1gZ017630; Thu, 13 Aug 2009 15:52:47 -0700 (PDT) Received: from [10.9.84.209] ([10.9.84.209]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Aug 2009 15:51:57 -0700 Message-ID: <4A84990C.9080002@bluecoat.com> Date: Thu, 13 Aug 2009 15:51:56 -0700 From: Andrew Knutsen User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" References: <4A775C60.7030204@bluecoat.com> <4A8460BE.1060105@bluecoat.com> <4A847050.7080007@bluecoat.com> In-Reply-To: X-OriginalArrivalTime: 13 Aug 2009 22:51:57.0415 (UTC) FILETIME=[A92FF770:01CA1C68] Cc: Jamshid Mahdavi , Ron Frederick , Qing Li , "tcpm@ietf.org" , Wei Jen Yeh Subject: Re: [tcpm] New ID available: TCP Option for Transparent Middlebox Discovery X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="=_reb-r7885D639-t4A849945" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org X-Processed-By: Rebuild v2.0-0 X-Spam: [F=0.0109755748; B=0.500(0); spf=0.500; CM=0.500; MH=0.500(2009081337); R=0.042(10971312625); S=0.200(2009071501); SC=none] X-MAIL-FROM: X-SOURCE-IP: [64.170.98.32] X-AnalysisOut: [v=1.0 c=1 a=YIYwsioZDMQA:10 a=8DnW6UiazkWc0BlsFzIHow==:17 ] X-AnalysisOut: [a=g0wtaXY6AAAA:8 a=of8oNcslYk3N1owTup4A:9 a=tGSJ06_chKpfe5] X-AnalysisOut: [v5jvsA:7 a=odm0A9VLCtEUjAvg7mseVBHFLW4A:4 a=22CU4wgijFUA:1] X-AnalysisOut: [0 a=z7R7uwx_P_EA:10 a=DWS6ea1utk0A:10 a=4V-xtCPZzMRN9_Ge:2] X-AnalysisOut: [1 a=qEIzwBlHkK47bQzj:21 a=oGduJeTZIYKW6SRU7xAA:9 a=pvRbgNG] X-AnalysisOut: [HUU_jLcFqEVUA:7 a=4FjaJuy_DeZjx0RQ6bEfffmtvSYA:4 a=48vgC7m] X-AnalysisOut: [UAAAA:8 a=fbvV29lhQbCPir5DFLEA:9 a=qjb8vFPnudwxp_pOvL-ObUh] X-AnalysisOut: [4dZgA:4 a=lZB815dzVvQA:10] Return-Path: tcpm-bounces@ietf.org This is a multi-part MIME message. --=_reb-r7885D639-t4A849945 Content-Type: multipart/alternative; boundary="=_reb-r6661B56E-t4A849945" This is a multi-part MIME message. --=_reb-r6661B56E-t4A849945 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I'll put my responses inline this time... Eddy, Wesley M. (GRC-MS00)[Verizon] wrote: > Ok; just a couple easy follow-up questions: > > >> -----Original Message----- >> From: Andrew Knutsen [mailto:andrew.knutsen@bluecoat.com] >> Sent: Thursday, August 13, 2009 3:58 PM >> >> To answer your fundamental question, yes this is existing >> technology, implemented by at least three companies for several years. >> You can check our website (www.bluecoat.com) for one example. This >> assignment will not change the basic operation of these WAN Optimization >> products. >> > > > Ok; so what option number do they use? Do they all use the same one, > or does each company pick its own? How was the option format arrived > at (is it just Bluecoat's or do all the vendors use their own variation)? > I guess that's all just background information that's needed to put the > effort in context. > > > We use one of the "experimental" numbers, 0xFD. Cisco uses 0x21, and Riverbed uses both 0x4C and 0x4E. You can draw your own conclusions on how they were picked ;-). Although this info can be easily "sniffed", its probably not appropriate to put it in the draft. In fact, I'm not making any promises or representations about BlueCoats, or anyone else's, use or non-use of any of these or any other numbers in the future or the past. I hope that keeps the lawyers happy. >> "Transparent detection" refers to the fact that there is no explicit >> detection protocol; instead the detection is piggybacked on the TCP >> connection transaction, which goes through to the OCS (as we say; >> Original Content Server, the host explicitly addresses by the SYN >> packet) if the connection is not intercepted. Again, this is existing >> multivendor practice, used for the reasons mentioned in the draft. >> > > > Ah; so there's terminology confusion between calling a middlebox > transparent (meaning without end-application/transport knowledge) and calling > the detection transparent (meaning no extra packets sent). I guess it would > be more clear as "in-band detection"? > > > Well, our implementation is transparent in both ways.. although another vendor uses a slightly different transparent exchange, where extra packets are sent if a peer is detected. The current proposal could be used for many of these mechanisms. "In-band" doesn't really imply that the connection works if the middlebox is not present, does it? The word "transparent" is used fairly widely in the sense of no explicit configuration, although it can also refer to use of the same addresses on a tunnel connection as on the client and server connections (see below). Also, the "no extra packets" isn't a common use of the word, although one might consider it "transparent in time" ;-). Its just a real-world requirement. >> The "R" bit is to detect hosts which misbehave, and reflect options >> back to the sender. This does happen. >> > > > Ick! That makes sense, but it should be explicitly stated in the discussion > of the R-bit if that's its full reason for existing, rather than only mentioned > in passing in the interoperability issues section. > > We felt that it is an interoperability issue, and discussing it earlier would detract from the discussion of the primary purpose. >> Simultaneous opens have never been an issue because this is >> client/server technology. We can make this explicit. >> > > > It seems reasonable to do so. > Will do. > > >> We can add some information to section 7 if desired, but middleboxes >> typically run proprietary operating systems and thus the APIs are not >> standard... >> > > > Right, but (correct this if I'm wrong ...) you have to also modify the > TCP and application on the endpoints that initiate communications, right? > Or will this only be intended for middlebox-to-middlebox? I'm still > trying to understand what an application does now that it knows something > about the middlebox(es), what changes about its behavior? > Our use for this, which I think is the most common, if not the only use at present, is to set up "tunnels" as described in section 1. Since this draft is not a protocol spec, we didn't add detail about how these work. However for the purpose of this discussion: There are usually four "boxes" involved when a tunnel (as described here) is used: the client and the server, which don't know anything about this option, and two middleboxes, which we may call the "edge" (near the client) and the "core" (near the server). However, it is possible for the edge function to be implemented in the client box. It is also possible to have multiple tunnels along a path, so one box is both edge and core. Server and core are less likely to be combined because that would add load to the server. Both the client and the edge can use either explicit or transparent connection methods. The simplest, and currently most common, use of this option is transparent detection of the core by the edge (ie to see if the server is fronted by a core box), for the purpose of setting up a tunnel between two middleboxes. Note that there are other kinds of "tunnels" which are really more like relays, in that there is only one middebox. There are also tunnels where transparency is not appropriate, such as VPN tunnels. The tunnels I'm talking about are most often used for compression (aka WAN Optimization). I could add a lot of pictures to this, but at this level they're just series of boxes with lines between them ;-). Again, we didn't feel this level of background was appropriate for the draft, partly because we don't want to prejudice any future efforts towards protocol-level interoperability in this area, and partly for legal reasons (I haven't compromised myself here, I don't think, but if I went into more detail I might). However perhaps we could add a sentence saying "tunnels", as defined in the draft, are a primary use case. > The draft is pretty good in explaining the format of the option itself, > but doesn't really speak to how the knowledge the option conveys gets > used productively. As the application-writer, now that a know > company X's gizmo 123 is in my path, how does that affect me versus > not knowing it, or knowing that company Y's doohickey 456 is on the path? > In order to request interception by company X, you'd want to find out how they registered their option (OUI or IANA), and what particular info they want in the option. Then you'd need to know what to do if they responded. Also, you wouldn't really need this if you knew what was in the path (you'd likely use an explicit arrangement). However, if you were writing a server-side app and looking at all the options received, you'd at least know to ignore this option. Or, if you were writing a network monitoring tool, you could keep track of interception requests and responses. If you were writing a firewall, you could do policy on it. Etc... Andrew > > >> And yes, WAN Optimization can be considered a layering >> violation, along with most other security and load-balancing >> middleboxes, but that won't make them go away... >> > > > Fully understood and I don't disagree :). > > > --------------------------- > Wes Eddy > Network & Systems Architect > Verizon FNS / NASA GRC > Office: (216) 433-6682 > --------------------------- > --=_reb-r6661B56E-t4A849945 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
    I'll put my responses inline this time... 

Eddy, Wesley M. (GRC-MS00)[Verizon] wrote: 
Ok; just a couple easy follow-up questions:

  
-----Original Message-----
From: Andrew Knutsen [mailto:andrew.knutsen@bluecoat.com]
Sent: Thursday, August 13, 2009 3:58 PM

   To answer your fundamental question, yes this is existing
technology, implemented by at least three companies for several years.
You can check our website (www.bluecoat.com) for one example. This
assignment will not change the basic operation of these WAN Optimization
products.
    


Ok; so what option number do they use?  Do they all use the same one,
or does each company pick its own?  How was the option format arrived
at (is it just Bluecoat's or do all the vendors use their own variation)?
I guess that's all just background information that's needed to put the
effort in context.
    We use one of the "experimental" numbers, 0xFD.  Cisco uses 0x21, and Riverbed uses both 0x4C and 0x4E. You can draw your own conclusions on how they were picked ;-). Although this info can be easily "sniffed", its probably not appropriate to put it in the draft. In fact, I'm not making any promises or representations about BlueCoats, or anyone else's, use or non-use of any of these or any other numbers in the future or the past.  I hope that keeps the lawyers happy.

  

    
   "Transparent detection" refers to the fact that there is no explicit
detection protocol; instead the detection is piggybacked on the TCP
connection transaction, which goes through to the OCS (as we say;
Original Content Server, the host explicitly addresses by the SYN
packet) if the connection is not intercepted.  Again, this is existing
multivendor practice, used for the reasons mentioned in the draft.
    

  

  


Ah; so there's terminology confusion between calling a middlebox
transparent (meaning without end-application/transport knowledge) and calling
the detection transparent (meaning no extra packets sent).  I guess it would
be more clear as "in-band detection"?


  



    Well, our implementation is transparent in both ways..  although
another vendor uses a slightly different transparent exchange, where
extra packets are sent if a peer is detected.  The current proposal
could be used for many of these mechanisms.  "In-band" doesn't really
imply that the connection works if the middlebox is not present, does
it?



    The word "transparent" is used fairly widely in the sense of no
explicit configuration, although it can also refer to use of the same
addresses on a tunnel connection as on the client and server
connections (see below).



    Also, the "no extra packets" isn't a common use of the word,
although one might consider it "transparent in time" ;-). Its just a
real-world requirement.





  

  

    
   The "R" bit is to detect hosts which misbehave, and reflect options
back to the sender.  This does happen.
    

  

  


Ick!  That makes sense, but it should be explicitly stated in the discussion
of the R-bit if that's its full reason for existing, rather than only mentioned
in passing in the interoperability issues section.

  



    We felt that it is an interoperability issue, and discussing it
earlier would detract from the discussion of the primary purpose.





  

    
   Simultaneous opens have never been an issue because this is
client/server technology. We can make this explicit.
    

  

  


It seems reasonable to do so.
  



    Will do.



  

  

  

    
   We can add some information to section 7 if desired, but middleboxes
typically run proprietary operating systems and thus the APIs are not
standard...
    

  

  


Right, but (correct this if I'm wrong ...) you have to also modify the
TCP and application on the endpoints that initiate communications, right?
Or will this only be intended for middlebox-to-middlebox?  I'm still
trying to understand what an application does now that it knows something
about the middlebox(es), what changes about its behavior?
  



    Our use for this, which I think is the most common, if not the only
use at present, is to set up "tunnels" as described in section 1. Since
this draft is not a protocol spec, we didn't add detail about how these
work.  However for the purpose of this discussion:



     There are usually four "boxes" involved when a tunnel (as
described here) is used: the client and the server, which don't know
anything about this option, and two middleboxes, which we may call the
"edge" (near the client) and the "core" (near the server). However, it
is possible for the edge function to be implemented in the client box.
It is also possible to have multiple tunnels along a path, so one box
is both edge and core. Server and core are less likely to be combined
because that would add load to the server.



    Both the client and the edge can use either explicit or transparent
connection methods. The simplest, and currently most common, use of
this option is transparent detection of the core by the edge (ie to see
if the server is fronted by a core box), for the purpose of setting up
a tunnel between two middleboxes.



    Note that there are other kinds of "tunnels" which are really more
like relays, in that there is only one middebox.  There are also
tunnels where transparency is not appropriate, such as VPN tunnels. The
tunnels I'm talking about are most often used for compression (aka WAN
Optimization).



    I could add a lot of pictures to this, but at this level they're
just series of boxes with lines between them ;-).



    Again, we didn't feel this level of background was appropriate for
the draft, partly because we don't want to prejudice any future efforts
towards protocol-level interoperability in this area, and partly for
legal reasons (I haven't compromised myself here, I don't think, but if
I went into more detail I might). However perhaps we could add a
sentence saying "tunnels", as defined in the draft, are a primary use
case.





  
The draft is pretty good in explaining the format of the option itself,
but doesn't really speak to how the knowledge the option conveys gets
used productively.  As the application-writer, now that a know
company X's gizmo 123 is in my path, how does that affect me versus
not knowing it, or knowing that company Y's doohickey 456 is on the path?
  



    In order to request interception by company X, you'd want to find
out how they registered their option (OUI or IANA), and what particular
info they want in the option. Then you'd need to know what to do if
they responded. Also, you wouldn't really need this if you knew what
was in the path (you'd likely use an explicit arrangement).



    However, if you were writing a server-side app and looking at all
the options received, you'd at least know to ignore this option. Or, if
you were writing a network monitoring tool, you could keep track of
interception requests and responses. If you were writing a firewall,
you could do policy on it.  Etc...



Andrew





  

  

  

    
 And yes, WAN Optimization can be considered a layering
violation, along with most other security and load-balancing
middleboxes, but that won't make them go away...
    

  

  


Fully understood and I don't disagree :).


---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------
  








--=_reb-r6661B56E-t4A849945--


--=_reb-r7885D639-t4A849945
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

--=_reb-r7885D639-t4A849945--


--------------000907030702050904010507--

From touch@ISI.EDU  Tue Dec 22 12:14: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 C9EEE3A681C for ; Tue, 22 Dec 2009 12:14:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.392
X-Spam-Level: 
X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmhtHzj7AqYa for ; Tue, 22 Dec 2009 12:14:14 -0800 (PST)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 124513A67B3 for ; Tue, 22 Dec 2009 12:14:14 -0800 (PST)
Received: from [75.215.214.226] (226.sub-75-215-214.myvzw.com [75.215.214.226]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nBMKDP3t024131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 22 Dec 2009 12:13:28 -0800 (PST)
Message-ID: <4B312865.5000103@isi.edu>
Date: Tue, 22 Dec 2009 12:13:25 -0800
From: Joe Touch 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" 
References: 	<3AEE4E4B-0470-4093-8803-825DF9890C34@mac.com>	<4B20809D.5060402@bluecoat.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" 
Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG	item
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 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, 22 Dec 2009 20:14:14 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, Wes (et al.),

Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote:
> Speaking as an individual (not a WG co-chair), it was an eye-opener
> for me to discover that there are N vendors, each of which is doing
> something similar to this, and they're picking their own TCP option
> numbers (not getting them properly allocated and documented).
> 
> That's "really bad".  

I agree. It's hard to understand why TCPM should take this on as a WG
item if the assumption is that the vendors won't follow the specs.

So far, what I've seen in the discussion seems to blow the size of the
options out of the water. It doesn't appear compatible with existing use
of the option space.

Taking this on as a WG item appears to both endorse the current method
and to assume that we can find a way to develop it as a useful standard.
It seems like we have a ways to go before reaching that conclusion.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAksxKGUACgkQE5f5cImnZrv62gCfdLpu44cdJQCJC0VT+L1VCSPs
jgIAoKQcQCCMgHW8+KVDlj4T4/ACHrXN
=PZ5g
-----END PGP SIGNATURE-----

From andrew.knutsen@bluecoat.com  Tue Dec 22 12:38: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 C19623A681E for ; Tue, 22 Dec 2009 12:38:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 L+0EcKz+4cl6 for ; Tue, 22 Dec 2009 12:38:50 -0800 (PST)
Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id A12A93A69CA for ; Tue, 22 Dec 2009 12:38:50 -0800 (PST)
Received: from exchfront1.internal.cacheflow.com (exchfront1 [10.2.2.114]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id nBMKcXsB005004; Tue, 22 Dec 2009 12:38:34 -0800 (PST)
Received: from [10.9.84.250] ([10.9.84.250]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Dec 2009 12:38:28 -0800
Message-ID: <4B312E44.3050303@bluecoat.com>
Date: Tue, 22 Dec 2009 12:38:28 -0800
From: Andrew Knutsen 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Joe Touch 
References: 	<3AEE4E4B-0470-4093-8803-825DF9890C34@mac.com>	<4B20809D.5060402@bluecoat.com>  <4B312865.5000103@isi.edu>
In-Reply-To: <4B312865.5000103@isi.edu>
Content-Type: multipart/alternative; boundary="------------050009010501070606070909"
X-OriginalArrivalTime: 22 Dec 2009 20:38:28.0754 (UTC) FILETIME=[B7C48720:01CA8346]
Cc: "tcpm@ietf.org" 
Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG	item
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 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, 22 Dec 2009 20:38:51 -0000

This is a multi-part message in MIME format.
--------------050009010501070606070909
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


    I'll try to be nice here, but this is getting repetitious.  However 
as Dr. SNMP says, "Repetition is the key to learning...  I'll say it 
again... Repetition is the key to learning".

    Vendors cannot follow specs that do not exist.  The spec will not 
exist until we adopt it.  Saying we shouldn't adopt it because it hasn't 
been adopted does not seem like a reasonable argument to me.

    Perhaps it seems odd, or heretical, but this option, or similar, is 
in fact "existing use of the option space".  This is because the fact 
that a spec does not exist does not preclude implementation and 
widespread deployment if a need (ie market) exists.

    The area we are dealing with here, middleboxes, is a very real part 
of the Internet which is not well dealt with using the formal model of a 
layered, end-to-end TCP protocol.  Lets remember the scientific method: 
rather than keeping faith in a model which does not match experience 
(and denying the incongruities), its more effective to change the model 
to fit experience.

   If its the consensus of the group, the IETF can continue to deny this 
aspect of reality.  All that will happen is that reality will continue 
to diverge from the IETF model (and the option space will become more 
chaotic).  I don't think that would be a desirable outcome.

Andrew

PS Happy Holidays!
AK

Joe Touch wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi, Wes (et al.),
>
> Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote:
>   
>> Speaking as an individual (not a WG co-chair), it was an eye-opener
>> for me to discover that there are N vendors, each of which is doing
>> something similar to this, and they're picking their own TCP option
>> numbers (not getting them properly allocated and documented).
>>
>> That's "really bad".  
>>     
>
> I agree. It's hard to understand why TCPM should take this on as a WG
> item if the assumption is that the vendors won't follow the specs.
>
> So far, what I've seen in the discussion seems to blow the size of the
> options out of the water. It doesn't appear compatible with existing use
> of the option space.
>
> Taking this on as a WG item appears to both endorse the current method
> and to assume that we can find a way to develop it as a useful standard.
> It seems like we have a ways to go before reaching that conclusion.
>
> Joe
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
>
> iEYEARECAAYFAksxKGUACgkQE5f5cImnZrv62gCfdLpu44cdJQCJC0VT+L1VCSPs
> jgIAoKQcQCCMgHW8+KVDlj4T4/ACHrXN
> =PZ5g
> -----END PGP SIGNATURE-----
>   


--------------050009010501070606070909
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  
  




    I'll try to be nice here, but this is getting repetitious.  However
as Dr. SNMP says, "Repetition is the key to learning...  I'll say it
again... Repetition is the key to learning".



    Vendors cannot follow specs that do not exist.  The spec will not
exist until we adopt it.  Saying we shouldn't adopt it because it
hasn't been adopted does not seem like a reasonable argument to me.



    Perhaps it seems odd, or heretical, but this option, or similar, is
in fact "existing use of the option space".  This is because the fact
that a spec does not exist does not preclude implementation and
widespread deployment if a need (ie market) exists.



    The area we are dealing with here, middleboxes, is a very real part
of the Internet which is not well dealt with using the formal model of
a layered, end-to-end TCP protocol.  Lets remember the scientific
method: rather than keeping faith in a model which does not match
experience (and denying the incongruities), its more effective to
change the model to fit experience.



   If its the consensus of the group, the IETF can continue to deny
this aspect of reality.  All that will happen is that reality will
continue to diverge from the IETF model (and the option space will
become more chaotic).  I don't think that would be a desirable outcome.



Andrew



PS Happy Holidays!

AK



Joe Touch wrote:


  
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, Wes (et al.),

Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote:
  

  

    
Speaking as an individual (not a WG co-chair), it was an eye-opener
for me to discover that there are N vendors, each of which is doing
something similar to this, and they're picking their own TCP option
numbers (not getting them properly allocated and documented).

That's "really bad".  
    

  

  

I agree. It's hard to understand why TCPM should take this on as a WG
item if the assumption is that the vendors won't follow the specs.

So far, what I've seen in the discussion seems to blow the size of the
options out of the water. It doesn't appear compatible with existing use
of the option space.

Taking this on as a WG item appears to both endorse the current method
and to assume that we can find a way to develop it as a useful standard.
It seems like we have a ways to go before reaching that conclusion.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAksxKGUACgkQE5f5cImnZrv62gCfdLpu44cdJQCJC0VT+L1VCSPs
jgIAoKQcQCCMgHW8+KVDlj4T4/ACHrXN
=PZ5g
-----END PGP SIGNATURE-----
  








--------------050009010501070606070909--

From touch@ISI.EDU  Tue Dec 22 13:18: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 8DA8F3A68F6 for ; Tue, 22 Dec 2009 13:18:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.427
X-Spam-Level: 
X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=0.172,  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 eDMFf8etcdjn for ; Tue, 22 Dec 2009 13:18:33 -0800 (PST)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 9BF313A68E7 for ; Tue, 22 Dec 2009 13:18:33 -0800 (PST)
Received: from [75.215.214.226] (226.sub-75-215-214.myvzw.com [75.215.214.226]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nBMLI0oC008411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 22 Dec 2009 13:18:03 -0800 (PST)
Message-ID: <4B313787.1020907@isi.edu>
Date: Tue, 22 Dec 2009 13:17:59 -0800
From: Joe Touch 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Andrew Knutsen 
References: 	<3AEE4E4B-0470-4093-8803-825DF9890C34@mac.com>	<4B20809D.5060402@bluecoat.com>  <4B312865.5000103@isi.edu> <4B312E44.3050303@bluecoat.com>
In-Reply-To: <4B312E44.3050303@bluecoat.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] poll for consensus on Middlebox Discover draft as a TCPM WG	item
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 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, 22 Dec 2009 21:18:35 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Andrew Knutsen wrote:
> 
>     I'll try to be nice here, but this is getting repetitious.  However
> as Dr. SNMP says, "Repetition is the key to learning...  I'll say it
> again... Repetition is the key to learning".
> 
>     Vendors cannot follow specs that do not exist.  The spec will not
> exist until we adopt it.  Saying we shouldn't adopt it because it hasn't
> been adopted does not seem like a reasonable argument to me.

FWIW, what I was saying was closer to:

	Vendors are violating the existing specs. It is not clear
	why we should expect them to follow new specs.

There are allowances in the spec for experimental options. The claim is
that these are not the option numbers being used.

>     Perhaps it seems odd, or heretical, but this option, or similar, is
> in fact "existing use of the option space".  This is because the fact
> that a spec does not exist does not preclude implementation and
> widespread deployment if a need (ie market) exists.

The TCP roadmap describes the use of existing options. It's not clear
that there is space for the option this proposal describes. I've raised
that on this list before.

>     The area we are dealing with here, middleboxes, is a very real part
> of the Internet which is not well dealt with using the formal model of a
> layered, end-to-end TCP protocol.  Lets remember the scientific method:
> rather than keeping faith in a model which does not match experience
> (and denying the incongruities), its more effective to change the model
> to fit experience.

FWIW, I wasn't saying we should never change TCP, or that this change
would never happen. I am saying that we don't seem to have a viable
change that is consistent with the whole of how TCP is used in the
Internet. That doesn't mean it doesn't already work in specific places.

I was implying that taking this on as a WG *document* was premature. We
can certainly take it on as an issue and see whether we have consensus
on how to proceed, but I didn't see that yet.

Joe

> Joe Touch wrote:
> Hi, Wes (et al.),
> 
> Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote:
>   
>>>> Speaking as an individual (not a WG co-chair), it was an eye-opener
>>>> for me to discover that there are N vendors, each of which is doing
>>>> something similar to this, and they're picking their own TCP option
>>>> numbers (not getting them properly allocated and documented).
>>>>
>>>> That's "really bad".  
>>>>     
> 
> I agree. It's hard to understand why TCPM should take this on as a WG
> item if the assumption is that the vendors won't follow the specs.
> 
> So far, what I've seen in the discussion seems to blow the size of the
> options out of the water. It doesn't appear compatible with existing use
> of the option space.
> 
> Taking this on as a WG item appears to both endorse the current method
> and to assume that we can find a way to develop it as a useful standard.
> It seems like we have a ways to go before reaching that conclusion.
> 
> Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAksxN4cACgkQE5f5cImnZrs5AQCgzcYotq18srhi2a7iC6yf46/L
4B0AnA1V6tSbTO7LNndmirzoYU8+k9c9
=sqwR
-----END PGP SIGNATURE-----

From andrew.knutsen@bluecoat.com  Tue Dec 22 13:33: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 42FB63A6A08 for ; Tue, 22 Dec 2009 13:33:35 -0800 (PST)
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 wGDmEhitqjgt for ; Tue, 22 Dec 2009 13:33:34 -0800 (PST)
Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id 691623A6894 for ; Tue, 22 Dec 2009 13:33:34 -0800 (PST)
Received: from exchfront1.internal.cacheflow.com (exchfront1 [10.2.2.114]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id nBMLXHBv012993; Tue, 22 Dec 2009 13:33:17 -0800 (PST)
Received: from [10.9.84.250] ([10.9.84.250]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Dec 2009 13:33:12 -0800
Message-ID: <4B313B17.8050502@bluecoat.com>
Date: Tue, 22 Dec 2009 13:33:11 -0800
From: Andrew Knutsen 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Joe Touch 
References: 	<3AEE4E4B-0470-4093-8803-825DF9890C34@mac.com>	<4B20809D.5060402@bluecoat.com>  <4B312865.5000103@isi.edu> <4B312E44.3050303@bluecoat.com> <4B313787.1020907@isi.edu>
In-Reply-To: <4B313787.1020907@isi.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 22 Dec 2009 21:33:12.0251 (UTC) FILETIME=[5CE268B0:01CA834E]
Cc: "tcpm@ietf.org" 
Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG	item
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 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, 22 Dec 2009 21:33:35 -0000

Joe Touch wrote:
> FWIW, what I was saying was closer to:
>
> 	Vendors are violating the existing specs. It is not clear
> 	why we should expect them to follow new specs.
>   

    Which spec is being violated, other than the implicit directive to 
not do anything thats already in a spec?

> There are allowances in the spec for experimental options. The claim is
> that these are not the option numbers being used.
>   

    In fact, one vendor (us ;-), is using the experimental kind.  
Unfortunately, that kind is not intended for deployment.

    WAN Optimization is not an experiment.  I'll say it again.  WAN 
Optimization is not an experiment.  Its a billion dollar industry.

> The TCP roadmap describes the use of existing options. It's not clear
> that there is space for the option this proposal describes. I've raised
> that on this list before.
>   

    This option is already in wide use, with very few (if any) space 
problems.  I'll say it again.  This option is already in wide use, with 
very few (if any) space problems.

> FWIW, I wasn't saying we should never change TCP, or that this change
> would never happen. I am saying that we don't seem to have a viable
> change that is consistent with the whole of how TCP is used in the
> Internet. That doesn't mean it doesn't already work in specific places.
>   

    I'll say it again.  This is in fact how TCP is used in the Internet.

> I was implying that taking this on as a WG *document* was premature. We
> can certainly take it on as an issue and see whether we have consensus
> on how to proceed, but I didn't see that yet.
>   

    At some point I'm going to get tired of repeating myself.  At that 
point, if this proposal dies, we may try for "Informational" status.   
However, that may not be sufficient to compel our organization to change 
over to the new kind, much less providing motivation for other 
organizations to do the same.

Andrew


From touch@ISI.EDU  Tue Dec 22 13:47: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 E20D83A6839 for ; Tue, 22 Dec 2009 13:47:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level: 
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151,  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 lPIH0abvH+sn for ; Tue, 22 Dec 2009 13:47:34 -0800 (PST)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 0EE7C3A6867 for ; Tue, 22 Dec 2009 13:47:34 -0800 (PST)
Received: from [75.215.214.226] (226.sub-75-215-214.myvzw.com [75.215.214.226]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nBMLkbHH014914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 22 Dec 2009 13:46:40 -0800 (PST)
Message-ID: <4B313E3D.6000906@isi.edu>
Date: Tue, 22 Dec 2009 13:46:37 -0800
From: Joe Touch 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Andrew Knutsen 
References: 	<3AEE4E4B-0470-4093-8803-825DF9890C34@mac.com>	<4B20809D.5060402@bluecoat.com>  <4B312865.5000103@isi.edu> <4B312E44.3050303@bluecoat.com> <4B313787.1020907@isi.edu> <4B313B17.8050502@bluecoat.com>
In-Reply-To: <4B313B17.8050502@bluecoat.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] poll for consensus on Middlebox Discover draft as a TCPM WG	item
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 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, 22 Dec 2009 21:47:35 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Andrew Knutsen wrote:
> Joe Touch wrote:
>> FWIW, what I was saying was closer to:
>>
>>     Vendors are violating the existing specs. It is not clear
>>     why we should expect them to follow new specs.
>>   
> 
>    Which spec is being violated, other than the implicit directive to
> not do anything thats already in a spec?

The use of TCP option numbers other than experimental.
RFC4727 defines those numbers.

>> There are allowances in the spec for experimental options. The claim is
>> that these are not the option numbers being used.
>>   
> 
>    In fact, one vendor (us ;-), is using the experimental kind. 
> Unfortunately, that kind is not intended for deployment.

Right - that's why this is the correct next step. I'm not disagreeing
with that part.

>    WAN Optimization is not an experiment.  I'll say it again.  WAN
> Optimization is not an experiment.  Its a billion dollar industry.

Please see the Tao of the IETF. Experimental also means there are
unanswered questions to a protocol that has not yet been approved for
standards track, so yes, this is an experiment.

>> The TCP roadmap describes the use of existing options. It's not clear
>> that there is space for the option this proposal describes. I've raised
>> that on this list before.
> 
>    This option is already in wide use, with very few (if any) space
> problems.  I'll say it again.  This option is already in wide use, with
> very few (if any) space problems.

You can say it a third time - it won't make it any more relevant.
Simultaneous open is never seen on some nodes, but that doesn't mean
it's any less relevant in the standard, or that we should remove those
protocol states.

What we see in the wild *today* is only a subset of what we design a
protocol for.

>> FWIW, I wasn't saying we should never change TCP, or that this change
>> would never happen. I am saying that we don't seem to have a viable
>> change that is consistent with the whole of how TCP is used in the
>> Internet. That doesn't mean it doesn't already work in specific places.
> 
>    I'll say it again.  This is in fact how TCP is used in the Internet.

See above.

>> I was implying that taking this on as a WG *document* was premature. We
>> can certainly take it on as an issue and see whether we have consensus
>> on how to proceed, but I didn't see that yet.
> 
>    At some point I'm going to get tired of repeating myself.  At that
> point, if this proposal dies, we may try for "Informational" status.  
> However, that may not be sufficient to compel our organization to change
> over to the new kind, much less providing motivation for other
> organizations to do the same.

Informational is not an end-run around a WG, either. If the WG thinks
that this option is a bad idea (e.g., not compatible with other uses of
the option space, etc.), then it may not be documented as a spec - it
could as easily be documented in a future "TCP implementation issues" RFC.

Just plopping something out there is not justification for the IETF to
standardize it.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAksxPj0ACgkQE5f5cImnZrtWfwCg2rN8wijy0jKy3gyq/hclC7QI
iOEAoNr+1DlXrqy7BdpVGc0g1WLbMGCY
=Ogon
-----END PGP SIGNATURE-----

From andrew.knutsen@bluecoat.com  Tue Dec 22 14:02: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 28A563A6839 for ; Tue, 22 Dec 2009 14:02:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 YlgQkySk-Hoo for ; Tue, 22 Dec 2009 14:02:55 -0800 (PST)
Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id 0A0B83A67F0 for ; Tue, 22 Dec 2009 14:02:55 -0800 (PST)
Received: from exchfront1.internal.cacheflow.com (exchfront1 [10.2.2.114]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id nBMM2KmU017615; Tue, 22 Dec 2009 14:02:20 -0800 (PST)
Received: from [10.9.84.250] ([10.9.84.250]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Dec 2009 14:02:15 -0800
Message-ID: <4B3141E7.3020908@bluecoat.com>
Date: Tue, 22 Dec 2009 14:02:15 -0800
From: Andrew Knutsen 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Joe Touch 
References: 	<3AEE4E4B-0470-4093-8803-825DF9890C34@mac.com>	<4B20809D.5060402@bluecoat.com>  <4B312865.5000103@isi.edu> <4B312E44.3050303@bluecoat.com> <4B313787.1020907@isi.edu> <4B313B17.8050502@bluecoat.com> <4B313E3D.6000906@isi.edu>
In-Reply-To: <4B313E3D.6000906@isi.edu>
Content-Type: multipart/alternative; boundary="------------020107060502010205080008"
X-OriginalArrivalTime: 22 Dec 2009 22:02:15.0745 (UTC) FILETIME=[6C167B10:01CA8352]
Cc: "tcpm@ietf.org" 
Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG	item
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 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, 22 Dec 2009 22:02:56 -0000

This is a multi-part message in MIME format.
--------------020107060502010205080008
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


    Well, I think our positions are clear, and I doubt they're going to 
change.  Its up to the rest of the group, as far as I'm concerned.  I've 
invested a lot of time trying to do the right thing here, but at some 
point one just has to rely on the wisdom of the collective.

Andrew

Joe Touch wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Andrew Knutsen wrote:
>   
>> Joe Touch wrote:
>>     
>>> FWIW, what I was saying was closer to:
>>>
>>>     Vendors are violating the existing specs. It is not clear
>>>     why we should expect them to follow new specs.
>>>   
>>>       
>>    Which spec is being violated, other than the implicit directive to
>> not do anything thats already in a spec?
>>     
>
> The use of TCP option numbers other than experimental.
> RFC4727 defines those numbers.
>
>   
>>> There are allowances in the spec for experimental options. The claim is
>>> that these are not the option numbers being used.
>>>   
>>>       
>>    In fact, one vendor (us ;-), is using the experimental kind. 
>> Unfortunately, that kind is not intended for deployment.
>>     
>
> Right - that's why this is the correct next step. I'm not disagreeing
> with that part.
>
>   
>>    WAN Optimization is not an experiment.  I'll say it again.  WAN
>> Optimization is not an experiment.  Its a billion dollar industry.
>>     
>
> Please see the Tao of the IETF. Experimental also means there are
> unanswered questions to a protocol that has not yet been approved for
> standards track, so yes, this is an experiment.
>
>   
>>> The TCP roadmap describes the use of existing options. It's not clear
>>> that there is space for the option this proposal describes. I've raised
>>> that on this list before.
>>>       
>>    This option is already in wide use, with very few (if any) space
>> problems.  I'll say it again.  This option is already in wide use, with
>> very few (if any) space problems.
>>     
>
> You can say it a third time - it won't make it any more relevant.
> Simultaneous open is never seen on some nodes, but that doesn't mean
> it's any less relevant in the standard, or that we should remove those
> protocol states.
>
> What we see in the wild *today* is only a subset of what we design a
> protocol for.
>
>   
>>> FWIW, I wasn't saying we should never change TCP, or that this change
>>> would never happen. I am saying that we don't seem to have a viable
>>> change that is consistent with the whole of how TCP is used in the
>>> Internet. That doesn't mean it doesn't already work in specific places.
>>>       
>>    I'll say it again.  This is in fact how TCP is used in the Internet.
>>     
>
> See above.
>
>   
>>> I was implying that taking this on as a WG *document* was premature. We
>>> can certainly take it on as an issue and see whether we have consensus
>>> on how to proceed, but I didn't see that yet.
>>>       
>>    At some point I'm going to get tired of repeating myself.  At that
>> point, if this proposal dies, we may try for "Informational" status.  
>> However, that may not be sufficient to compel our organization to change
>> over to the new kind, much less providing motivation for other
>> organizations to do the same.
>>     
>
> Informational is not an end-run around a WG, either. If the WG thinks
> that this option is a bad idea (e.g., not compatible with other uses of
> the option space, etc.), then it may not be documented as a spec - it
> could as easily be documented in a future "TCP implementation issues" RFC.
>
> Just plopping something out there is not justification for the IETF to
> standardize it.
>
> Joe
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
>
> iEYEARECAAYFAksxPj0ACgkQE5f5cImnZrtWfwCg2rN8wijy0jKy3gyq/hclC7QI
> iOEAoNr+1DlXrqy7BdpVGc0g1WLbMGCY
> =Ogon
> -----END PGP SIGNATURE-----
>   


--------------020107060502010205080008
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  
  




    Well, I think our positions are clear, and I doubt they're going to
change.  Its up to the rest of the group, as far as I'm concerned. 
I've invested a lot of time trying to do the right thing here, but at
some point one just has to rely on the wisdom of the collective. 



Andrew



Joe Touch wrote:


  
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Andrew Knutsen wrote:
  

  

    
Joe Touch wrote:
    

    

      
FWIW, what I was saying was closer to:

    Vendors are violating the existing specs. It is not clear
    why we should expect them to follow new specs.
  
      

    

    
   Which spec is being violated, other than the implicit directive to
not do anything thats already in a spec?
    

  

  

The use of TCP option numbers other than experimental.
RFC4727 defines those numbers.

  

  

    

      
There are allowances in the spec for experimental options. The claim is
that these are not the option numbers being used.
  
      

    

    
   In fact, one vendor (us ;-), is using the experimental kind. 
Unfortunately, that kind is not intended for deployment.
    

  

  

Right - that's why this is the correct next step. I'm not disagreeing
with that part.

  

  

    
   WAN Optimization is not an experiment.  I'll say it again.  WAN
Optimization is not an experiment.  Its a billion dollar industry.
    

  

  

Please see the Tao of the IETF. Experimental also means there are
unanswered questions to a protocol that has not yet been approved for
standards track, so yes, this is an experiment.

  

  

    

      
The TCP roadmap describes the use of existing options. It's not clear
that there is space for the option this proposal describes. I've raised
that on this list before.
      

    

    
   This option is already in wide use, with very few (if any) space
problems.  I'll say it again.  This option is already in wide use, with
very few (if any) space problems.
    

  

  

You can say it a third time - it won't make it any more relevant.
Simultaneous open is never seen on some nodes, but that doesn't mean
it's any less relevant in the standard, or that we should remove those
protocol states.

What we see in the wild *today* is only a subset of what we design a
protocol for.

  

  

    

      
FWIW, I wasn't saying we should never change TCP, or that this change
would never happen. I am saying that we don't seem to have a viable
change that is consistent with the whole of how TCP is used in the
Internet. That doesn't mean it doesn't already work in specific places.
      

    

    
   I'll say it again.  This is in fact how TCP is used in the Internet.
    

  

  

See above.

  

  

    

      
I was implying that taking this on as a WG *document* was premature. We
can certainly take it on as an issue and see whether we have consensus
on how to proceed, but I didn't see that yet.
      

    

    
   At some point I'm going to get tired of repeating myself.  At that
point, if this proposal dies, we may try for "Informational" status.  
However, that may not be sufficient to compel our organization to change
over to the new kind, much less providing motivation for other
organizations to do the same.
    

  

  

Informational is not an end-run around a WG, either. If the WG thinks
that this option is a bad idea (e.g., not compatible with other uses of
the option space, etc.), then it may not be documented as a spec - it
could as easily be documented in a future "TCP implementation issues" RFC.

Just plopping something out there is not justification for the IETF to
standardize it.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAksxPj0ACgkQE5f5cImnZrtWfwCg2rN8wijy0jKy3gyq/hclC7QI
iOEAoNr+1DlXrqy7BdpVGc0g1WLbMGCY
=Ogon
-----END PGP SIGNATURE-----
  








--------------020107060502010205080008--

From wesley.m.eddy@nasa.gov  Tue Dec 22 14:17: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 02F763A68B0 for ; Tue, 22 Dec 2009 14:17:19 -0800 (PST)
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=[AWL=0.000,  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 8mLbIdFdoiED for ; Tue, 22 Dec 2009 14:17:18 -0800 (PST)
Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id CCD9C3A6935 for ; Tue, 22 Dec 2009 14:17:17 -0800 (PST)
Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 746F6328A1C; Tue, 22 Dec 2009 16:17:00 -0600 (CST)
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 nBMMH1aM027321; Tue, 22 Dec 2009 16:17:01 -0600
Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub06.ndc.nasa.gov ([198.117.4.165]) with mapi; Tue, 22 Dec 2009 16:17:00 -0600
From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" 
To: Andrew Knutsen 
Date: Tue, 22 Dec 2009 16:16:58 -0600
Thread-Topic: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG	item
Thread-Index: AcqDUnvg3v49/mNpTP+mSewBn49glQAAJq6w
Message-ID: 
References:  <3AEE4E4B-0470-4093-8803-825DF9890C34@mac.com> <4B20809D.5060402@bluecoat.com>  <4B312865.5000103@isi.edu> <4B312E44.3050303@bluecoat.com> <4B313787.1020907@isi.edu> <4B313B17.8050502@bluecoat.com> <4B313E3D.6000906@isi.edu> <4B3141E7.3020908@bluecoat.com>
In-Reply-To: <4B3141E7.3020908@bluecoat.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-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-12-22_09:2009-12-12, 2009-12-22, 2009-12-22 signatures=0
Cc: "tcpm@ietf.org" 
Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG	item
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 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, 22 Dec 2009 22:17:19 -0000

Speaking for myself, I think this is probably the right thing to do,
and would support the work in TCPM if adopted.

That said, whether it will actually help to fix the present situation
seems uncertain.  However, what does it cost us if we spec this out
as Experimental and it ends up not getting used?  Some years down the
line, it can be classed as Historic and the option number can be
reaped.  I don't see a problem with that.

The concern expressed about options space is interesting to me, having
grappled with that problem myself in the past.  For the purposes of
this option, which is being used by middleboxes rather than end-hosts,
it seems to me like as long as it fails safe and disables either this
portion of the discovery process or the optimization it permits, when
there's not enough space, then it seems acceptable to me.  It's not
ideal, but seems to be a step better than allowing chaos to reign, as
Andrew tells us it is, and I think that's fitting with the spirit of
the draft.

--
Wes Eddy
MTI Systems


>-----Original Message-----
>From: Andrew Knutsen [mailto:andrew.knutsen@bluecoat.com]
>Sent: Tuesday, December 22, 2009 5:02 PM
>To: Joe Touch
>Cc: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; rick jones;
>tcpm@ietf.org
>Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a
>TCPM WG item
>
>
>    Well, I think our positions are clear, and I doubt they're going to
>change.  Its up to the rest of the group, as far as I'm concerned.  I've
>invested a lot of time trying to do the right thing here, but at some
>point one just has to rely on the wisdom of the collective.
>
>Andrew
>
>Joe Touch wrote:
>
>	-----BEGIN PGP SIGNED MESSAGE-----
>	Hash: SHA1
>
>
>
>	Andrew Knutsen wrote:
>
>
>		Joe Touch wrote:
>
>
>			FWIW, what I was saying was closer to:
>
>			    Vendors are violating the existing specs. It is
>not clear
>			    why we should expect them to follow new specs.
>
>
>
>		   Which spec is being violated, other than the implicit
>directive to
>		not do anything thats already in a spec?
>
>
>
>	The use of TCP option numbers other than experimental.
>	RFC4727 defines those numbers.
>
>
>
>			There are allowances in the spec for experimental
>options. The claim is
>			that these are not the option numbers being used.
>
>
>
>		   In fact, one vendor (us ;-), is using the experimental
>kind.
>		Unfortunately, that kind is not intended for deployment.
>
>
>
>	Right - that's why this is the correct next step. I'm not
>disagreeing
>	with that part.
>
>
>
>		   WAN Optimization is not an experiment.  I'll say it
>again.  WAN
>		Optimization is not an experiment.  Its a billion dollar
>industry.
>
>
>
>	Please see the Tao of the IETF. Experimental also means there are
>	unanswered questions to a protocol that has not yet been approved
>for
>	standards track, so yes, this is an experiment.
>
>
>
>			The TCP roadmap describes the use of existing options.
>It's not clear
>			that there is space for the option this proposal
>describes. I've raised
>			that on this list before.
>
>
>		   This option is already in wide use, with very few (if
>any) space
>		problems.  I'll say it again.  This option is already in
>wide use, with
>		very few (if any) space problems.
>
>
>
>	You can say it a third time - it won't make it any more relevant.
>	Simultaneous open is never seen on some nodes, but that doesn't
>mean
>	it's any less relevant in the standard, or that we should remove
>those
>	protocol states.
>
>	What we see in the wild *today* is only a subset of what we design
>a
>	protocol for.
>
>
>
>			FWIW, I wasn't saying we should never change TCP, or
>that this change
>			would never happen. I am saying that we don't seem to
>have a viable
>			change that is consistent with the whole of how TCP is
>used in the
>			Internet. That doesn't mean it doesn't already work in
>specific places.
>
>
>		   I'll say it again.  This is in fact how TCP is used in
>the Internet.
>
>
>
>	See above.
>
>
>
>			I was implying that taking this on as a WG *document*
>was premature. We
>			can certainly take it on as an issue and see whether
>we have consensus
>			on how to proceed, but I didn't see that yet.
>
>
>		   At some point I'm going to get tired of repeating myself.
>At that
>		point, if this proposal dies, we may try for "Informational"
>status.
>		However, that may not be sufficient to compel our
>organization to change
>		over to the new kind, much less providing motivation for
>other
>		organizations to do the same.
>
>
>
>	Informational is not an end-run around a WG, either. If the WG
>thinks
>	that this option is a bad idea (e.g., not compatible with other
>uses of
>	the option space, etc.), then it may not be documented as a spec -
>it
>	could as easily be documented in a future "TCP implementation
>issues" RFC.
>
>	Just plopping something out there is not justification for the
>IETF to
>	standardize it.
>
>	Joe
>	-----BEGIN PGP SIGNATURE-----
>	Version: GnuPG v1.4.9 (MingW32)
>
>	iEYEARECAAYFAksxPj0ACgkQE5f5cImnZrtWfwCg2rN8wijy0jKy3gyq/hclC7QI
>	iOEAoNr+1DlXrqy7BdpVGc0g1WLbMGCY
>	=3DOgon
>	-----END PGP SIGNATURE-----
>
>


From andrew.knutsen@bluecoat.com  Tue Dec 22 14:42:21 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 39ED83A687F for ; Tue, 22 Dec 2009 14:42:21 -0800 (PST)
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 2lH9rH7SIJlv for ; Tue, 22 Dec 2009 14:42:20 -0800 (PST)
Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id 968213A684A for ; Tue, 22 Dec 2009 14:42:20 -0800 (PST)
Received: from exchfront1.internal.cacheflow.com (exchfront1 [10.2.2.114]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id nBMMg4xB023045; Tue, 22 Dec 2009 14:42:04 -0800 (PST)
Received: from [10.9.84.250] ([10.9.84.250]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Dec 2009 14:41:59 -0800
Message-ID: <4B314B36.9010505@bluecoat.com>
Date: Tue, 22 Dec 2009 14:41:58 -0800
From: Andrew Knutsen 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" 
References: 	<3AEE4E4B-0470-4093-8803-825DF9890C34@mac.com>	<4B20809D.5060402@bluecoat.com>  <4B312865.5000103@isi.edu> <4B312E44.3050303@bluecoat.com> <4B313787.1020907@isi.edu> <4B313B17.8050502@bluecoat.com> <4B313E3D.6000906@isi.edu> <4B3141E7.3020908@bluecoat.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 22 Dec 2009 22:41:59.0011 (UTC) FILETIME=[F8A00330:01CA8357]
Cc: "tcpm@ietf.org" 
Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG	item
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 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, 22 Dec 2009 22:42:21 -0000

Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote:
> That said, whether it will actually help to fix the present situation
> seems uncertain. 

    There is a very good chance that Blue Coat will in fact use the new 
option kind if it is allocated. As our software in the field is updated, 
use of the experimental kind for this no-longer-experimental purpose 
will go down. Our competitors use techniques that are similar enough to 
ours to use this option as well.

Andrew



From jamshid.mahdavi@bluecoat.com  Tue Dec 22 15:49: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 4A9553A6927 for ; Tue, 22 Dec 2009 15:49:19 -0800 (PST)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BANNED, message contains part: multipart/mixed | application/ms-tnef,.tnef,winmail.dat
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]
X-Amavis-Modified: Mail body modified (defanged) by core3.amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtI1QFxG4cW0 for ; Tue, 22 Dec 2009 15:49:18 -0800 (PST)
Content-Type: multipart/mixed; boundary="----------=_1261525759-31635-1"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id F1E6B3A6A7C for ; Tue, 22 Dec 2009 15:49:15 -0800 (PST)
Received: from bcs-mail04.internal.cacheflow.com (bcsmail04.internal.cacheflow.com [10.2.2.56] (may be forged)) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id nBMNmxvI011025 for ; Tue, 22 Dec 2009 15:48:59 -0800 (PST)
Date: Tue, 22 Dec 2009 15:48:53 -0800
Message-ID: 
References: 
From: "Mahdavi, Jamshid" 
To: 
Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG item
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 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, 22 Dec 2009 23:49:19 -0000

This is a multi-part message in MIME format...

------------=_1261525759-31635-1
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

WARNING: contains banned part

------------=_1261525759-31635-1
Content-Type: message/rfc822; x-spam-type=original; name="message"
Content-Disposition: attachment; filename="message"
Content-Transfer-Encoding: 7bit
Content-Description: Original message

Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28])
	by core3.amsl.com (Postfix) with ESMTP id F1E6B3A6A7C
	for ; Tue, 22 Dec 2009 15:49:15 -0800 (PST)
Received: from bcs-mail04.internal.cacheflow.com (bcsmail04.internal.cacheflow.com [10.2.2.56] (may be forged))
	by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id nBMNmxvI011025
	for ; Tue, 22 Dec 2009 15:48:59 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_001_01CA8361.514A02D7"
Subject: Re: poll for consensus on Middlebox Discover draft as a TCPM WG item
Date: Tue, 22 Dec 2009 15:48:53 -0800
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: poll for consensus on Middlebox Discover draft as a TCPM WG item
Thread-Index: AcqDUn+60DoatlUmRYqHfN2MriXVeAAC8uZN
References: 
From: "Mahdavi, Jamshid" 
To: 

This is a multi-part message in MIME format.

------_=_NextPart_001_01CA8361.514A02D7
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


I'd just like to echo some of Andrew's points.  We have a group of =
authors with a history of working with the IETF directly or with IETF =
standards extensively, and when we came together to start working on =
this we came to it with the mindset of wanting to do the right thing.

I think we have heard some very supportive statements from some people =
on the list.  In my interpretation, we have heard a couple of key =
things:

- There is a need for an in-band discovery mechanism.  Several people =
have said this, and we also know from practical experience that there is =
such a need in our products and in the products of other people working =
in this space.

- We don't want people camping out on unallocated option numbers for =
this.

We have also heard a couple of key objections:

- The use of this option will consume too much space in the TCP header.  =
With regards to this point, my observation would be that options are, by =
definition, "optional".  Especially in the case of middleboxes, it is up =
to those devices to decide what would be the best set of options to =
choose for their particular application.  In our experience, space has =
not been a problem, and if it becomes one we would have to make such =
trade-offs.

- I believe there may be some question as to whether vendors would adopt =
this if a standard were created.  We can only speak for ourselves of =
course, but we would certainly intend to adopt it.  Speaking in general =
terms, customers like it when vendors follow standards, so I can't see =
why other vendors would not also follow suit if a standard is provided.

- Finally, I think there was also some question early on about the =
actual usefulness of the mechanism we've proposed.  If we take this on =
as a WG item this is something we'd be happy to get back to discussing.

I might be putting some words into Joe's mouth here, but it sounded like =
you would be ok with adopting the general problem of middlebox discovery =
as a WG item, but not necessarily starting from the solution that we =
have proposed.  I think that if we actually need to go back to starting =
at square one we could do that, although you'll understand why we'd =
prefer not to.

It sounds like in either event we should probably plan for some type of =
in-person discussions at the next IETF.  The March IETF will be pretty =
convenient for us and I think we could commit to some of us being =
present to take the next steps.

--J


------_=_NextPart_001_01CA8361.514A02D7
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Transfer-Encoding: base64

eJ8+IjYXAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEARQAAAFJlOiBwb2xsIGZvciBjb25z
ZW5zdXMgb24gTWlkZGxlYm94IERpc2NvdmVyIGRyYWZ0IGFzIGEgVENQTSBXRyBpdGVtAMsXAQWA
AwAOAAAA2QcMABYADwAwADUAAgB4AQEggAMADgAAANkHDAAWAA8AMAA1AAIAeAEBCYABACEAAAA2
NTgxMkQwRDdCMTQ1NTQ5QjNCQUY4M0ZFNzJDN0Y0QwBHBwEDkAYASA4AADkAAAADACYAAAAAAAMA
NgAAAAAAQAA5ANcCSlFhg8oBHgA9AAEAAAAFAAAAUmU6IAAAAAACAUcAAQAAADYAAABjPVVTO2E9
IDtwPUNBQ0hFRkxPVztsPUJDUy1NQUlMMDQtMDkxMjIyMjM0ODUzWi0zMzYwMQAAAB4ASQABAAAA
HgAAAHRjcG0gRGlnZXN0LCBWb2wgNjgsIElzc3VlIDIwAAAAQABOAIB+rYRSg8oBHgBaAAEAAAAW
AAAAdGNwbS1ib3VuY2VzQGlldGYub3JnAAAAAgFbAAEAAABJAAAAAAAAAIErH6S+oxAZnW4A3QEP
VAIAAAAAdGNwbS1ib3VuY2VzQGlldGYub3JnAFNNVFAAdGNwbS1ib3VuY2VzQGlldGYub3JnAAAA
AAIBXAABAAAAGwAAAFNNVFA6VENQTS1CT1VOQ0VTQElFVEYuT1JHAAAeAF0AAQAAABYAAAB0Y3Bt
LXJlcXVlc3RAaWV0Zi5vcmcAAAACAV4AAQAAAEkAAAAAAAAAgSsfpL6jEBmdbgDdAQ9UAgAAAAB0
Y3BtLXJlcXVlc3RAaWV0Zi5vcmcAU01UUAB0Y3BtLXJlcXVlc3RAaWV0Zi5vcmcAAAAAAgFfAAEA
AAAbAAAAU01UUDpUQ1BNLVJFUVVFU1RASUVURi5PUkcAAB4AZgABAAAABQAAAFNNVFAAAAAAHgBn
AAEAAAAWAAAAdGNwbS1ib3VuY2VzQGlldGYub3JnAAAAHgBoAAEAAAAFAAAAU01UUAAAAAAeAGkA
AQAAABYAAAB0Y3BtLXJlcXVlc3RAaWV0Zi5vcmcAAAAeAHAAAQAAAEEAAABwb2xsIGZvciBjb25z
ZW5zdXMgb24gTWlkZGxlYm94IERpc2NvdmVyIGRyYWZ0IGFzIGEgVENQTSBXRyBpdGVtAAAAAAIB
cQABAAAAGwAAAAHKg1J/utA6GrZVJkWKh3zdjK4l1XgAAvLmTQAeAHQAAQAAAA4AAAB0Y3BtQGll
dGYub3JnAAAAHgAaDAEAAAARAAAATWFoZGF2aSwgSmFtc2hpZAAAAAAeAB0OAQAAAEEAAABwb2xs
IGZvciBjb25zZW5zdXMgb24gTWlkZGxlYm94IERpc2NvdmVyIGRyYWZ0IGFzIGEgVENQTSBXRyBp
dGVtAAAAAAIBCRABAAAAkgYAAI4GAADaCgAATFpGddedWXwDAAoAcmNwZzEyNeIyA0N0ZXgFQQED
Aff/CoACpAPkBxMCgA/zAFAEVj8IVQeyESUOUQMBAgBjaOEKwHNldDIGAAbDESX2MwRGE7cwEiwR
MwjvCfe2OxgfDjA1ESIMYGMAUPMLCQFkMzYWUAumCuMKgIBJJ2QganVzBUAAbGlrZSB0byA1BZBo
HkBzA3AeEG9mSRDAbmQYIHcnBCBwAm8LgHRzLiAgV8seEBPgdh4QYSAJwAhgYnAe8mF1dB6AFAAg
NwPwIaAgwWgEAB4wcnnVHvJ3BbBrC4BnIfQhoAEeEElFVEYgZGnxGCBjdGwi0QXAIgMkM/sdsABw
ZAsRBCAOwQnwAJD7IKAk4CwgwB9AIfAkAAOgsnceEGNhHtEeMGcUIP8kAAXAHjEl4QAgIxcCICPh
2wQAJ9kgIhAjmG0LgCZQtxQgIuMAcHQjYh4xZB5AcyPyBRBnaAVAKjEjcC73HPQc9S4TayfSIIMk
AAsR9x6kIKAiwXMhIB/AACAm4W8l0g6wB4Af8SADUh6kcPxlbwtQHuEqEh4QHeAdsHUgIUkDoG0i
0B/hBJBw+xggMgFpAiAnMC/MINAFoD8hIDOCHxAeACLQLiNzOvEuii0gVCixHhAqUSDQfm4J4B1w
AhAFwAORC4At7mInUiSABPBvMPMHgBPR+QMAc20gIQZgMPEHQDM2fSCDcwtwHXAqMic1ILFs8x6w
N4BubwfgMqM1QADQPyzQKBADIA7AM0AIgW5j/x4RE+AuAjlFMUAT0DmmC4D/HvAIcD+xBHAa0DJx
J1JCsfcj8kMnHwFvKKMzRSMmQ/N/QcIKsEDgLns5ACBRLVBu3icpYSyxMzYoEXApwyGQ+SnydW4H
QBewKBAOsB1w9zNgNZI5wHUG0ASQMoEFsT8qMi57IFc+4jZ/N4NvYv5qJLE1oTgvJAEdoB7jKjP/
SzUD8EqgNuEAgEuwHhIeQI5tQgJG80PmVENQMDLvBIEgIiISGCBnJjMeMSoznx/DJzA0wU+gFBBy
djWD+SMRdWwdcEvQQQRLNDmR+xggJzBiItABAQuAIhA1o9YiSzQHQCIgIUVG8AWQPwcxJOFD9SgQ
UYQr8GRk+zOABuB4B5AnMCsxKlEhIe1Wc29RgQEAdg3gB5EtIv9b8QEAJ4FBMVhZHhBL0B2xvyw1
WTYeMR5xXxJMJGUkkN8fsClBDeBYcArBYTFgHeD/StE1oTRkQuJAaCcwVAQT4P8EID8wBUBL0Cex
INBDIQJg/zIwJzQGkCsiS9AFoAeCAiD/RdFF0lhyIIMeMQDAHgFB8/Z0PLABAC0fAAPQR00vQP9L
0B3gPIFBVQDAItBYsR6z/nEKUB2wS2JnQR4xJ5Eoo/8goB9AIcNYY1UwSzEqJGjx/yDQJeYn0TlR
BQAwUErxICT7KBBCwW4k4VvRazA6Ewhh/RQQbCCgRNM28RQBWeFKEf9qF0DgACALcVxDJqE94R5A
/3FkIhA8QnSyRjUogDnQPLL9NRFtPjFkYCKRB4Ah0R3j/ysyJ6JwhgIQSqEH4CXnZrH/HkAvQHQR
SJEUEGBSItFwP+8dcGdyPtN89nVeMnIrVsLfA2BfcAEAc6BQXEYLgFwi/ycwL0ZBZCygOZE+4m7M
MFG/JOJn4QbgShEj8j/hdTzB/VFxZlhwOdAEEVGzK9E7xn0n0ScgoUMhH8AUEHOiST8jAR4RazJR
5G+DINBXR/8rITIwcbVB0R7BLiOKgliT/xPgMWA3sR5AKIFYoADQhUH/LTE7IR2gAJAuXyvwLeJY
sf5wIZAs0x6zIyEmUR/hHkD8Sm+KoAQgBGAhkTAxWcO/ShErMR6wSnCDMR3UeQhg/VhIby+hIhNx
cizjJAF6Fv9oJV0rOwmM2nZ0Z3I50F+R/z2wBRB0cikyI2IyoyPyHrD/CkBLU0ETL8aK+oT3QTFo
8f8+oohzJOE504+iHkCQFp1H/UExc28QWbFpxjbxWIEtU2syECcxbCGhdS3gloInf1LBleIUACXy
fvOOwzVBZv8SgWdyHjAufJWle4aHESIR7xKBPIFI4Sfhc6YhWIFoIj8BoCThC1EDoDoiHrN0ef8z
QB7yOpFAgR6wA6CQlllzv4gEOdAO0SQyICFRMk0KwP9CESQzUqOSgjVRrdBS4nCB/0CxBUA6Ih2g
J0MvSaUEaXH/K/Cowh6ns7FL0CNiNUEUEJ9I4VZyjBSwBR2wZXBsXRQtSi6KfbqQAAAeADUQAQAA
AE0AAAA8QjBEODAzRDA0QUEyRjU0QTgyMjdFMUI2MDYzNDRFRDkwMzIwNjNBMEBiY3MtbWFpbDA0
LmludGVybmFsLmNhY2hlZmxvdy5jb20+AAAAAB4AORABAAAALgAAADxtYWlsbWFuLjYxOTAuMTI2
MTUxOTM3Ny4zMjcyOS50Y3BtQGlldGYub3JnPgAAAB4ARxABAAAADwAAAG1lc3NhZ2UvcmZjODIy
AAALAPIQAQAAAB8A8xABAAAAlgAAAFIAZQAlADMAQQAgAHAAbwBsAGwAIABmAG8AcgAgAGMAbwBu
AHMAZQBuAHMAdQBzACAAbwBuACAATQBpAGQAZABsAGUAYgBvAHgAIABEAGkAcwBjAG8AdgBlAHIA
IABkAHIAYQBmAHQAIABhAHMAIABhACAAVABDAFAATQAgAFcARwAgAGkAdABlAG0ALgBFAE0ATAAA
AAAACwD2EAAAAABAAAcw911RS16DygFAAAgwnu5VUWGDygEDAN4/r28AAAMA8T8JBAAAHgD4PwEA
AAARAAAATWFoZGF2aSwgSmFtc2hpZAAAAAACAfk/AQAAAFQAAAAAAAAA3KdAyMBCEBq0uQgAKy/h
ggEAAAAAAAAAL089Q0FDSEVGTE9XL09VPUNGLUJBWS9DTj1SRUNJUElFTlRTL0NOPUpBTVNISUQu
TUFIREFWSQAeAPo/AQAAABUAAABTeXN0ZW0gQWRtaW5pc3RyYXRvcgAAAAACAfs/AQAAAB4AAAAA
AAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAALgAAAAMA/T/kBAAAAwAZQAAAAAADABpAAAAAAAMA
HUAAAAAAAwAeQAAAAAAeADBAAQAAABAAAABKQU1TSElELk1BSERBVkkAHgAxQAEAAAAQAAAASkFN
U0hJRC5NQUhEQVZJAB4AMkABAAAAFgAAAHRjcG0tYm91bmNlc0BpZXRmLm9yZwAAAB4AM0ABAAAA
FgAAAHRjcG0tcmVxdWVzdEBpZXRmLm9yZwAAAB4AOEABAAAAEAAAAEpBTVNISUQuTUFIREFWSQAe
ADlAAQAAAAIAAAAuAAAAAwB2QP////8LACkAAAAAAAsAIwAAAAAAAwAGEGWv9TADAAcQegcAAAMA
EBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABJREpVU1RMSUtFVE9FQ0hPU09NRU9GQU5EUkVXU1BP
SU5UU1dFSEFWRUFHUk9VUE9GQVVUSE9SU1dJVEhBSElTVE9SWU9GV09SS0lOR1dJVEhUSEVJRVRG
RElSRUNUTFlPUldJAAAAAAIBfwABAAAATQAAADxCMEQ4MDNEMDRBQTJGNTRBODIyN0UxQjYwNjM0
NEVEOTAzMjA2M0EwQGJjcy1tYWlsMDQuaW50ZXJuYWwuY2FjaGVmbG93LmNvbT4AAAAAmQw=

------_=_NextPart_001_01CA8361.514A02D7--

------------=_1261525759-31635-1--

From touch@ISI.EDU  Tue Dec 22 16:23: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 43A7A3A68C6 for ; Tue, 22 Dec 2009 16:23:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.465
X-Spam-Level: 
X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134,  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 GTKYuI5C1Usl for ; Tue, 22 Dec 2009 16:23:27 -0800 (PST)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id BCE903A6867 for ; Tue, 22 Dec 2009 16:23:26 -0800 (PST)
Received: from [75.215.214.226] (226.sub-75-215-214.myvzw.com [75.215.214.226]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nBN0MJ8j020929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 22 Dec 2009 16:22:22 -0800 (PST)
Message-ID: <4B3162BA.403@isi.edu>
Date: Tue, 22 Dec 2009 16:22:18 -0800
From: Joe Touch 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: "Mahdavi, Jamshid" 
References:  
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
Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG item
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 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, 23 Dec 2009 00:23:28 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Mahdavi, Jamshid wrote:
...
> I might be putting some words into Joe's mouth here, but it sounded
> like you would be ok with adopting the general problem of middlebox
> discovery as a WG item, but not necessarily starting from the solution
> that we have proposed. I think that if we actually need to go back to
> starting at square one we could do that, although you'll understand why
> we'd prefer not to.

I want to start with understanding the problem and why it has to be
solved with TCP options in devices that aren't supposed to be modifying
a TCP header (as opposed to IP options in those packets).

If this were to move forward, we'd need to understand how many current
Internet standards are updated by allowing intermediate devices to
modify TCP headers.

I don't see a huge problem if these issues are addressed using the
current solution, e.g., moving forward as suggested by Wes. However, if
these cannot be sufficiently addressed, I hope we can accept a solution
that is compatible with the architecture (whether modified or completely
different - I'm not suggesting I know which is the case, though) - not
just the one that happens to be deployed.

A key question is whether this qualifies as a minor modification of TCP,
or whether this ought to be in the TSVWG. IMO, adding an option is
minor, but changing the standards to allow middleboxes to modify options
is major.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAksxYroACgkQE5f5cImnZrsrbQCgghukQhjWuxbhIAOYaMldsLN4
A1kAoIknMDXflTxPUx2Vyeua4xsoOk0C
=TPlf
-----END PGP SIGNATURE-----

From jamshid.mahdavi@bluecoat.com  Tue Dec 22 16:44: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 D751B3A68FA for ; Tue, 22 Dec 2009 16:44:52 -0800 (PST)
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 UxgpgoPJYJW1 for ; Tue, 22 Dec 2009 16:44:52 -0800 (PST)
Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id 029573A682C for ; Tue, 22 Dec 2009 16:44:51 -0800 (PST)
Received: from bcs-mail04.internal.cacheflow.com (bcsmail04.internal.cacheflow.com [10.2.2.56] (may be forged)) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id nBN0iZe5016928; Tue, 22 Dec 2009 16:44:35 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 22 Dec 2009 16:44:30 -0800
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG item
Thread-Index: AcqDZhs+hr4JOdf2Sa65YbUWbXJrWAAAeCVO
References:   <4B3162BA.403@isi.edu>
From: "Mahdavi, Jamshid" 
To: "Joe Touch" , 
Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG item
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 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, 23 Dec 2009 00:44:52 -0000

As it happens, we don't modify options at all.  What our boxes do is =
terminate one TCP connection (essentially masquerading as the server), =
and then create a new connection to the server (with whatever new =
options we choose) and optionally masquerade as the client on that =
connection (commonly known as ip-spoofing).

Not all middleboxes work this way, of course.  NATs are an obvious =
example where connections are not terminated.  Boxes like that may (I =
believe) modify options, perhaps by removing ones they don't know about. =
 We see this sort of thing from time to time.  Even outside of what we =
are doing for discovery, we also rely on options for things like TCP =
large windows support so it is something we watch for.

So, in my view, our draft does not propose to either allow or disallow =
"modification" of TCP options.  Instead, we define a new option which =
may be used by devices that originate connections (either clients or =
proxies), or by devices which are already in the business of twiddling =
with existing connections.

--J

-----Original Message-----
From: Joe Touch [mailto:touch@isi.edu]
Sent: Tue 12/22/2009 4:22 PM
To: Mahdavi, Jamshid
Cc: tcpm@ietf.org
Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a =
TCPM WG item
=20
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Mahdavi, Jamshid wrote:
...
> I might be putting some words into Joe's mouth here, but it sounded
> like you would be ok with adopting the general problem of middlebox
> discovery as a WG item, but not necessarily starting from the solution
> that we have proposed. I think that if we actually need to go back to
> starting at square one we could do that, although you'll understand =
why
> we'd prefer not to.

I want to start with understanding the problem and why it has to be
solved with TCP options in devices that aren't supposed to be modifying
a TCP header (as opposed to IP options in those packets).

If this were to move forward, we'd need to understand how many current
Internet standards are updated by allowing intermediate devices to
modify TCP headers.

I don't see a huge problem if these issues are addressed using the
current solution, e.g., moving forward as suggested by Wes. However, if
these cannot be sufficiently addressed, I hope we can accept a solution
that is compatible with the architecture (whether modified or completely
different - I'm not suggesting I know which is the case, though) - not
just the one that happens to be deployed.

A key question is whether this qualifies as a minor modification of TCP,
or whether this ought to be in the TSVWG. IMO, adding an option is
minor, but changing the standards to allow middleboxes to modify options
is major.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAksxYroACgkQE5f5cImnZrsrbQCgghukQhjWuxbhIAOYaMldsLN4
A1kAoIknMDXflTxPUx2Vyeua4xsoOk0C
=3DTPlf
-----END PGP SIGNATURE-----



From touch@ISI.EDU  Tue Dec 22 16: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 4389B3A6818 for ; Tue, 22 Dec 2009 16:53:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.478
X-Spam-Level: 
X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121,  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 cQmoud0alLWU for ; Tue, 22 Dec 2009 16:53:08 -0800 (PST)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 60A3A3A67A1 for ; Tue, 22 Dec 2009 16:53:08 -0800 (PST)
Received: from [75.215.214.226] (226.sub-75-215-214.myvzw.com [75.215.214.226]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nBN0qXY5027960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 22 Dec 2009 16:52:36 -0800 (PST)
Message-ID: <4B3169D1.5050707@isi.edu>
Date: Tue, 22 Dec 2009 16:52:33 -0800
From: Joe Touch 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: "Mahdavi, Jamshid" 
References:   <4B3162BA.403@isi.edu> 
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
Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG item
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 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, 23 Dec 2009 00:53:09 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Mahdavi, Jamshid wrote:
> As it happens, we don't modify options at all. What our boxes do is
> terminate one TCP connection (essentially masquerading as the server),
> and then create a new connection to the server (with whatever new
> options we choose) and optionally masquerade as the client on that
> connection (commonly known as ip-spoofing).

Masquerading is not standards track. You're not only asking for an
experimental RFC, you're asking us to allow masquerading.

...
> So, in my view, our draft does not propose to either allow or 
> disallow "modification" of TCP options. Instead, we define a new
> option which may be used by devices that originate connections
> (either clients or proxies), or by devices which are already in the
> business of twiddling with existing connections.

You're defining an option that is only useful by a box that violates
existing standards - whether they already do so or not, that causes a
problem AFAICT for TCPM to take this on as a WG item.

Joe

> -----Original Message-----
> From: Joe Touch [mailto:touch@isi.edu]
> Sent: Tue 12/22/2009 4:22 PM
> To: Mahdavi, Jamshid
> Cc: tcpm@ietf.org
> Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG item
>  
> 
> 
> Mahdavi, Jamshid wrote:
> ...
>> I might be putting some words into Joe's mouth here, but it sounded
>> like you would be ok with adopting the general problem of middlebox
>> discovery as a WG item, but not necessarily starting from the solution
>> that we have proposed. I think that if we actually need to go back to
>> starting at square one we could do that, although you'll understand why
>> we'd prefer not to.
> 
> I want to start with understanding the problem and why it has to be
> solved with TCP options in devices that aren't supposed to be modifying
> a TCP header (as opposed to IP options in those packets).
> 
> If this were to move forward, we'd need to understand how many current
> Internet standards are updated by allowing intermediate devices to
> modify TCP headers.
> 
> I don't see a huge problem if these issues are addressed using the
> current solution, e.g., moving forward as suggested by Wes. However, if
> these cannot be sufficiently addressed, I hope we can accept a solution
> that is compatible with the architecture (whether modified or completely
> different - I'm not suggesting I know which is the case, though) - not
> just the one that happens to be deployed.
> 
> A key question is whether this qualifies as a minor modification of TCP,
> or whether this ought to be in the TSVWG. IMO, adding an option is
> minor, but changing the standards to allow middleboxes to modify options
> is major.
> 
> Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAksxadEACgkQE5f5cImnZrutFACcD4ZggKX7+wXmRfHDEqXp4mmu
NfkAoPD2L9FBOV6RUn4UBrDRm4hxC1di
=3xz3
-----END PGP SIGNATURE-----

From wesley.m.eddy@nasa.gov  Tue Dec 22 19:35: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 DD3FD3A6814 for ; Tue, 22 Dec 2009 19:35:18 -0800 (PST)
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 VlMXwrZRdPIi for ; Tue, 22 Dec 2009 19:35:17 -0800 (PST)
Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [198.117.0.123]) by core3.amsl.com (Postfix) with ESMTP id AAAED3A679C for ; Tue, 22 Dec 2009 19:35:17 -0800 (PST)
Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 7C4742D8063; Tue, 22 Dec 2009 21:34:59 -0600 (CST)
Received: from ndjshub02.ndc.nasa.gov (ndjshub02-pub.ndc.nasa.gov [198.117.1.161]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id nBN3Z0kZ032719;  Tue, 22 Dec 2009 21:35:00 -0600
Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub02.ndc.nasa.gov ([198.117.1.161]) with mapi; Tue, 22 Dec 2009 21:34:58 -0600
From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" 
To: Joe Touch , "Mahdavi, Jamshid" 
Date: Tue, 22 Dec 2009 21:34:58 -0600
Thread-Topic: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG item
Thread-Index: AcqDakQhkLli4AX4RPutiUR/XPlC4gAEMLK3
Message-ID: 
References:   <4B3162BA.403@isi.edu> , <4B3169D1.5050707@isi.edu>
In-Reply-To: <4B3169D1.5050707@isi.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-12-22_09:2009-12-12, 2009-12-22, 2009-12-22 signatures=0
Cc: "tcpm@ietf.org" 
Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG item
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 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, 23 Dec 2009 03:35:19 -0000

There are already several RFCs that discuss the dangers of various middlebo=
x behaviors like splitting TCP connections and pretending to be other hosts=
, and discourage those behaviors.  We don't really have the ability to deci=
de whether to "allow" these behaviors or not; they're already widespread de=
spite our expressed concerns and the lack of any formal standards encouragi=
ng them.  The situation goes from bad to worse when they start poaching opt=
ions numbers and other assigned values though, without even leaving a paper=
 trail for the community to be aware of what's going on.  IANA's tables bec=
ome meaningless if big parts of the community stop paying attention to them=
 and deploy new values without regard to the maintenance (or authority) of =
the registries.

Though we can't make some of the naughty things middleboxes do go away, I'd=
 think we could at least define this option for them as a sandbox to play w=
ithin rather than continue to watch them pollute the whole space of options=
 numbers with landmines that will only be painfully discovered in the futur=
e.  We'd clearly have the ability to say something like: "Please see refere=
nces XXX and YYY as to why certain types of middleboxes are short-sighted o=
ptimization attempts and harmful to the Internet.  If you choose to ignore =
that advice and do these things anyways and also decide to use TCP options =
for some portion of your functionality, as many in-the-wild devices are pre=
sently, then please at least do not poach unallocated TCP option numbers wh=
ich are supposed to be under IANA's control.  Please use option number Z an=
d the accompanying option format defined in this document, which includes a=
 user-specified portion flexible to your needs."

I'd think that's along the lines of what's being proposed.  It's about (1) =
raising awareness that poaching assigned values is yet another harmful beha=
vior of middleboxes to be avoided (I'd never heard of it, at least ... igno=
rance was bliss), and (2) showing the vendors that there's a very easy way =
they can avoid the problem.



________________________________________
From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of Joe Touch =
[touch@ISI.EDU]
Sent: Tuesday, December 22, 2009 7:52 PM
To: Mahdavi, Jamshid
Cc: tcpm@ietf.org
Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a TCP=
M WG item

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Mahdavi, Jamshid wrote:
> As it happens, we don't modify options at all. What our boxes do is
> terminate one TCP connection (essentially masquerading as the server),
> and then create a new connection to the server (with whatever new
> options we choose) and optionally masquerade as the client on that
> connection (commonly known as ip-spoofing).

Masquerading is not standards track. You're not only asking for an
experimental RFC, you're asking us to allow masquerading.

...
> So, in my view, our draft does not propose to either allow or
> disallow "modification" of TCP options. Instead, we define a new
> option which may be used by devices that originate connections
> (either clients or proxies), or by devices which are already in the
> business of twiddling with existing connections.

You're defining an option that is only useful by a box that violates
existing standards - whether they already do so or not, that causes a
problem AFAICT for TCPM to take this on as a WG item.

Joe

> -----Original Message-----
> From: Joe Touch [mailto:touch@isi.edu]
> Sent: Tue 12/22/2009 4:22 PM
> To: Mahdavi, Jamshid
> Cc: tcpm@ietf.org
> Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a T=
CPM WG item
>
>
>
> Mahdavi, Jamshid wrote:
> ...
>> I might be putting some words into Joe's mouth here, but it sounded
>> like you would be ok with adopting the general problem of middlebox
>> discovery as a WG item, but not necessarily starting from the solution
>> that we have proposed. I think that if we actually need to go back to
>> starting at square one we could do that, although you'll understand why
>> we'd prefer not to.
>
> I want to start with understanding the problem and why it has to be
> solved with TCP options in devices that aren't supposed to be modifying
> a TCP header (as opposed to IP options in those packets).
>
> If this were to move forward, we'd need to understand how many current
> Internet standards are updated by allowing intermediate devices to
> modify TCP headers.
>
> I don't see a huge problem if these issues are addressed using the
> current solution, e.g., moving forward as suggested by Wes. However, if
> these cannot be sufficiently addressed, I hope we can accept a solution
> that is compatible with the architecture (whether modified or completely
> different - I'm not suggesting I know which is the case, though) - not
> just the one that happens to be deployed.
>
> A key question is whether this qualifies as a minor modification of TCP,
> or whether this ought to be in the TSVWG. IMO, adding an option is
> minor, but changing the standards to allow middleboxes to modify options
> is major.
>
> Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAksxadEACgkQE5f5cImnZrutFACcD4ZggKX7+wXmRfHDEqXp4mmu
NfkAoPD2L9FBOV6RUn4UBrDRm4hxC1di
=3D3xz3
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm=

From touch@ISI.EDU  Tue Dec 22 22:56: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 25C9F3A6909 for ; Tue, 22 Dec 2009 22:56:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=-0.003, 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 Fm73eYsqsinJ for ; Tue, 22 Dec 2009 22:56:38 -0800 (PST)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 1C72A3A68F5 for ; Tue, 22 Dec 2009 22:56:38 -0800 (PST)
Received: from [192.168.1.43] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nBN6u36f006988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 22 Dec 2009 22:56:05 -0800 (PST)
Message-ID: <4B31BF03.2060906@isi.edu>
Date: Tue, 22 Dec 2009 22:56:03 -0800
From: Joe Touch 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" 
References: 		<4B3162BA.403@isi.edu>	, <4B3169D1.5050707@isi.edu> 
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: "Mahdavi, Jamshid" , "tcpm@ietf.org" 
Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG item
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 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, 23 Dec 2009 06:56:39 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, Wes,

You make a convincing argument.

Since they already aren't following the standards, I see no reason to
limit them to the existing 0-255 range. I propose option #256 for these
mechanisms.

Joe

Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote:
> There are already several RFCs that discuss the dangers of various middlebox behaviors like splitting TCP connections and pretending to be other hosts, and discourage those behaviors.  We don't really have the ability to decide whether to "allow" these behaviors or not; they're already widespread despite our expressed concerns and the lack of any formal standards encouraging them.  The situation goes from bad to worse when they start poaching options numbers and other assigned values though, without even leaving a paper trail for the community to be aware of what's going on.  IANA's tables become meaningless if big parts of the community stop paying attention to them and deploy new values without regard to the maintenance (or authority) of the registries.
> 
> Though we can't make some of the naughty things middleboxes do go away, I'd think we could at least define this option for them as a sandbox to play within rather than continue to watch them pollute the whole space of options numbers with landmines that will only be painfully discovered in the future.  We'd clearly have the ability to say something like: "Please see references XXX and YYY as to why certain types of middleboxes are short-sighted optimization attempts and harmful to the Internet.  If you choose to ignore that advice and do these things anyways and also decide to use TCP options for some portion of your functionality, as many in-the-wild devices are presently, then please at least do not poach unallocated TCP option numbers which are supposed to be under IANA's control.  Please use option number Z and the accompanying option format defined in this document, which includes a user-specified portion flexible to your needs."
> 
> I'd think that's along the lines of what's being proposed.  It's about (1) raising awareness that poaching assigned values is yet another harmful behavior of middleboxes to be avoided (I'd never heard of it, at least ... ignorance was bliss), and (2) showing the vendors that there's a very easy way they can avoid the problem.
> 
> 
> 
> ________________________________________
> From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of Joe Touch [touch@ISI.EDU]
> Sent: Tuesday, December 22, 2009 7:52 PM
> To: Mahdavi, Jamshid
> Cc: tcpm@ietf.org
> Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG item
> 
> 
> 
> Mahdavi, Jamshid wrote:
>> As it happens, we don't modify options at all. What our boxes do is
>> terminate one TCP connection (essentially masquerading as the server),
>> and then create a new connection to the server (with whatever new
>> options we choose) and optionally masquerade as the client on that
>> connection (commonly known as ip-spoofing).
> 
> Masquerading is not standards track. You're not only asking for an
> experimental RFC, you're asking us to allow masquerading.
> 
> ...
>> So, in my view, our draft does not propose to either allow or
>> disallow "modification" of TCP options. Instead, we define a new
>> option which may be used by devices that originate connections
>> (either clients or proxies), or by devices which are already in the
>> business of twiddling with existing connections.
> 
> You're defining an option that is only useful by a box that violates
> existing standards - whether they already do so or not, that causes a
> problem AFAICT for TCPM to take this on as a WG item.
> 
> Joe
> 
>> -----Original Message-----
>> From: Joe Touch [mailto:touch@isi.edu]
>> Sent: Tue 12/22/2009 4:22 PM
>> To: Mahdavi, Jamshid
>> Cc: tcpm@ietf.org
>> Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG item
> 
> 
> 
>> Mahdavi, Jamshid wrote:
>> ...
>>> I might be putting some words into Joe's mouth here, but it sounded
>>> like you would be ok with adopting the general problem of middlebox
>>> discovery as a WG item, but not necessarily starting from the solution
>>> that we have proposed. I think that if we actually need to go back to
>>> starting at square one we could do that, although you'll understand why
>>> we'd prefer not to.
>> I want to start with understanding the problem and why it has to be
>> solved with TCP options in devices that aren't supposed to be modifying
>> a TCP header (as opposed to IP options in those packets).
> 
>> If this were to move forward, we'd need to understand how many current
>> Internet standards are updated by allowing intermediate devices to
>> modify TCP headers.
> 
>> I don't see a huge problem if these issues are addressed using the
>> current solution, e.g., moving forward as suggested by Wes. However, if
>> these cannot be sufficiently addressed, I hope we can accept a solution
>> that is compatible with the architecture (whether modified or completely
>> different - I'm not suggesting I know which is the case, though) - not
>> just the one that happens to be deployed.
> 
>> A key question is whether this qualifies as a minor modification of TCP,
>> or whether this ought to be in the TSVWG. IMO, adding an option is
>> minor, but changing the standards to allow middleboxes to modify options
>> is major.
> 
>> Joe
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAksxvwMACgkQE5f5cImnZruNHgCfQZKkulmbjS/7F+8lCuH11uJd
wS0AnR3sZoRfI8an1cWPMS4jyOBYq8yy
=g/g2
-----END PGP SIGNATURE-----

From lars.eggert@nokia.com  Wed Dec 23 03:13: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 A862D3A69D5 for ; Wed, 23 Dec 2009 03:13:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.522
X-Spam-Level: 
X-Spam-Status: No, score=-3.522 tagged_above=-999 required=5 tests=[AWL=0.077,  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 TY3K3LPN+T65 for ; Wed, 23 Dec 2009 03:13:33 -0800 (PST)
Received: from smtp.tele.fi (smtp.tele.fi [192.89.123.25]) by core3.amsl.com (Postfix) with ESMTP id 72A223A6A7A for ; Wed, 23 Dec 2009 03:13:33 -0800 (PST)
X-Originating-Ip: [212.213.221.241]
Received: from host-241.nrln.net (host-241.nrln.net [212.213.221.241]) by smtp.tele.fi (Postfix) with ESMTP id B3D0E199C; Wed, 23 Dec 2009 13:13:10 +0200 (EET)
Received: from mail.fit.nokia.com ([212.213.221.40]) by host-241.nrln.net (Lotus Domino Release 6.5) with ESMTP id 2009122313191361-358 ; Wed, 23 Dec 2009 13:19:13 +0200 
Received: from [IPv6:2001:14b8:18f::225:ff:fe45:eccf] ([IPv6:2001:14b8:18f:0:225:ff:fe45:eccf]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id nBNBD1PX069185 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 23 Dec 2009 13:13:03 +0200 (EET) (envelope-from lars.eggert@nokia.com)
Mime-Version: 1.0 (Apple Message framework v1077)
From: Lars Eggert 
In-Reply-To: 
Date: Wed, 23 Dec 2009 13:12:56 +0200
Message-Id: 
References:   <4B3162BA.403@isi.edu> , <4B3169D1.5050707@isi.edu> 
To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" 
X-Mailer: Apple Mail (2.1077)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [IPv6:2001:708:40:fff1::1]); Wed, 23 Dec 2009 13:13:04 +0200 (EET)
X-MIMETrack: Itemize by SMTP Server on host-241/srv/nrln(Release 6.5|September 26, 2003) at 12/23/2009 01:19:13 PM, Serialize by Router on host-241/srv/nrln(Release 6.5|September 26, 2003) at 12/23/2009 01:19:19 PM, Serialize complete at 12/23/2009 01:19:19 PM
Content-Type: multipart/signed; boundary=Apple-Mail-11--208264989; protocol="application/pkcs7-signature"; micalg=sha1
Cc: "Mahdavi, Jamshid" , "tcpm@ietf.org" , Joe Touch 
Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG item
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 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, 23 Dec 2009 11:13:34 -0000

--Apple-Mail-11--208264989
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi,

On 2009-12-23, at 5:34, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] =
wrote:
> Though we can't make some of the naughty things middleboxes do go =
away, I'd think we could at least define this option for them as a =
sandbox to play within rather than continue to watch them pollute the =
whole space of options numbers with landmines that will only be =
painfully discovered in the future.  We'd clearly have the ability to =
say something like: "Please see references XXX and YYY as to why certain =
types of middleboxes are short-sighted optimization attempts and harmful =
to the Internet.  If you choose to ignore that advice and do these =
things anyways and also decide to use TCP options for some portion of =
your functionality, as many in-the-wild devices are presently, then =
please at least do not poach unallocated TCP option numbers which are =
supposed to be under IANA's control.  Please use option number Z and the =
accompanying option format defined in this document, which includes a =
user-specified portion flexible to your needs."


speaking as an individual, this to me sounds like a reasonable document =
for the WG to produce.

Lars=

--Apple-Mail-11--208264989
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw
ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx
NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy
dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X
uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY
Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB
6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT
VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr
ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu
ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt
I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H
5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80
QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT
BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg
Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG
A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL
MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV
BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK
MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7
n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw
QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl
ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl
TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M
Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg
T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw
YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq
BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP
6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF
MQ8XDTA5MTIyMzExMTI1NlowIwYJKoZIhvcNAQkEMRYEFGdPODT9oakT3PxCUVuSR3ZmFeNXMIGF
BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu
ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD
QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw
IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy
c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF
AASCAQByGdSXrHZgB60TOidp7hTljbsaeUbau6lzP07k+bc3w/eiFlV42Rk3itQ7IJUmClylZbQR
/YIzSJQU5rOHuMnEKscGgAU3HtMAQSuqbb67jRo6jvhRiXx+k2zCxuirt4OHEMpSDMRpXl4u1AC0
jsC9MiI9jUosF2CZ3u19vpdfatJ5/cvI72iTtvUzv27XWm9OM2OS759IPPDquxPrBHfGw1DZE9rl
lKhDoJWUlJWw2nj9oqWLPsi/EvT8QxlGBbRW8nKSsES3TWcqnmkcIbpyr5x93WCExsB9+kcevNhI
UOhMWYWWD45I+ITHHp31wiZCBKiJc6Hww5ExH9D2KWiQAAAAAAAA

--Apple-Mail-11--208264989--

From wesley.m.eddy@nasa.gov  Wed Dec 23 12:58: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 D836B3A68B4 for ; Wed, 23 Dec 2009 12:58:00 -0800 (PST)
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 X6ohY1U3Mbce for ; Wed, 23 Dec 2009 12:57:59 -0800 (PST)
Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [198.117.0.123]) by core3.amsl.com (Postfix) with ESMTP id 6A9A13A67D9 for ; Wed, 23 Dec 2009 12:57:58 -0800 (PST)
Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 289852D89FB; Wed, 23 Dec 2009 14:57:40 -0600 (CST)
Received: from ndjshub02.ndc.nasa.gov (ndjshub02-pub.ndc.nasa.gov [198.117.1.161]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id nBNKveoF023130;  Wed, 23 Dec 2009 14:57:40 -0600
Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub02.ndc.nasa.gov ([198.117.1.161]) with mapi; Wed, 23 Dec 2009 14:57:39 -0600
From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" 
To: Andrew Knutsen 
Date: Wed, 23 Dec 2009 14:57:39 -0600
Thread-Topic: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG item
Thread-Index: AcqEDHUado3fZ0hvSzed5PPiJgbjGwABNj/A
Message-ID: 
References:   <4B3162BA.403@isi.edu> , <4B3169D1.5050707@isi.edu>  <4B3279FC.6060504@bluecoat.com>
In-Reply-To: <4B3279FC.6060504@bluecoat.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-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-12-23_07:2009-12-12, 2009-12-23, 2009-12-23 signatures=0
Cc: "Mahdavi, Jamshid" , "tcpm@ietf.org" , Joe Touch 
Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG item
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 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, 23 Dec 2009 20:58:00 -0000

I wasn't suggesting that you put it into your document, I was just
mentioning that I think that some similar context-setting makes
sense to add if there's a working group product on the topic,
because as Joe pointed out, there's otherwise potential for some
confusion.  There are probably much better ways to phrase the actual
words :).

There are two things going on that I was seeing as distinct (though
related):

(1) Typical middlebox behaviors (connection-splitting, etc.)
(2) TCP option number poaching

I think we would be making a statement about (2), and leaving
advise on (1) to the several existing statements?

--
Wes Eddy
MTI Systems


>-----Original Message-----
>From: Andrew Knutsen [mailto:andrew.knutsen@bluecoat.com]
>Sent: Wednesday, December 23, 2009 3:14 PM
>To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
>Cc: Joe Touch; Mahdavi, Jamshid; tcpm@ietf.org
>Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a
>TCPM WG item
>
>
>    Are you suggesting we add the text you mention to the draft?  I
>think we could come up with some similar (if less biased ;-) text.
>However we need the values of XXX and YYY, preferably with chapter and
>verse, if its going to be relevant.
>
>    Please don't get us wrong; Blue Coat does believe in
>interoperability (at the appropriate point), and we do have a long-term
>goal of helping bring standards to today's Internet. But we do have to
>start where we're at...
>
>Andrew
>
>Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote:
>
>	There are already several RFCs that discuss the dangers of various
>middlebox behaviors like splitting TCP connections and pretending to be
>other hosts, and discourage those behaviors.  We don't really have the
>ability to decide whether to "allow" these behaviors or not; they're
>already widespread despite our expressed concerns and the lack of any
>formal standards encouraging them.  The situation goes from bad to worse
>when they start poaching options numbers and other assigned values
>though, without even leaving a paper trail for the community to be aware
>of what's going on.  IANA's tables become meaningless if big parts of
>the community stop paying attention to them and deploy new values
>without regard to the maintenance (or authority) of the registries.
>
>	Though we can't make some of the naughty things middleboxes do go
>away, I'd think we could at least define this option for them as a
>sandbox to play within rather than continue to watch them pollute the
>whole space of options numbers with landmines that will only be
>painfully discovered in the future.  We'd clearly have the ability to
>say something like: "Please see references XXX and YYY as to why certain
>types of middleboxes are short-sighted optimization attempts and harmful
>to the Internet.  If you choose to ignore that advice and do these
>things anyways and also decide to use TCP options for some portion of
>your functionality, as many in-the-wild devices are presently, then
>please at least do not poach unallocated TCP option numbers which are
>supposed to be under IANA's control.  Please use option number Z and the
>accompanying option format defined in this document, which includes a
>user-specified portion flexible to your needs."
>
>	I'd think that's along the lines of what's being proposed.  It's
>about (1) raising awareness that poaching assigned values is yet another
>harmful behavior of middleboxes to be avoided (I'd never heard of it, at
>least ... ignorance was bliss), and (2) showing the vendors that there's
>a very easy way they can avoid the problem.
>
>
>
>	________________________________________
>	From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of
>Joe Touch [touch@ISI.EDU]
>	Sent: Tuesday, December 22, 2009 7:52 PM
>	To: Mahdavi, Jamshid
>	Cc: tcpm@ietf.org
>	Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft
>as a TCPM WG item
>
>	-----BEGIN PGP SIGNED MESSAGE-----
>	Hash: SHA1
>
>
>
>	Mahdavi, Jamshid wrote:
>
>
>		As it happens, we don't modify options at all. What our
>boxes do is
>		terminate one TCP connection (essentially masquerading as
>the server),
>		and then create a new connection to the server (with
>whatever new
>		options we choose) and optionally masquerade as the client
>on that
>		connection (commonly known as ip-spoofing).
>
>
>
>	Masquerading is not standards track. You're not only asking for an
>	experimental RFC, you're asking us to allow masquerading.
>
>	...
>
>
>		So, in my view, our draft does not propose to either allow
>or
>		disallow "modification" of TCP options. Instead, we define a
>new
>		option which may be used by devices that originate
>connections
>		(either clients or proxies), or by devices which are already
>in the
>		business of twiddling with existing connections.
>
>
>
>	You're defining an option that is only useful by a box that
>violates
>	existing standards - whether they already do so or not, that
>causes a
>	problem AFAICT for TCPM to take this on as a WG item.
>
>	Joe
>
>
>
>		-----Original Message-----
>		From: Joe Touch [mailto:touch@isi.edu]
>		Sent: Tue 12/22/2009 4:22 PM
>		To: Mahdavi, Jamshid
>		Cc: tcpm@ietf.org
>		Subject: Re: [tcpm] poll for consensus on Middlebox Discover
>draft as a TCPM WG item
>
>
>
>		Mahdavi, Jamshid wrote:
>		...
>
>
>			I might be putting some words into Joe's mouth here,
>but it sounded
>			like you would be ok with adopting the general problem
>of middlebox
>			discovery as a WG item, but not necessarily starting
>from the solution
>			that we have proposed. I think that if we actually
>need to go back to
>			starting at square one we could do that, although
>you'll understand why
>			we'd prefer not to.
>
>
>		I want to start with understanding the problem and why it
>has to be
>		solved with TCP options in devices that aren't supposed to
>be modifying
>		a TCP header (as opposed to IP options in those packets).
>
>		If this were to move forward, we'd need to understand how
>many current
>		Internet standards are updated by allowing intermediate
>devices to
>		modify TCP headers.
>
>		I don't see a huge problem if these issues are addressed
>using the
>		current solution, e.g., moving forward as suggested by Wes.
>However, if
>		these cannot be sufficiently addressed, I hope we can accept
>a solution
>		that is compatible with the architecture (whether modified
>or completely
>		different - I'm not suggesting I know which is the case,
>though) - not
>		just the one that happens to be deployed.
>
>		A key question is whether this qualifies as a minor
>modification of TCP,
>		or whether this ought to be in the TSVWG. IMO, adding an
>option is
>		minor, but changing the standards to allow middleboxes to
>modify options
>		is major.
>
>		Joe
>
>
>	-----BEGIN PGP SIGNATURE-----
>	Version: GnuPG v1.4.9 (MingW32)
>
>	iEYEARECAAYFAksxadEACgkQE5f5cImnZrutFACcD4ZggKX7+wXmRfHDEqXp4mmu
>	NfkAoPD2L9FBOV6RUn4UBrDRm4hxC1di
>	=3D3xz3
>	-----END PGP SIGNATURE-----
>	_______________________________________________
>	tcpm mailing list
>	tcpm@ietf.org
>	https://www.ietf.org/mailman/listinfo/tcpm
>	_______________________________________________
>	tcpm mailing list
>	tcpm@ietf.org
>	https://www.ietf.org/mailman/listinfo/tcpm
>
>


From wesley.m.eddy@nasa.gov  Wed Dec 23 13:06: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 DE1643A6A1C for ; Wed, 23 Dec 2009 13:06:39 -0800 (PST)
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 8glnPnKexXSG for ; Wed, 23 Dec 2009 13:06:38 -0800 (PST)
Received: from ndmsnpf01.ndc.nasa.gov (ndmsnpf01.ndc.nasa.gov [198.117.0.121]) by core3.amsl.com (Postfix) with ESMTP id 20FAB3A692D for ; Wed, 23 Dec 2009 13:06:38 -0800 (PST)
Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndmsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 31BD5260ED9; Wed, 23 Dec 2009 15:04:58 -0600 (CST)
Received: from ndjshub01.ndc.nasa.gov (ndjshub01-pub.ndc.nasa.gov [198.117.1.160]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id nBNL4wLK029815;  Wed, 23 Dec 2009 15:04:59 -0600
Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub01.ndc.nasa.gov ([198.117.1.160]) with mapi; Wed, 23 Dec 2009 15:04:58 -0600
From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" 
To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" , Andrew Knutsen 
Date: Wed, 23 Dec 2009 15:04:56 -0600
Thread-Topic: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG item
Thread-Index: AcqEDHUado3fZ0hvSzed5PPiJgbjGwABNj/AAAB2C7A=
Message-ID: 
References:   <4B3162BA.403@isi.edu> , <4B3169D1.5050707@isi.edu>  <4B3279FC.6060504@bluecoat.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-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-12-23_07:2009-12-12, 2009-12-23, 2009-12-23 signatures=0
Cc: "Mahdavi, Jamshid" , "tcpm@ietf.org" , Joe Touch 
Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG item
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 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, 23 Dec 2009 21:06:40 -0000

Just to clarify, by "existing statements", I mean documents like
RFC 3234 and 3135:
http://www.rfc-editor.org/rfc/rfc3234.txt
http://www.rfc-editor.org/rfc/rfc3135.txt
which already have positions on the middlebox behaviors.  They
don't say anything about sneaking options away from IANA though.

--
Wes Eddy
MTI Systems


>-----Original Message-----
>From: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
>Sent: Wednesday, December 23, 2009 3:58 PM
>To: 'Andrew Knutsen'
>Cc: Joe Touch; Mahdavi, Jamshid; tcpm@ietf.org
>Subject: RE: [tcpm] poll for consensus on Middlebox Discover draft as a
>TCPM WG item
>
>I wasn't suggesting that you put it into your document, I was just
>mentioning that I think that some similar context-setting makes
>sense to add if there's a working group product on the topic,
>because as Joe pointed out, there's otherwise potential for some
>confusion.  There are probably much better ways to phrase the actual
>words :).
>
>There are two things going on that I was seeing as distinct (though
>related):
>
>(1) Typical middlebox behaviors (connection-splitting, etc.)
>(2) TCP option number poaching
>
>I think we would be making a statement about (2), and leaving
>advise on (1) to the several existing statements?
>
>--
>Wes Eddy
>MTI Systems
>
>
>>-----Original Message-----
>>From: Andrew Knutsen [mailto:andrew.knutsen@bluecoat.com]
>>Sent: Wednesday, December 23, 2009 3:14 PM
>>To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
>>Cc: Joe Touch; Mahdavi, Jamshid; tcpm@ietf.org
>>Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a
>>TCPM WG item
>>
>>
>>    Are you suggesting we add the text you mention to the draft?  I
>>think we could come up with some similar (if less biased ;-) text.
>>However we need the values of XXX and YYY, preferably with chapter and
>>verse, if its going to be relevant.
>>
>>    Please don't get us wrong; Blue Coat does believe in
>>interoperability (at the appropriate point), and we do have a long-term
>>goal of helping bring standards to today's Internet. But we do have to
>>start where we're at...
>>
>>Andrew
>>
>>Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote:
>>
>>	There are already several RFCs that discuss the dangers of various
>>middlebox behaviors like splitting TCP connections and pretending to be
>>other hosts, and discourage those behaviors.  We don't really have the
>>ability to decide whether to "allow" these behaviors or not; they're
>>already widespread despite our expressed concerns and the lack of any
>>formal standards encouraging them.  The situation goes from bad to
>worse
>>when they start poaching options numbers and other assigned values
>>though, without even leaving a paper trail for the community to be
>aware
>>of what's going on.  IANA's tables become meaningless if big parts of
>>the community stop paying attention to them and deploy new values
>>without regard to the maintenance (or authority) of the registries.
>>
>>	Though we can't make some of the naughty things middleboxes do go
>>away, I'd think we could at least define this option for them as a
>>sandbox to play within rather than continue to watch them pollute the
>>whole space of options numbers with landmines that will only be
>>painfully discovered in the future.  We'd clearly have the ability to
>>say something like: "Please see references XXX and YYY as to why
>certain
>>types of middleboxes are short-sighted optimization attempts and
>harmful
>>to the Internet.  If you choose to ignore that advice and do these
>>things anyways and also decide to use TCP options for some portion of
>>your functionality, as many in-the-wild devices are presently, then
>>please at least do not poach unallocated TCP option numbers which are
>>supposed to be under IANA's control.  Please use option number Z and
>the
>>accompanying option format defined in this document, which includes a
>>user-specified portion flexible to your needs."
>>
>>	I'd think that's along the lines of what's being proposed.  It's
>>about (1) raising awareness that poaching assigned values is yet
>another
>>harmful behavior of middleboxes to be avoided (I'd never heard of it,
>at
>>least ... ignorance was bliss), and (2) showing the vendors that
>there's
>>a very easy way they can avoid the problem.
>>
>>
>>
>>	________________________________________
>>	From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of
>>Joe Touch [touch@ISI.EDU]
>>	Sent: Tuesday, December 22, 2009 7:52 PM
>>	To: Mahdavi, Jamshid
>>	Cc: tcpm@ietf.org
>>	Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft
>>as a TCPM WG item
>>
>>	-----BEGIN PGP SIGNED MESSAGE-----
>>	Hash: SHA1
>>
>>
>>
>>	Mahdavi, Jamshid wrote:
>>
>>
>>		As it happens, we don't modify options at all. What our
>>boxes do is
>>		terminate one TCP connection (essentially masquerading as
>>the server),
>>		and then create a new connection to the server (with
>>whatever new
>>		options we choose) and optionally masquerade as the client
>>on that
>>		connection (commonly known as ip-spoofing).
>>
>>
>>
>>	Masquerading is not standards track. You're not only asking for an
>>	experimental RFC, you're asking us to allow masquerading.
>>
>>	...
>>
>>
>>		So, in my view, our draft does not propose to either allow
>>or
>>		disallow "modification" of TCP options. Instead, we define a
>>new
>>		option which may be used by devices that originate
>>connections
>>		(either clients or proxies), or by devices which are already
>>in the
>>		business of twiddling with existing connections.
>>
>>
>>
>>	You're defining an option that is only useful by a box that
>>violates
>>	existing standards - whether they already do so or not, that
>>causes a
>>	problem AFAICT for TCPM to take this on as a WG item.
>>
>>	Joe
>>
>>
>>
>>		-----Original Message-----
>>		From: Joe Touch [mailto:touch@isi.edu]
>>		Sent: Tue 12/22/2009 4:22 PM
>>		To: Mahdavi, Jamshid
>>		Cc: tcpm@ietf.org
>>		Subject: Re: [tcpm] poll for consensus on Middlebox Discover
>>draft as a TCPM WG item
>>
>>
>>
>>		Mahdavi, Jamshid wrote:
>>		...
>>
>>
>>			I might be putting some words into Joe's mouth here,
>>but it sounded
>>			like you would be ok with adopting the general problem
>>of middlebox
>>			discovery as a WG item, but not necessarily starting
>>from the solution
>>			that we have proposed. I think that if we actually
>>need to go back to
>>			starting at square one we could do that, although
>>you'll understand why
>>			we'd prefer not to.
>>
>>
>>		I want to start with understanding the problem and why it
>>has to be
>>		solved with TCP options in devices that aren't supposed to
>>be modifying
>>		a TCP header (as opposed to IP options in those packets).
>>
>>		If this were to move forward, we'd need to understand how
>>many current
>>		Internet standards are updated by allowing intermediate
>>devices to
>>		modify TCP headers.
>>
>>		I don't see a huge problem if these issues are addressed
>>using the
>>		current solution, e.g., moving forward as suggested by Wes.
>>However, if
>>		these cannot be sufficiently addressed, I hope we can accept
>>a solution
>>		that is compatible with the architecture (whether modified
>>or completely
>>		different - I'm not suggesting I know which is the case,
>>though) - not
>>		just the one that happens to be deployed.
>>
>>		A key question is whether this qualifies as a minor
>>modification of TCP,
>>		or whether this ought to be in the TSVWG. IMO, adding an
>>option is
>>		minor, but changing the standards to allow middleboxes to
>>modify options
>>		is major.
>>
>>		Joe
>>
>>
>>	-----BEGIN PGP SIGNATURE-----
>>	Version: GnuPG v1.4.9 (MingW32)
>>
>>	iEYEARECAAYFAksxadEACgkQE5f5cImnZrutFACcD4ZggKX7+wXmRfHDEqXp4mmu
>>	NfkAoPD2L9FBOV6RUn4UBrDRm4hxC1di
>>	=3D3xz3
>>	-----END PGP SIGNATURE-----
>>	_______________________________________________
>>	tcpm mailing list
>>	tcpm@ietf.org
>>	https://www.ietf.org/mailman/listinfo/tcpm
>>	_______________________________________________
>>	tcpm mailing list
>>	tcpm@ietf.org
>>	https://www.ietf.org/mailman/listinfo/tcpm
>>
>>


From wesley.m.eddy@nasa.gov  Wed Dec 23 13:32: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 8820C3A6A17 for ; Wed, 23 Dec 2009 13:32:30 -0800 (PST)
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 avFVEIZM83ay for ; Wed, 23 Dec 2009 13:32:29 -0800 (PST)
Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [198.117.1.122]) by core3.amsl.com (Postfix) with ESMTP id 7E8B43A69DB for ; Wed, 23 Dec 2009 13:32:29 -0800 (PST)
Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id C752CA8B98; Wed, 23 Dec 2009 15:32:10 -0600 (CST)
Received: from ndjshub01.ndc.nasa.gov (ndjshub01-pub.ndc.nasa.gov [198.117.1.160]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id nBNLW21j020935;  Wed, 23 Dec 2009 15:32:10 -0600
Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub01.ndc.nasa.gov ([198.117.1.160]) with mapi; Wed, 23 Dec 2009 15:32:01 -0600
From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" 
To: Joe Touch 
Date: Wed, 23 Dec 2009 15:31:59 -0600
Thread-Topic: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG item
Thread-Index: AcqEFHW/6bCM0TtyT3+6NlOO0/rjpgAAKjeQ
Message-ID: 
References:   <4B3162BA.403@isi.edu> , <4B3169D1.5050707@isi.edu>  <4B3279FC.6060504@bluecoat.com>  <4B328721.1080203@isi.edu>
In-Reply-To: <4B328721.1080203@isi.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-12-23_10:2009-12-12, 2009-12-23, 2009-12-23 signatures=0
Cc: "Mahdavi, Jamshid" , "tcpm@ietf.org" 
Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG item
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 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, 23 Dec 2009 21:32:30 -0000

>-----Original Message-----
>From: Joe Touch [mailto:touch@ISI.EDU]
>Sent: Wednesday, December 23, 2009 4:10 PM
>
>Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote:
>> Just to clarify, by "existing statements", I mean documents like
>> RFC 3234 and 3135:
>> http://www.rfc-editor.org/rfc/rfc3234.txt
>> http://www.rfc-editor.org/rfc/rfc3135.txt
>> which already have positions on the middlebox behaviors.  They
>> don't say anything about sneaking options away from IANA though.
>
>Nobody "sneaks" things from IANA, AFAICT.


There's an existence proof that several companies have been for years.


>They use numbers that have not been assigned by IANA. IANA lists cases
>it is aware of as "inappropriate use". That should be taken by the
>public as a signal of whose products to avoid, IMO.


Yet IANA has no inherent means to detect inappropriate use, and
no IT department checks IANA's registries as part of their process
of selecting products and vendors.  This is a completely after-
the-fact way to document numbers inappropriately used, but it's
neither a deterrent or a path to friendlier behavior.

If nobody has done so already, I'll at least report the numbers
we've been told are in-use in the wild to IANA so they don't get
allocated into a collision at some future time.  The real problem
remains though, in that next year's product line(s) may use
different numbers, and playing keep-up won't be possible.

--
Wes Eddy
MTI Systems

From wesley.m.eddy@nasa.gov  Wed Dec 23 14:07: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 760133A68DC for ; Wed, 23 Dec 2009 14:07:04 -0800 (PST)
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 EfbAkebDpC7n for ; Wed, 23 Dec 2009 14:07:03 -0800 (PST)
Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by core3.amsl.com (Postfix) with ESMTP id 506763A677D for ; Wed, 23 Dec 2009 14:07:03 -0800 (PST)
Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 07D7F148246; Wed, 23 Dec 2009 16:06:45 -0600 (CST)
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 nBNM6joV010619; Wed, 23 Dec 2009 16:06:45 -0600
Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub06.ndc.nasa.gov ([198.117.4.165]) with mapi; Wed, 23 Dec 2009 16:06:44 -0600
From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" 
To: "iana@iana.org" 
Date: Wed, 23 Dec 2009 16:06:43 -0600
Thread-Topic: unallocated TCP options in-use
Thread-Index: AcqEHDY6ps/xMM1WSxyq638sRbW28g==
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.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-12-23_10:2009-12-12, 2009-12-23, 2009-12-23 signatures=0
Cc: "tcpm@ietf.org" 
Subject: [tcpm] unallocated TCP options in-use
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 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, 23 Dec 2009 22:07:04 -0000

In the IETF's TCPM working group, there's been a revelation that several
TCP Options Numbers, not listed as allocated in IANA's registry, are in
use on the Internet.

I think IANA is in the best position to decide how to deal with this, but
it's been proposed that they be added to your registry for TCP options:
http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml

The values to add are:
0x21 - Cisco middlebox discovery
0x4C - Riverbed middlebox discovery
0x4E - Riverbed middlebox discovery

One suggestion was to label these as "inappropriate use" so that the
practice is discouraged to some extent.

It may also be a good idea to make even more clear (if possible) that the
two numbers reserved for experimental use are not to be used in shipping
products as defaults.  The current footnote that says this shows up above
the table rather than below where most people would expect to find it, I
think.

--
Wes Eddy
MTI Systems



From andrew.knutsen@bluecoat.com  Wed Dec 23 14:10: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 385AF3A6906 for ; Wed, 23 Dec 2009 14:10:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 W+cRPRkmOybG for ; Wed, 23 Dec 2009 14:10:48 -0800 (PST)
Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id 0A8B33A659C for ; Wed, 23 Dec 2009 14:10:48 -0800 (PST)
Received: from exchfront1.internal.cacheflow.com (exchfront1 [10.2.2.114]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id nBNMAVkB018455; Wed, 23 Dec 2009 14:10:31 -0800 (PST)
Received: from [10.9.84.250] ([10.9.84.250]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Dec 2009 14:10:25 -0800
Message-ID: <4B329551.7010207@bluecoat.com>
Date: Wed, 23 Dec 2009 14:10:25 -0800
From: Andrew Knutsen 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" 
References: 		<4B3162BA.403@isi.edu>	, <4B3169D1.5050707@isi.edu>  <4B3279FC.6060504@bluecoat.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------070405060304080906070309"
X-OriginalArrivalTime: 23 Dec 2009 22:10:25.0918 (UTC) FILETIME=[BAAAB1E0:01CA841C]
Cc: "Mahdavi, Jamshid" , "tcpm@ietf.org" , Joe Touch 
Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG item
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 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, 23 Dec 2009 22:13:47 -0000

This is a multi-part message in MIME format.
--------------070405060304080906070309
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


    Please let us know what we can do in the draft to alleviate your 
concerns.

    Thanks for the RFC references.  The draft already references 3234; I 
can add a similar reference for 3135. A quick reading of the latter 
gives me the impression it takes the opposite side of the argument from 
some parts of 3234 though: it focuses more on how middleboxes are 
useful, rather than potential issues.

    On looking through 3234 again, I noticed section 3 refers to some 
other WGs: MIDCOM,  "a working group with focus on the architectural 
framework and the requirements for the protocol between a requesting 
device and a middlebox and the architectural framework for the interface 
between a middlebox and a policy entity"; and WEBI (Web Intermediaries), 
"a working group that addresses specific issues in the world wide web 
infrastructure (as identified by the WREC working group), by providing 
generic mechanisms which are useful in several application domains 
(e.g., proxies, content delivery surrogates)."

    Perhaps the higher level discussions on how the Internet should 
evolve in the next century (to create a standard middlebox architecture, 
or make them unnecessary) should take place in these groups, if they 
still exist. I can add text to this effect to the draft if desired.

Andrew

Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote:
> I wasn't suggesting that you put it into your document, I was just
> mentioning that I think that some similar context-setting makes
> sense to add if there's a working group product on the topic,
> because as Joe pointed out, there's otherwise potential for some
> confusion.  There are probably much better ways to phrase the actual
> words :).
>
> There are two things going on that I was seeing as distinct (though
> related):
>
> (1) Typical middlebox behaviors (connection-splitting, etc.)
> (2) TCP option number poaching
>
> I think we would be making a statement about (2), and leaving
> advise on (1) to the several existing statements?
>
> --
> Wes Eddy
> MTI Systems
>
>
>   
>> -----Original Message-----
>> From: Andrew Knutsen [mailto:andrew.knutsen@bluecoat.com]
>> Sent: Wednesday, December 23, 2009 3:14 PM
>> To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
>> Cc: Joe Touch; Mahdavi, Jamshid; tcpm@ietf.org
>> Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a
>> TCPM WG item
>>
>>
>>    Are you suggesting we add the text you mention to the draft?  I
>> think we could come up with some similar (if less biased ;-) text.
>> However we need the values of XXX and YYY, preferably with chapter and
>> verse, if its going to be relevant.
>>
>>    Please don't get us wrong; Blue Coat does believe in
>> interoperability (at the appropriate point), and we do have a long-term
>> goal of helping bring standards to today's Internet. But we do have to
>> start where we're at...
>>
>> Andrew
>>
>> Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote:
>>
>> 	There are already several RFCs that discuss the dangers of various
>> middlebox behaviors like splitting TCP connections and pretending to be
>> other hosts, and discourage those behaviors.  We don't really have the
>> ability to decide whether to "allow" these behaviors or not; they're
>> already widespread despite our expressed concerns and the lack of any
>> formal standards encouraging them.  The situation goes from bad to worse
>> when they start poaching options numbers and other assigned values
>> though, without even leaving a paper trail for the community to be aware
>> of what's going on.  IANA's tables become meaningless if big parts of
>> the community stop paying attention to them and deploy new values
>> without regard to the maintenance (or authority) of the registries.
>>
>> 	Though we can't make some of the naughty things middleboxes do go
>> away, I'd think we could at least define this option for them as a
>> sandbox to play within rather than continue to watch them pollute the
>> whole space of options numbers with landmines that will only be
>> painfully discovered in the future.  We'd clearly have the ability to
>> say something like: "Please see references XXX and YYY as to why certain
>> types of middleboxes are short-sighted optimization attempts and harmful
>> to the Internet.  If you choose to ignore that advice and do these
>> things anyways and also decide to use TCP options for some portion of
>> your functionality, as many in-the-wild devices are presently, then
>> please at least do not poach unallocated TCP option numbers which are
>> supposed to be under IANA's control.  Please use option number Z and the
>> accompanying option format defined in this document, which includes a
>> user-specified portion flexible to your needs."
>>
>> 	I'd think that's along the lines of what's being proposed.  It's
>> about (1) raising awareness that poaching assigned values is yet another
>> harmful behavior of middleboxes to be avoided (I'd never heard of it, at
>> least ... ignorance was bliss), and (2) showing the vendors that there's
>> a very easy way they can avoid the problem.
>>
>>
>>
>> 	________________________________________
>> 	From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of
>> Joe Touch [touch@ISI.EDU]
>> 	Sent: Tuesday, December 22, 2009 7:52 PM
>> 	To: Mahdavi, Jamshid
>> 	Cc: tcpm@ietf.org
>> 	Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft
>> as a TCPM WG item
>>
>> 	-----BEGIN PGP SIGNED MESSAGE-----
>> 	Hash: SHA1
>>
>>
>>
>> 	Mahdavi, Jamshid wrote:
>>
>>
>> 		As it happens, we don't modify options at all. What our
>> boxes do is
>> 		terminate one TCP connection (essentially masquerading as
>> the server),
>> 		and then create a new connection to the server (with
>> whatever new
>> 		options we choose) and optionally masquerade as the client
>> on that
>> 		connection (commonly known as ip-spoofing).
>>
>>
>>
>> 	Masquerading is not standards track. You're not only asking for an
>> 	experimental RFC, you're asking us to allow masquerading.
>>
>> 	...
>>
>>
>> 		So, in my view, our draft does not propose to either allow
>> or
>> 		disallow "modification" of TCP options. Instead, we define a
>> new
>> 		option which may be used by devices that originate
>> connections
>> 		(either clients or proxies), or by devices which are already
>> in the
>> 		business of twiddling with existing connections.
>>
>>
>>
>> 	You're defining an option that is only useful by a box that
>> violates
>> 	existing standards - whether they already do so or not, that
>> causes a
>> 	problem AFAICT for TCPM to take this on as a WG item.
>>
>> 	Joe
>>
>>
>>
>> 		-----Original Message-----
>> 		From: Joe Touch [mailto:touch@isi.edu]
>> 		Sent: Tue 12/22/2009 4:22 PM
>> 		To: Mahdavi, Jamshid
>> 		Cc: tcpm@ietf.org
>> 		Subject: Re: [tcpm] poll for consensus on Middlebox Discover
>> draft as a TCPM WG item
>>
>>
>>
>> 		Mahdavi, Jamshid wrote:
>> 		...
>>
>>
>> 			I might be putting some words into Joe's mouth here,
>> but it sounded
>> 			like you would be ok with adopting the general problem
>> of middlebox
>> 			discovery as a WG item, but not necessarily starting
>>     
> >from the solution
>   
>> 			that we have proposed. I think that if we actually
>> need to go back to
>> 			starting at square one we could do that, although
>> you'll understand why
>> 			we'd prefer not to.
>>
>>
>> 		I want to start with understanding the problem and why it
>> has to be
>> 		solved with TCP options in devices that aren't supposed to
>> be modifying
>> 		a TCP header (as opposed to IP options in those packets).
>>
>> 		If this were to move forward, we'd need to understand how
>> many current
>> 		Internet standards are updated by allowing intermediate
>> devices to
>> 		modify TCP headers.
>>
>> 		I don't see a huge problem if these issues are addressed
>> using the
>> 		current solution, e.g., moving forward as suggested by Wes.
>> However, if
>> 		these cannot be sufficiently addressed, I hope we can accept
>> a solution
>> 		that is compatible with the architecture (whether modified
>> or completely
>> 		different - I'm not suggesting I know which is the case,
>> though) - not
>> 		just the one that happens to be deployed.
>>
>> 		A key question is whether this qualifies as a minor
>> modification of TCP,
>> 		or whether this ought to be in the TSVWG. IMO, adding an
>> option is
>> 		minor, but changing the standards to allow middleboxes to
>> modify options
>> 		is major.
>>
>> 		Joe
>>
>>
>> 	-----BEGIN PGP SIGNATURE-----
>> 	Version: GnuPG v1.4.9 (MingW32)
>>
>> 	iEYEARECAAYFAksxadEACgkQE5f5cImnZrutFACcD4ZggKX7+wXmRfHDEqXp4mmu
>> 	NfkAoPD2L9FBOV6RUn4UBrDRm4hxC1di
>> 	=3xz3
>> 	-----END PGP SIGNATURE-----
>> 	_______________________________________________
>> 	tcpm mailing list
>> 	tcpm@ietf.org
>> 	https://www.ietf.org/mailman/listinfo/tcpm
>> 	_______________________________________________
>> 	tcpm mailing list
>> 	tcpm@ietf.org
>> 	https://www.ietf.org/mailman/listinfo/tcpm
>>
>>
>>     
>
>   


--------------070405060304080906070309
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  
  




    Please let us know what we can do in the draft to alleviate your
concerns.



    Thanks for the RFC references.  The draft already references 3234;
I can add a similar reference for 3135. A quick reading of the latter
gives me the impression it takes the opposite side of the argument from
some parts of 3234 though: it focuses more on how middleboxes are
useful, rather than potential issues.



    On looking through 3234 again, I noticed section 3 refers to some
other WGs: MIDCOM,  "a working group with focus on the architectural
framework and the requirements for the protocol between a requesting
device and a middlebox and the architectural framework for the
interface between a middlebox and a policy entity"; and WEBI (Web
Intermediaries), "a working group that addresses specific issues in the
world wide web infrastructure (as identified by the WREC working
group), by providing generic mechanisms which are useful in several
application domains (e.g., proxies, content delivery surrogates)."



    Perhaps the higher level discussions on how the Internet should
evolve in the next century (to create a standard middlebox
architecture, or make them unnecessary) should take place in these
groups, if they still exist. I can add text to this effect to the draft
if desired.



Andrew



Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote:


  
I wasn't suggesting that you put it into your document, I was just
mentioning that I think that some similar context-setting makes
sense to add if there's a working group product on the topic,
because as Joe pointed out, there's otherwise potential for some
confusion.  There are probably much better ways to phrase the actual
words :).

There are two things going on that I was seeing as distinct (though
related):

(1) Typical middlebox behaviors (connection-splitting, etc.)
(2) TCP option number poaching

I think we would be making a statement about (2), and leaving
advise on (1) to the several existing statements?

--
Wes Eddy
MTI Systems


  

  

    
-----Original Message-----
From: Andrew Knutsen [mailto:andrew.knutsen@bluecoat.com]
Sent: Wednesday, December 23, 2009 3:14 PM
To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
Cc: Joe Touch; Mahdavi, Jamshid; tcpm@ietf.org
Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a
TCPM WG item


   Are you suggesting we add the text you mention to the draft?  I
think we could come up with some similar (if less biased ;-) text.
However we need the values of XXX and YYY, preferably with chapter and
verse, if its going to be relevant.

   Please don't get us wrong; Blue Coat does believe in
interoperability (at the appropriate point), and we do have a long-term
goal of helping bring standards to today's Internet. But we do have to
start where we're at...

Andrew

Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote:

	There are already several RFCs that discuss the dangers of various
middlebox behaviors like splitting TCP connections and pretending to be
other hosts, and discourage those behaviors.  We don't really have the
ability to decide whether to "allow" these behaviors or not; they're
already widespread despite our expressed concerns and the lack of any
formal standards encouraging them.  The situation goes from bad to worse
when they start poaching options numbers and other assigned values
though, without even leaving a paper trail for the community to be aware
of what's going on.  IANA's tables become meaningless if big parts of
the community stop paying attention to them and deploy new values
without regard to the maintenance (or authority) of the registries.

	Though we can't make some of the naughty things middleboxes do go
away, I'd think we could at least define this option for them as a
sandbox to play within rather than continue to watch them pollute the
whole space of options numbers with landmines that will only be
painfully discovered in the future.  We'd clearly have the ability to
say something like: "Please see references XXX and YYY as to why certain
types of middleboxes are short-sighted optimization attempts and harmful
to the Internet.  If you choose to ignore that advice and do these
things anyways and also decide to use TCP options for some portion of
your functionality, as many in-the-wild devices are presently, then
please at least do not poach unallocated TCP option numbers which are
supposed to be under IANA's control.  Please use option number Z and the
accompanying option format defined in this document, which includes a
user-specified portion flexible to your needs."

	I'd think that's along the lines of what's being proposed.  It's
about (1) raising awareness that poaching assigned values is yet another
harmful behavior of middleboxes to be avoided (I'd never heard of it, at
least ... ignorance was bliss), and (2) showing the vendors that there's
a very easy way they can avoid the problem.



	________________________________________
	From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of
Joe Touch [touch@ISI.EDU]
	Sent: Tuesday, December 22, 2009 7:52 PM
	To: Mahdavi, Jamshid
	Cc: tcpm@ietf.org
	Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft
as a TCPM WG item

	-----BEGIN PGP SIGNED MESSAGE-----
	Hash: SHA1



	Mahdavi, Jamshid wrote:


		As it happens, we don't modify options at all. What our
boxes do is
		terminate one TCP connection (essentially masquerading as
the server),
		and then create a new connection to the server (with
whatever new
		options we choose) and optionally masquerade as the client
on that
		connection (commonly known as ip-spoofing).



	Masquerading is not standards track. You're not only asking for an
	experimental RFC, you're asking us to allow masquerading.

	...


		So, in my view, our draft does not propose to either allow
or
		disallow "modification" of TCP options. Instead, we define a
new
		option which may be used by devices that originate
connections
		(either clients or proxies), or by devices which are already
in the
		business of twiddling with existing connections.



	You're defining an option that is only useful by a box that
violates
	existing standards - whether they already do so or not, that
causes a
	problem AFAICT for TCPM to take this on as a WG item.

	Joe



		-----Original Message-----
		From: Joe Touch [mailto:touch@isi.edu]
		Sent: Tue 12/22/2009 4:22 PM
		To: Mahdavi, Jamshid
		Cc: tcpm@ietf.org
		Subject: Re: [tcpm] poll for consensus on Middlebox Discover
draft as a TCPM WG item



		Mahdavi, Jamshid wrote:
		...


			I might be putting some words into Joe's mouth here,
but it sounded
			like you would be ok with adopting the general problem
of middlebox
			discovery as a WG item, but not necessarily starting
    

  

  
>from the solution
  

  

    
			that we have proposed. I think that if we actually
need to go back to
			starting at square one we could do that, although
you'll understand why
			we'd prefer not to.


		I want to start with understanding the problem and why it
has to be
		solved with TCP options in devices that aren't supposed to
be modifying
		a TCP header (as opposed to IP options in those packets).

		If this were to move forward, we'd need to understand how
many current
		Internet standards are updated by allowing intermediate
devices to
		modify TCP headers.

		I don't see a huge problem if these issues are addressed
using the
		current solution, e.g., moving forward as suggested by Wes.
However, if
		these cannot be sufficiently addressed, I hope we can accept
a solution
		that is compatible with the architecture (whether modified
or completely
		different - I'm not suggesting I know which is the case,
though) - not
		just the one that happens to be deployed.

		A key question is whether this qualifies as a minor
modification of TCP,
		or whether this ought to be in the TSVWG. IMO, adding an
option is
		minor, but changing the standards to allow middleboxes to
modify options
		is major.

		Joe


	-----BEGIN PGP SIGNATURE-----
	Version: GnuPG v1.4.9 (MingW32)

	iEYEARECAAYFAksxadEACgkQE5f5cImnZrutFACcD4ZggKX7+wXmRfHDEqXp4mmu
	NfkAoPD2L9FBOV6RUn4UBrDRm4hxC1di
	=3xz3
	-----END PGP SIGNATURE-----
	_______________________________________________
	tcpm mailing list
	tcpm@ietf.org
	https://www.ietf.org/mailman/listinfo/tcpm
	_______________________________________________
	tcpm mailing list
	tcpm@ietf.org
	https://www.ietf.org/mailman/listinfo/tcpm


    

  

  

  








--------------070405060304080906070309--

From andrew.knutsen@bluecoat.com  Wed Dec 23 12:14: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 7AEC73A697E for ; Wed, 23 Dec 2009 12:14:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 VUCGgJ1Klubt for ; Wed, 23 Dec 2009 12:14:11 -0800 (PST)
Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id 50A3B3A6906 for ; Wed, 23 Dec 2009 12:14:11 -0800 (PST)
Received: from exchfront1.internal.cacheflow.com (exchfront1 [10.2.2.114]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id nBNKDrxj002639; Wed, 23 Dec 2009 12:13:53 -0800 (PST)
Received: from [10.9.84.250] ([10.9.84.250]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Dec 2009 12:13:48 -0800
Message-ID: <4B3279FC.6060504@bluecoat.com>
Date: Wed, 23 Dec 2009 12:13:48 -0800
From: Andrew Knutsen 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" 
References: 		<4B3162BA.403@isi.edu>	, <4B3169D1.5050707@isi.edu> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------060104050101020403040209"
X-OriginalArrivalTime: 23 Dec 2009 20:13:48.0729 (UTC) FILETIME=[70046290:01CA840C]
Cc: "Mahdavi, Jamshid" , "tcpm@ietf.org" , Joe Touch 
Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG item
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 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, 24 Dec 2009 00:10:50 -0000

This is a multi-part message in MIME format.
--------------060104050101020403040209
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable


    Are you suggesting we add the text you mention to the draft?  I=20
think we could come up with some similar (if less biased ;-) text. =20
However we need the values of XXX and YYY, preferably with chapter and=20
verse, if its going to be relevant.

    Please don't get us wrong; Blue Coat does believe in=20
interoperability (at the appropriate point), and we do have a long-term=20
goal of helping bring standards to today's Internet. But we do have to=20
start where we're at...

Andrew

Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote:
> There are already several RFCs that discuss the dangers of various midd=
lebox behaviors like splitting TCP connections and pretending to be other=
 hosts, and discourage those behaviors.  We don't really have the ability=
 to decide whether to "allow" these behaviors or not; they're already wid=
espread despite our expressed concerns and the lack of any formal standar=
ds encouraging them.  The situation goes from bad to worse when they star=
t poaching options numbers and other assigned values though, without even=
 leaving a paper trail for the community to be aware of what's going on. =
 IANA's tables become meaningless if big parts of the community stop payi=
ng attention to them and deploy new values without regard to the maintena=
nce (or authority) of the registries.
>
> Though we can't make some of the naughty things middleboxes do go away,=
 I'd think we could at least define this option for them as a sandbox to =
play within rather than continue to watch them pollute the whole space of=
 options numbers with landmines that will only be painfully discovered in=
 the future.  We'd clearly have the ability to say something like: "Pleas=
e see references XXX and YYY as to why certain types of middleboxes are s=
hort-sighted optimization attempts and harmful to the Internet.  If you c=
hoose to ignore that advice and do these things anyways and also decide t=
o use TCP options for some portion of your functionality, as many in-the-=
wild devices are presently, then please at least do not poach unallocated=
 TCP option numbers which are supposed to be under IANA's control.  Pleas=
e use option number Z and the accompanying option format defined in this =
document, which includes a user-specified portion flexible to your needs.=
"
>
> I'd think that's along the lines of what's being proposed.  It's about =
(1) raising awareness that poaching assigned values is yet another harmfu=
l behavior of middleboxes to be avoided (I'd never heard of it, at least =
=2E.. ignorance was bliss), and (2) showing the vendors that there's a ve=
ry easy way they can avoid the problem.
>
>
>
> ________________________________________
> From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of Joe To=
uch [touch@ISI.EDU]
> Sent: Tuesday, December 22, 2009 7:52 PM
> To: Mahdavi, Jamshid
> Cc: tcpm@ietf.org
> Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a=
 TCPM WG item
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Mahdavi, Jamshid wrote:
>  =20
>> As it happens, we don't modify options at all. What our boxes do is
>> terminate one TCP connection (essentially masquerading as the server),=

>> and then create a new connection to the server (with whatever new
>> options we choose) and optionally masquerade as the client on that
>> connection (commonly known as ip-spoofing).
>>    =20
>
> Masquerading is not standards track. You're not only asking for an
> experimental RFC, you're asking us to allow masquerading.
>
> ...
>  =20
>> So, in my view, our draft does not propose to either allow or
>> disallow "modification" of TCP options. Instead, we define a new
>> option which may be used by devices that originate connections
>> (either clients or proxies), or by devices which are already in the
>> business of twiddling with existing connections.
>>    =20
>
> You're defining an option that is only useful by a box that violates
> existing standards - whether they already do so or not, that causes a
> problem AFAICT for TCPM to take this on as a WG item.
>
> Joe
>
>  =20
>> -----Original Message-----
>> From: Joe Touch [mailto:touch@isi.edu]
>> Sent: Tue 12/22/2009 4:22 PM
>> To: Mahdavi, Jamshid
>> Cc: tcpm@ietf.org
>> Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as =
a TCPM WG item
>>
>>
>>
>> Mahdavi, Jamshid wrote:
>> ...
>>    =20
>>> I might be putting some words into Joe's mouth here, but it sounded
>>> like you would be ok with adopting the general problem of middlebox
>>> discovery as a WG item, but not necessarily starting from the solutio=
n
>>> that we have proposed. I think that if we actually need to go back to=

>>> starting at square one we could do that, although you'll understand w=
hy
>>> we'd prefer not to.
>>>      =20
>> I want to start with understanding the problem and why it has to be
>> solved with TCP options in devices that aren't supposed to be modifyin=
g
>> a TCP header (as opposed to IP options in those packets).
>>
>> If this were to move forward, we'd need to understand how many current=

>> Internet standards are updated by allowing intermediate devices to
>> modify TCP headers.
>>
>> I don't see a huge problem if these issues are addressed using the
>> current solution, e.g., moving forward as suggested by Wes. However, i=
f
>> these cannot be sufficiently addressed, I hope we can accept a solutio=
n
>> that is compatible with the architecture (whether modified or complete=
ly
>> different - I'm not suggesting I know which is the case, though) - not=

>> just the one that happens to be deployed.
>>
>> A key question is whether this qualifies as a minor modification of TC=
P,
>> or whether this ought to be in the TSVWG. IMO, adding an option is
>> minor, but changing the standards to allow middleboxes to modify optio=
ns
>> is major.
>>
>> Joe
>>    =20
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
>
> iEYEARECAAYFAksxadEACgkQE5f5cImnZrutFACcD4ZggKX7+wXmRfHDEqXp4mmu
> NfkAoPD2L9FBOV6RUn4UBrDRm4hxC1di
> =3D3xz3
> -----END PGP SIGNATURE-----
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>  =20


--------------060104050101020403040209
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  
  




    Are you suggesting we add the text you mention to the draft?  I
think we could come up with some similar (if less biased ;-) text. 
However we need the values of XXX and YYY, preferably with chapter and
verse, if its going to be relevant.



    Please don't get us wrong; Blue Coat does believe in
interoperability (at the appropriate point), and we do have a long-term
goal of helping bring standards to today's Internet. But we do have to
start where we're at...



Andrew



Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote:


  
There are already several RFCs that discuss the dangers of various middlebox behaviors like splitting TCP connections and pretending to be other hosts, and discourage those behaviors.  We don't really have the ability to decide whether to "allow" these behaviors or not; they're already widespread despite our expressed concerns and the lack of any formal standards encouraging them.  The situation goes from bad to worse when they start poaching options numbers and other assigned values though, without even leaving a paper trail for the community to be aware of what's going on.  IANA's tables become meaningless if big parts of the community stop paying attention to them and deploy new values without regard to the maintenance (or authority) of the registries.

Though we can't make some of the naughty things middleboxes do go away, I'd think we could at least define this option for them as a sandbox to play within rather than continue to watch them pollute the whole space of options numbers with landmines that will only be painfully discovered in the future.  We'd clearly have the ability to say something like: "Please see references XXX and YYY as to why certain types of middleboxes are short-sighted optimization attempts and harmful to the Internet.  If you choose to ignore that advice and do these things anyways and also decide to use TCP options for some portion of your functionality, as many in-the-wild devices are presently, then please at least do not poach unallocated TCP option numbers which are supposed to be under IANA's control.  Please use option number Z and the accompanying option format defined in this document, which includes a user-specified portion flexible to your needs."

I'd think that's along the lines of what's being proposed.  It's about (1) raising awareness that poaching assigned values is yet another harmful behavior of middleboxes to be avoided (I'd never heard of it, at least ... ignorance was bliss), and (2) showing the vendors that there's a very easy way they can avoid the problem.



________________________________________
From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of Joe Touch [touch@ISI.EDU]
Sent: Tuesday, December 22, 2009 7:52 PM
To: Mahdavi, Jamshid
Cc: tcpm@ietf.org
Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG item

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Mahdavi, Jamshid wrote:
  

  

    
As it happens, we don't modify options at all. What our boxes do is
terminate one TCP connection (essentially masquerading as the server),
and then create a new connection to the server (with whatever new
options we choose) and optionally masquerade as the client on that
connection (commonly known as ip-spoofing).
    

  

  

Masquerading is not standards track. You're not only asking for an
experimental RFC, you're asking us to allow masquerading.

...
  

  

    
So, in my view, our draft does not propose to either allow or
disallow "modification" of TCP options. Instead, we define a new
option which may be used by devices that originate connections
(either clients or proxies), or by devices which are already in the
business of twiddling with existing connections.
    

  

  

You're defining an option that is only useful by a box that violates
existing standards - whether they already do so or not, that causes a
problem AFAICT for TCPM to take this on as a WG item.

Joe

  

  

    
-----Original Message-----
From: Joe Touch [mailto:touch@isi.edu]
Sent: Tue 12/22/2009 4:22 PM
To: Mahdavi, Jamshid
Cc: tcpm@ietf.org
Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG item



Mahdavi, Jamshid wrote:
...
    

    

      
I might be putting some words into Joe's mouth here, but it sounded
like you would be ok with adopting the general problem of middlebox
discovery as a WG item, but not necessarily starting from the solution
that we have proposed. I think that if we actually need to go back to
starting at square one we could do that, although you'll understand why
we'd prefer not to.
      

    

    
I want to start with understanding the problem and why it has to be
solved with TCP options in devices that aren't supposed to be modifying
a TCP header (as opposed to IP options in those packets).

If this were to move forward, we'd need to understand how many current
Internet standards are updated by allowing intermediate devices to
modify TCP headers.

I don't see a huge problem if these issues are addressed using the
current solution, e.g., moving forward as suggested by Wes. However, if
these cannot be sufficiently addressed, I hope we can accept a solution
that is compatible with the architecture (whether modified or completely
different - I'm not suggesting I know which is the case, though) - not
just the one that happens to be deployed.

A key question is whether this qualifies as a minor modification of TCP,
or whether this ought to be in the TSVWG. IMO, adding an option is
minor, but changing the standards to allow middleboxes to modify options
is major.

Joe
    

  

  
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAksxadEACgkQE5f5cImnZrutFACcD4ZggKX7+wXmRfHDEqXp4mmu
NfkAoPD2L9FBOV6RUn4UBrDRm4hxC1di
=3xz3
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
  








--------------060104050101020403040209--

From nwnetworks@dial.pipex.com  Mon Dec 28 10:56: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 992143A6920 for ; Mon, 28 Dec 2009 10:56:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.07
X-Spam-Level: *
X-Spam-Status: No, score=1.07 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DATE_IN_PAST_06_12=1.069]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeO97x3VKNmF for ; Mon, 28 Dec 2009 10:56:29 -0800 (PST)
Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 595B53A6816 for ; Mon, 28 Dec 2009 10:56:29 -0800 (PST)
X-Trace: 315309183/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.58/None/nwnetworks@dial.pipex.com
X-SBRS: None
X-RemoteIP: 62.188.105.58
X-IP-MAIL-FROM: nwnetworks@dial.pipex.com
X-SMTP-AUTH: 
X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106
X-IP-BHB: Once
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtUFAA6OOEs+vGk6/2dsb2JhbABCghoqhS+ITMROCoQpBA
X-IronPort-AV: E=Sophos;i="4.47,463,1257120000"; d="scan'208";a="315309183"
X-IP-Direction: IN
Received: from 1cust58.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.58]) by smtp.pipex.tiscali.co.uk with SMTP; 28 Dec 2009 18:56:08 +0000
Message-ID: <002001ca87e7$1885d6a0$0601a8c0@allison>
From: "Tom Petch" 
To: "Eddy, Wesley M. \(GRC-MS00\)[ASRC AEROSPACE CORP]" , 
References: 
Date: Mon, 28 Dec 2009 12:25:13 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Cc: tcpm@ietf.org
Subject: Re: [tcpm] unallocated TCP options in-use
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Tom Petch 
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Dec 2009 18:56:30 -0000

--- Original Message -----
From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" 
Sent: Wednesday, December 23, 2009 11:06 PM

> In the IETF's TCPM working group, there's been a revelation that several
> TCP Options Numbers, not listed as allocated in IANA's registry, are in
> use on the Internet.
>
> I think IANA is in the best position to decide how to deal with this, but

Disagree.

I think that the IETF at large is the body that should decide this, so the
discussion should be on the main IETF list.  That would need a chair to call
rough consensus - perhaps one of our ADs would oblige.

Tom Petch

> it's been proposed that they be added to your registry for TCP options:
> http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml
>
> The values to add are:
> 0x21 - Cisco middlebox discovery
> 0x4C - Riverbed middlebox discovery
> 0x4E - Riverbed middlebox discovery
>
> One suggestion was to label these as "inappropriate use" so that the
> practice is discouraged to some extent.
>
> It may also be a good idea to make even more clear (if possible) that the
> two numbers reserved for experimental use are not to be used in shipping
> products as defaults.  The current footnote that says this shows up above
> the table rather than below where most people would expect to find it, I
> think.
>
> --
> Wes Eddy
> MTI Systems
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm


From touch@ISI.EDU  Mon Dec 28 11:06: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 95E343A691D for ; Mon, 28 Dec 2009 11:06:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=-0.003, 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 ofm978hYZiiI for ; Mon, 28 Dec 2009 11:06:34 -0800 (PST)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 5FCF43A6927 for ; Mon, 28 Dec 2009 11:06:34 -0800 (PST)
Received: from [192.168.1.95] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nBSJ5NIm028265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 28 Dec 2009 11:05:26 -0800 (PST)
Message-ID: <4B390173.4070003@isi.edu>
Date: Mon, 28 Dec 2009 11:05:23 -0800
From: Joe Touch 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Tom Petch 
References:  <002001ca87e7$1885d6a0$0601a8c0@allison>
In-Reply-To: <002001ca87e7$1885d6a0$0601a8c0@allison>
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, iana@iana.org
Subject: Re: [tcpm] unallocated TCP options in-use
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 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, 28 Dec 2009 19:06:35 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Tom Petch wrote:
> --- Original Message -----
> From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" 
> Sent: Wednesday, December 23, 2009 11:06 PM
> 
>> In the IETF's TCPM working group, there's been a revelation that several
>> TCP Options Numbers, not listed as allocated in IANA's registry, are in
>> use on the Internet.
>>
>> I think IANA is in the best position to decide how to deal with this, but
> 
> Disagree.
> 
> I think that the IETF at large is the body that should decide this, so the
> discussion should be on the main IETF list.  That would need a chair to call
> rough consensus - perhaps one of our ADs would oblige.

What are the possible alternatives other than noting that these options
are being used without being allocated, and are thus their use in the
public Internet is inappropriate?

Joe


>> it's been proposed that they be added to your registry for TCP options:
>> http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml
>>
>> The values to add are:
>> 0x21 - Cisco middlebox discovery
>> 0x4C - Riverbed middlebox discovery
>> 0x4E - Riverbed middlebox discovery
>>
>> One suggestion was to label these as "inappropriate use" so that the
>> practice is discouraged to some extent.
>>
>> It may also be a good idea to make even more clear (if possible) that the
>> two numbers reserved for experimental use are not to be used in shipping
>> products as defaults.  The current footnote that says this shows up above
>> the table rather than below where most people would expect to find it, I
>> think.
>>
>> --
>> Wes Eddy
>> MTI Systems
>>
>>
>> _______________________________________________
>> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAks5AXIACgkQE5f5cImnZrtDJwCgh6uJ/D/AlUTr4pMFladjt0sd
3WEAni6itdI97tKcEjnOQWHu6FIl5jge
=Sc5K
-----END PGP SIGNATURE-----

From nwnetworks@dial.pipex.com  Thu Dec 31 10:15: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 30BE63A6A01 for ; Thu, 31 Dec 2009 10:15:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.558
X-Spam-Level: 
X-Spam-Status: No, score=0.558 tagged_above=-999 required=5 tests=[AWL=0.513,  BAYES_50=0.001, 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 NihFBiTmUcJH for ; Thu, 31 Dec 2009 10:15:01 -0800 (PST)
Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id EC1983A6A4E for ; Thu, 31 Dec 2009 10:15:00 -0800 (PST)
X-Trace: 226708939/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.33/None/nwnetworks@dial.pipex.com
X-SBRS: None
X-RemoteIP: 62.188.100.33
X-IP-MAIL-FROM: nwnetworks@dial.pipex.com
X-SMTP-AUTH: 
X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106
X-IP-BHB: Once
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: As4EAD94PEs+vGQh/2dsb2JhbABAghqFWIhLwx8KhCcEjTI
X-IronPort-AV: E=Sophos;i="4.47,483,1257120000"; d="scan'208";a="226708939"
X-IP-Direction: IN
Received: from 1cust33.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.33]) by smtp.pipex.tiscali.co.uk with SMTP; 31 Dec 2009 18:13:39 +0000
Message-ID: <02a701ca8a3c$a6b79380$0601a8c0@allison>
From: "Tom Petch" 
To: "Joe Touch" 
References: <002001ca87e7$1885d6a0$0601a8c0@allison> <4B390173.4070003@isi.edu>
Date: Thu, 31 Dec 2009 14:49:15 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Cc: tcpm@ietf.org, iana@iana.org
Subject: Re: [tcpm] unallocated TCP options in-use
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Tom Petch 
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Dec 2009 18:15:02 -0000

----- Original Message -----
From: "Joe Touch" 
Sent: Monday, December 28, 2009 8:05 PM
>
> Tom Petch wrote:
> > --- Original Message -----
> > From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]"

> > Sent: Wednesday, December 23, 2009 11:06 PM
> >
> >> In the IETF's TCPM working group, there's been a revelation that several
> >> TCP Options Numbers, not listed as allocated in IANA's registry, are in
> >> use on the Internet.
> >>
> >> I think IANA is in the best position to decide how to deal with this, but
> >
> > Disagree.
> >
> > I think that the IETF at large is the body that should decide this, so the
> > discussion should be on the main IETF list.  That would need a chair to call
> > rough consensus - perhaps one of our ADs would oblige.
>
> What are the possible alternatives other than noting that these options
> are being used without being allocated, and are thus their use in the
> public Internet is inappropriate?

The policy could take several forms.

Do nothing
Document them privately
Document them publicly but in a format that expresses disapproval
Document them publicly without disapproval but noting that there is no RFC to
endorse their use

'One suggestion was to label these as "inappropriate use" so that the
practice is discouraged to some extent.'  Some might think this too
mild.

Doubtless others will think of other options.

Tom Petch

> Joe
>
> >> it's been proposed that they be added to your registry for TCP options:
> >> http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml
> >>
> >> The values to add are:
> >> 0x21 - Cisco middlebox discovery
> >> 0x4C - Riverbed middlebox discovery
> >> 0x4E - Riverbed middlebox discovery
> >>
> >> One suggestion was to label these as "inappropriate use" so that the
> >> practice is discouraged to some extent.
> >>
> >> It may also be a good idea to make even more clear (if possible) that the
> >> two numbers reserved for experimental use are not to be used in shipping
> >> products as defaults.  The current footnote that says this shows up above
> >> the table rather than below where most people would expect to find it, I
> >> think.
> >>
> >> --
> >> Wes Eddy
> >> MTI Systems


From touch@ISI.EDU  Thu Dec 31 10:36: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 ED6B53A694E for ; Thu, 31 Dec 2009 10:36:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=-0.003, 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 1NlW7gCf+afx for ; Thu, 31 Dec 2009 10:36:40 -0800 (PST)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id E58173A682A for ; Thu, 31 Dec 2009 10:36:39 -0800 (PST)
Received: from [192.168.1.95] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id nBVIZXSe016563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 31 Dec 2009 10:35:34 -0800 (PST)
Message-ID: <4B3CEEF6.4040006@isi.edu>
Date: Thu, 31 Dec 2009 10:35:34 -0800
From: Joe Touch 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Tom Petch 
References: <002001ca87e7$1885d6a0$0601a8c0@allison> <4B390173.4070003@isi.edu> <02a701ca8a3c$a6b79380$0601a8c0@allison>
In-Reply-To: <02a701ca8a3c$a6b79380$0601a8c0@allison>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-MailScanner-ID: nBVIZXSe016563
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm@ietf.org, iana@iana.org
Subject: Re: [tcpm] unallocated TCP options in-use
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 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, 31 Dec 2009 18:36:41 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Tom Petch wrote:
> ----- Original Message -----
> From: "Joe Touch" 
> Sent: Monday, December 28, 2009 8:05 PM
>> Tom Petch wrote:
>>> --- Original Message -----
>>> From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]"
> 
>>> Sent: Wednesday, December 23, 2009 11:06 PM
>>>
>>>> In the IETF's TCPM working group, there's been a revelation that several
>>>> TCP Options Numbers, not listed as allocated in IANA's registry, are in
>>>> use on the Internet.
>>>>
>>>> I think IANA is in the best position to decide how to deal with this, but
>>> Disagree.
>>>
>>> I think that the IETF at large is the body that should decide this, so the
>>> discussion should be on the main IETF list.  That would need a chair to call
>>> rough consensus - perhaps one of our ADs would oblige.
>>
>> What are the possible alternatives other than noting that these options
>> are being used without being allocated, and are thus their use in the
>> public Internet is inappropriate?
> 
> The policy could take several forms.
> 
> Do nothing
> Document them privately
> Document them publicly but in a format that expresses disapproval
> Document them publicly without disapproval but noting that there is no RFC to
> endorse their use
> 
> 'One suggestion was to label these as "inappropriate use" so that the
> practice is discouraged to some extent.'  Some might think this too
> mild.

Of the 4 options above, labeling them is option 3.

Of the 4 options above, options 1,2 do nothing to discourage squatting,
thus they implicitly endorse it, which defeats the purpose of IANA in
managing that space.

Option 4 explicitly endorses squatting.

That's why it seems to me that option 3 is IANA's only reasonable way
forward, esp. as it mirrors what is done for ports.

> Doubtless others will think of other options.

It'd be interesting to hear if there are any that aren't the above, and
how they specifically address IANA's management of the space.

Joe

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAks87vUACgkQE5f5cImnZruu5ACcCmoO+lP2m0IqFFXGCVP03Tkf
08QAoOd8WISY51xdwF40fWwBE1K2fCJn
=AZ2F
-----END PGP SIGNATURE-----

From william.allen.simpson@gmail.com  Thu Dec 31 10:59: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 972B83A6873 for ; Thu, 31 Dec 2009 10:59:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.547
X-Spam-Level: 
X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=1.052,  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 lvif0eL8cqMG for ; Thu, 31 Dec 2009 10:59:47 -0800 (PST)
Received: from mail-yw0-f196.google.com (mail-yw0-f196.google.com [209.85.211.196]) by core3.amsl.com (Postfix) with ESMTP id 90E803A68D0 for ; Thu, 31 Dec 2009 10:59:47 -0800 (PST)
Received: by ywh34 with SMTP id 34so5751051ywh.31 for ; Thu, 31 Dec 2009 10:59:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=OI/8IxccPEAm9elbfzXbWCzu+OuPh+IHsP5lVzr62jw=; b=Uw+M+l7aPCMejbpvCuXupot8NBSDarssiwHpiU4oBGK8myKlTY0AywTPww7PUbdWxL cQg/rSnUAUNW8Fcdcwf324xfWFMdRfataXaW20meW27fRu2ay82QPFHuqsybOSXKflRz /NrcXaO4OpFMrz44fISr/3RH8meEdHkrBfzcw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=ATsT5qO4RqRECxrI9+4210wxG6RK2qU5bymCoE2O09UPsoTKvKWx0u5pSCiMzbbzcY v8CcMv2V/GRvbBnvAZx97V9l+5qvGVGBz6ma468THPHhxCjNKQwgnuq9T/x6CW4j7Xoz fsJrpXSVZ9Z69wIyWdfWa8JI3uksDuyg05lFM=
Received: by 10.90.5.6 with SMTP id 6mr937796age.106.1262285964340; Thu, 31 Dec 2009 10:59:24 -0800 (PST)
Received: from Wastrel.local (c-68-40-195-221.hsd1.mi.comcast.net [68.40.195.221]) by mx.google.com with ESMTPS id 20sm13929103iwn.9.2009.12.31.10.59.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 31 Dec 2009 10:59:23 -0800 (PST)
Message-ID: <4B3CF48A.8050103@gmail.com>
Date: Thu, 31 Dec 2009 13:59:22 -0500
From: William Allen Simpson 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Joe Touch 
References: <002001ca87e7$1885d6a0$0601a8c0@allison>	<4B390173.4070003@isi.edu> <02a701ca8a3c$a6b79380$0601a8c0@allison> <4B3CEEF6.4040006@isi.edu>
In-Reply-To: <4B3CEEF6.4040006@isi.edu>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: tcpm@ietf.org, Tom Petch , iana@iana.org
Subject: Re: [tcpm] unallocated TCP options in-use
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 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, 31 Dec 2009 18:59:48 -0000

Joe Touch wrote:
> It'd be interesting to hear if there are any that aren't the above, and
> how they specifically address IANA's management of the space.
> 
The route that I chose a couple of months ago was to fill out the IANA
form....  After all, IANA already has a way to handle these non-working
group related assignments:

   http://iana.org/protocols/apply/

BTW, I'm using:

   31 (0x1f) TCP Cookie Transactions
   32 (0x20) 64-bit Timestamps

Make a note of it.

From touch@ISI.EDU  Thu Dec 31 12:26: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 B0A1A3A6856 for ; Thu, 31 Dec 2009 12:26:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=-0.003, 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 cB+F0l72ehOk for ; Thu, 31 Dec 2009 12:26:39 -0800 (PST)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id CEC533A67EE for ; Thu, 31 Dec 2009 12:26:39 -0800 (PST)
Received: from [192.168.1.95] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nBVKPd1l023054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 31 Dec 2009 12:25:41 -0800 (PST)
Message-ID: <4B3D08C3.5070509@isi.edu>
Date: Thu, 31 Dec 2009 12:25:39 -0800
From: Joe Touch 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: William Allen Simpson 
References: <002001ca87e7$1885d6a0$0601a8c0@allison>	<4B390173.4070003@isi.edu> <02a701ca8a3c$a6b79380$0601a8c0@allison> <4B3CEEF6.4040006@isi.edu> <4B3CF48A.8050103@gmail.com>
In-Reply-To: <4B3CF48A.8050103@gmail.com>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm@ietf.org, Tom Petch , iana@iana.org
Subject: Re: [tcpm] unallocated TCP options in-use
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 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, 31 Dec 2009 20:26:40 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



William Allen Simpson wrote:
> Joe Touch wrote:
>> It'd be interesting to hear if there are any that aren't the above, and
>> how they specifically address IANA's management of the space.
>>
> The route that I chose a couple of months ago was to fill out the IANA
> form....  After all, IANA already has a way to handle these non-working
> group related assignments:
> 
>   http://iana.org/protocols/apply/
> 
> BTW, I'm using:
> 
>   31 (0x1f) TCP Cookie Transactions
>   32 (0x20) 64-bit Timestamps
> 
> Make a note of it.

IANA also has requirements for assignments - for TCP options, they are
IESG approval or standards action.

Has either gone through either process? If not, then these too would be
unauthorized use.

Joe

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAks9CMMACgkQE5f5cImnZrtuwACdE3MGO2mfOqwxrLZPa85zZFtA
BPEAoN6ZjzIVvRrb0mVLzZf8jmV3hM5d
=lR52
-----END PGP SIGNATURE-----

From william.allen.simpson@gmail.com  Thu Dec 31 15:52:33 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 42ABB3A68DD for ; Thu, 31 Dec 2009 15:52:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[AWL=0.701,  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 YH0K5wTsfUdh for ; Thu, 31 Dec 2009 15:52:32 -0800 (PST)
Received: from mail-iw0-f195.google.com (mail-iw0-f195.google.com [209.85.223.195]) by core3.amsl.com (Postfix) with ESMTP id 6D5C53A6920 for ; Thu, 31 Dec 2009 15:52:32 -0800 (PST)
Received: by iwn33 with SMTP id 33so1245276iwn.29 for ; Thu, 31 Dec 2009 15:52:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=v/kvbIM/8txni6d5J6rsCeLFP5ONXpTUXrPMxGOg/zc=; b=D0Mx7X4nAxeqW+EZMfkFUBMPpcuoFkWCAzKy3sZnHoeFRbzQqP2aUvqi4WE+dI96L9 mvAbU/iWpfJ/cqGfHl+pdAATC3swFZ+05IyZnfvELLlvKXP/UXO7fTt0gER6KNVIzMs0 cqVFjx1jZhAT7SuIt52Hzn5kCJ53iDfH4LffQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Rz+b8TNu/BKCY6KaD+dTd5V5fRAWSV5P7nxHedJTZ3vuaxrZ+6cl9fQy/9Gbw3gxLP VFsbqEOOfrJ8X/vS1RnOIEigWwvK2g4p8rQYCN2Se/WMstTTfwiNPPKHG6QvD9wKefBZ qaS0VZ5c4/cDuvChERhpBBgwdRV2aTyfNJxb8=
Received: by 10.231.10.23 with SMTP id n23mr1688614ibn.4.1262303529414; Thu, 31 Dec 2009 15:52:09 -0800 (PST)
Received: from Wastrel.local (c-68-40-195-221.hsd1.mi.comcast.net [68.40.195.221]) by mx.google.com with ESMTPS id 22sm14149515iwn.0.2009.12.31.15.52.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 31 Dec 2009 15:52:08 -0800 (PST)
Message-ID: <4B3D3926.1000105@gmail.com>
Date: Thu, 31 Dec 2009 18:52:06 -0500
From: William Allen Simpson 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Joe Touch 
References: <002001ca87e7$1885d6a0$0601a8c0@allison>	<4B390173.4070003@isi.edu> <02a701ca8a3c$a6b79380$0601a8c0@allison> <4B3CEEF6.4040006@isi.edu> <4B3CF48A.8050103@gmail.com> <4B3D08C3.5070509@isi.edu>
In-Reply-To: <4B3D08C3.5070509@isi.edu>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: tcpm@ietf.org, Tom Petch , iana@iana.org
Subject: Re: [tcpm] [IANA #290479] unallocated TCP options in-use
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 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, 31 Dec 2009 23:52:33 -0000

For some odd reason, my previous message was assigned a number, so I'm
including it in the subject.  Presumably, all the rest of you also had
some number assigned, too.


Joe Touch wrote:
> IANA also has requirements for assignments - for TCP options, they are
> IESG approval or standards action.
> 
> Has either gone through either process? If not, then these too would be
> unauthorized use.
> 
You asked about a 5th option, I'm merely pointing you to the current
process (which wasn't covered in the 4 options given).

Since it is IANA's process, I'm assuming that when we fill out their
form, they send the assignment along to IESG for pro forma approval.
IANA is a collector of information, not an "authorizer" per se.

As to the latter, this thread is about non-working-group actions, thus
not standards action (by definition).

If having been informed, IANA fails to handle the processing, then
that's not my problem (nor Cisco's nor anybody else).  Does anybody know
whether Cisco bothered to submit the assignment form?

I do remember MicroSoft, during their embrace and extend days, refused
to even inform IANA or anybody about protocol numbers they were
self-assigning.  That lead to conflicts.

My only interest is avoiding assignment conflicts.
--
Happy New Year


From touch@ISI.EDU  Thu Dec 31 19:54: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 CAF033A6860 for ; Thu, 31 Dec 2009 19:54:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=-0.003, 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 gSZgN-kFcj86 for ; Thu, 31 Dec 2009 19:54:16 -0800 (PST)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 11F0D3A67B1 for ; Thu, 31 Dec 2009 19:54:16 -0800 (PST)
Received: from [192.168.1.46] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o013qHwv029081 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 31 Dec 2009 19:52:21 -0800 (PST)
From: Joe Touch 
To: William Allen Simpson 
In-Reply-To: <4B3D3926.1000105@gmail.com>
X-Mailer: iPhone Mail (7D11)
References: <002001ca87e7$1885d6a0$0601a8c0@allison>	<4B390173.4070003@isi.edu> <02a701ca8a3c$a6b79380$0601a8c0@allison> <4B3CEEF6.4040006@isi.edu> <4B3CF48A.8050103@gmail.com> <4B3D08C3.5070509@isi.edu> <4B3D3926.1000105@gmail.com>
Message-Id: 
Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (iPhone Mail 7D11)
Date: Thu, 31 Dec 2009 19:52:13 -0800
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "tcpm@ietf.org" , Tom Petch , "iana@iana.org" 
Subject: Re: [tcpm] [IANA #290479] unallocated TCP options in-use
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 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, 01 Jan 2010 03:54:16 -0000

Fixing a nonassigned number to make it assigned is an option, but not  
a very easy one. One presumes the IESG doesn't rubberstamp such  
applications.

Joe

Sent from my iPhone

On Dec 31, 2009, at 3:52 PM, William Allen Simpson  wrote:

> For some odd reason, my previous message was assigned a number, so I'm
> including it in the subject.  Presumably, all the rest of you also had
> some number assigned, too.
>
>
> Joe Touch wrote:
>> IANA also has requirements for assignments - for TCP options, they  
>> are
>> IESG approval or standards action.
>> Has either gone through either process? If not, then these too  
>> would be
>> unauthorized use.
> You asked about a 5th option, I'm merely pointing you to the current
> process (which wasn't covered in the 4 options given).
>
> Since it is IANA's process, I'm assuming that when we fill out their
> form, they send the assignment along to IESG for pro forma approval.
> IANA is a collector of information, not an "authorizer" per se.
>
> As to the latter, this thread is about non-working-group actions, thus
> not standards action (by definition).
>
> If having been informed, IANA fails to handle the processing, then
> that's not my problem (nor Cisco's nor anybody else).  Does anybody  
> know
> whether Cisco bothered to submit the assignment form?
>
> I do remember MicroSoft, during their embrace and extend days, refused
> to even inform IANA or anybody about protocol numbers they were
> self-assigning.  That lead to conflicts.
>
> My only interest is avoiding assignment conflicts.
> --
> Happy New Year