Re: [tcpm] closing WGLC for TCP-AO

"Anantha Ramaiah (ananth)" <ananth@cisco.com> Wed, 02 December 2009 07:19 UTC

Return-Path: <ananth@cisco.com>
X-Original-To: tcpm@core3.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 <tcpm@core3.amsl.com>; 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 <tcpm@core3.amsl.com>; 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 <tcpm@ietf.org>; 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, 01 Dec 2009 23:19:11 -0800
Message-ID: <0C53DCFB700D144284A584F54711EC58087D6B17@xmb-sjc-21c.amer.cisco.com>
In-Reply-To: <C304DB494AC0C04C87C6A6E2FF5603DB47D7AED9C3@NDJSSCC01.ndc.nasa.gov>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [tcpm] closing WGLC for TCP-AO
Thread-Index: Acpyzx3mMN5CpAIqSqSwb6k6u7bDpwASa9cw
References: <C304DB494AC0C04C87C6A6E2FF5603DB47D7AED9C3@NDJSSCC01.ndc.nasa.gov>
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <wesley.m.eddy@nasa.gov>, tcpm@ietf.org
X-OriginalArrivalTime: 02 Dec 2009 07:19:14.0190 (UTC) FILETIME=[C05BC2E0:01CA731F]
Cc: Joe Touch <touch@isi.edu>
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 <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=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.) 

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 
> 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
>