Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01

"Anantha Ramaiah (ananth)" <> Tue, 29 July 2008 12:47 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 82F1B28C23D; Tue, 29 Jul 2008 05:47:36 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 750853A6B5A for <>; Tue, 29 Jul 2008 05:47:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8Cm1mmYHa8Ll for <>; Tue, 29 Jul 2008 05:47:28 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EB21128C266 for <>; Tue, 29 Jul 2008 05:47:27 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.31,272,1215388800"; d="scan'208";a="58886982"
Received: from ([]) by with ESMTP; 29 Jul 2008 12:47:40 +0000
Received: from ( []) by (8.12.11/8.12.11) with ESMTP id m6TClddo009038; Tue, 29 Jul 2008 05:47:39 -0700
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id m6TClelV003596; Tue, 29 Jul 2008 12:47:40 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jul 2008 05:47:39 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 29 Jul 2008 05:46:17 -0700
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01
Thread-Index: Acjw3NEVCYBgMOiRTJKL+z2goucxXgAmX6+A
References: <><> <><> <><><><> <> <>
From: "Anantha Ramaiah (ananth)" <>
To: Adam Langley <>, Joe Touch <>
X-OriginalArrivalTime: 29 Jul 2008 12:47:39.0690 (UTC) FILETIME=[48ED30A0:01C8F179]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3240; t=1217335660; x=1218199660; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;;; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20<ananth@cisco .com> |Subject:=20RE=3A=20[tcpm]=20Review=20of=20draft-ietf-tcpm- tcp-auth-opt-01 |Sender:=20; bh=Qa57ACF/kcEkgQyPbStFeeDYG/qVMRmla2xAaIcptfk=; b=e0N0JjNyXWRoz4PdTrwE5mA173YRs/RfZbszyIXgvHYi4O+gwAfZAGD+gM yC0dQshxTnfu8Gv+mT3xOz7hdLwSAcxSUg+cA0fXG8v8EgZpzGfvJxaymP9D 78VQnyCnQd;
Authentication-Results: sj-dkim-4;; dkim=pass ( sig from verified; );
Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

   The extended feeling which I get after watching some of the
conversation is that we seem to be in a cherry picking mode of what to
include/exclude in the digest (MAC) computation. (psuedo header, TCP
options etc.,)

So, if we are going down that route, then I would argue it may be
worthwhile to debate "how much" to include in general, i.e, is it
worthwhile to include selective portions OR part of the data portion of
the TCP data in the MAC computation instead of he entire data.?
Rationale and reasoning follows :-

- performance sensitive applications (in cases there are no hardware
assists for computing the crypto)
- the very reason of NAT (which you mnetion), yes, I am talking about
NAT ALG's which can muck around the data portion of the payload.

My point is that it boils down to how much flexibility one wants to
provide with the TCP AO. 


> -----Original Message-----
> From: [] On 
> Behalf Of Adam Langley
> Sent: Monday, July 28, 2008 11:07 AM
> To: Joe Touch
> Cc:
> Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01
> Some points from the discussion:
> Regarding NATs:
> Your reasoning, as I understood it, for not including an 
> option to exclude the pseudoheader and port numbers for NAT 
> traversal was that the host needs these items to lookup the 
> correct key anyway.
> There are several situation where this is not the case. (I'll 
> point out that I see TCP-AO as being useful outside the 
> domain of securing BGP sessions between backbone routers)
> 1) A host installs a key on a listening socket with a 
> wildcard address. Thus, one can only connect to the socket if 
> you know the key.
> The key probably rotates based on time. This is currently, 
> usually done based on "port knocking" - which has always 
> struck me as a messy solution. The resulting, ESTABLISHED 
> connection knows the port numbers and IP addresses without 
> having to establish it before hand.
> 2) An unauthenticated connection is established and the 
> userland code wishes to upgrade to TCP-AO. Again, since the 
> connection is established the keyset to use are implicit. I 
> didn't know that the NONE mac was designed for upgrading like 
> this. In my Linux patches there's a TCP_AUTH_LATCH option 
> which means "accept unsigned packets until the first signed 
> packet, then require signatures".
> In both of these cases, excluding port numbers and/or 
> pesudoheaders is needed given the deployment of NAT boxes 
> which change these headers.
> Keyids:
> I agree that keeping the cryptography in the MAC is a good thing.
> There is an implementation issue about the number of keys 
> that a kernel may have to store (80ish bytes per key * 256 
> keys * number of configured hosts), but that's not a spec problem.
> --
> Adam Langley 
> _______________________________________________
> tcpm mailing list
tcpm mailing list