[tcpm] TCP-AO review comments.

"Anantha Ramaiah (ananth)" <ananth@cisco.com> Mon, 28 July 2008 08:16 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from [] (localhost []) by core3.amsl.com (Postfix) with ESMTP id BE5F23A6AD7; Mon, 28 Jul 2008 01:16:54 -0700 (PDT)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id C5DDE3A6ADD for <tcpm@core3.amsl.com>; Mon, 28 Jul 2008 01:16:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
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 ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id if1tx4uh4oLy for <tcpm@core3.amsl.com>; Mon, 28 Jul 2008 01:16:52 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com []) by core3.amsl.com (Postfix) with ESMTP id 2D19E3A6A31 for <tcpm@ietf.org>; Mon, 28 Jul 2008 01:16:52 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.31,264,1215388800"; d="scan'208";a="69520893"
Received: from sj-dkim-4.cisco.com ([]) by sj-iport-2.cisco.com with ESMTP; 28 Jul 2008 08:17:01 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com []) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m6S8H0aO022572 for <tcpm@ietf.org>; Mon, 28 Jul 2008 01:17:00 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com []) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6S8H0U6023406 for <tcpm@ietf.org>; Mon, 28 Jul 2008 08:17:00 GMT
Received: from xmb-sjc-21c.amer.cisco.com ([]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jul 2008 01:17:00 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 28 Jul 2008 01:17:00 -0700
Message-ID: <0C53DCFB700D144284A584F54711EC58058C2FD4@xmb-sjc-21c.amer.cisco.com>
Thread-Topic: TCP-AO review comments.
Thread-Index: AcjwfncrprtVx7MJRpe3GEDbm58hBQ==
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: tcpm@ietf.org
X-OriginalArrivalTime: 28 Jul 2008 08:17:00.0169 (UTC) FILETIME=[4F012F90:01C8F08A]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3629; t=1217233020; x=1218097020; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20<ananth@cisco .com> |Subject:=20TCP-AO=20review=20comments. |Sender:=20; bh=Rc+180CdZziRE/7l8mozV1IFJ60FNjMGKupSDBa3PB8=; b=WY3y02BX4x+n33IwH7jKHirLgyzeIMqdTMSfV0Po4g1rkV9UsYS6nvhx6M J61NYL4F8Wa2Sy50/0lTbKqOa2K4HBy3/t6BW7rUNTb60mPC9GKM6cDv3GQM e1+QaB01me;
Authentication-Results: sj-dkim-4; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; );
Subject: [tcpm] TCP-AO review comments.
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

  I went over the latest copy of the TCP authentication draft and
jotting down my observations and comments.

   I have problem with the term "obsoletes 2385" [ I did bring this up
before] It is going to be a long time before deployments move over to
the new TCP auth option. Many customers (deployments) are fine with TCP
MD5 with periodic key rollover option and hence would not move to TCP-AO
immediately. So, in short it really depends on combination of perceived
threat levels, desired security level of a network. Also, TCP-AO is
taking a new TCP option number with backward compatibility in mind.


- It mentions BGP and LDP. FWIW MSDP also uses TCP MD5 and some
proprietary protocols as well. Should we use the word, "long lived
connections" instead? Just wanted to convey the feeling that it is
intended to be a generic TCP authentication option.

Section 1.1

"allows rekeying during a TCP connection "

2385 doesn't mention re-keying nor does it preclude one from doing so.
Like I mentioned earlier, deployments have been running code with some
implicit key rollover schemes.

Section 3
(security association management (TSAD)

- IMO, the contents and interpreation of TSAD should be implementation
specific. Applications can use some out of band (or configuration)
mechanism to set up the TSAD. 

- It says : "there MUST be no more than one matching TSAD entry" Not
sure why, you could have a primary and secondary key here. (I understand
that this is not robust) but using a MUST here seems too much of a
restriction. In other words, IMO, this document shouldn't be specifying
too much about TSAD. 

- TCP option exclusion : reading this it seems unclear to me as to
whether TCP-AO is excluded in the option calculation or not. 

- it says : "TCP option kind exclusion list MUST NOT change during TCP
connection" Not sure why? Needs explanation.

- It says "keyID MAY have value of 0" - really what is the point here?
Also, shouldn't we allow non-numeric key ID's ?

- "Asymmetric use of TCP-AO" - I am kind of confused here, are we saying
that the ACK's are not going to be signed, from the peer which has
negotaited "NONE" ? If so, isn't a security hole since someone can spoof
an ACK and cause issues for the side which HAS signed up for

- Question :
I have heard cases where some customers (although rare) want the
authentication to be turned off at some point of time, and also turned
on dynamically. TCP, today doesn't allow options negotiation "on
demand", so the latter point is moot for now. What are the thoughts
about turning off the AO option ?

- TCP user interface - I am not sure why this document (no other TCP
option document even mentions that), for eg:- STATUS call, there is no
such thing as TCP API document, typically BSD sockets are the popular
API set, the point is that you may want to simply say "appropriate API's
for the application to read/configure entries"  Just a nitpick since I
haven't seen any other TCP option document even talk about such things..
This comment can be ignored if needed..

- On connectionless resets.
Today, the way implementations work is that when a RST is generated, if
the incoming TCP segment has the TCP MD5 option, then it consults the
database to obtain the key for the the 4 tuple in question. In the case
TCP-AO option with the use of index, you could still obtain this piece
of information and generate the RST. Well, this is a "best effort", but
has been proven to be useful field experience. 

So much so far..

tcpm mailing list