Re: [tcpm] tcp-auth-opt issue: unique connection keys

Eric Rescorla <> Thu, 31 July 2008 00:18 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id E5CAF3A6B68; Wed, 30 Jul 2008 17:18:39 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6CB9F3A6B68 for <>; Wed, 30 Jul 2008 17:18:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.485
X-Spam-Status: No, score=-0.485 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Qc2cSyDraT79 for <>; Wed, 30 Jul 2008 17:18:37 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id 9DF3B3A6B5A for <>; Wed, 30 Jul 2008 17:18:37 -0700 (PDT)
Received: from kilo-2.local (localhost []) by (Postfix) with ESMTP id D6CF54D5E53; Wed, 30 Jul 2008 17:18:09 -0700 (PDT)
Date: Wed, 30 Jul 2008 17:18:09 -0700
From: Eric Rescorla <>
To: Joe Touch <touch@ISI.EDU>
In-Reply-To: <>
References: <>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Message-Id: <>
Subject: Re: [tcpm] tcp-auth-opt issue: unique connection keys
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

At Wed, 30 Jul 2008 15:42:38 -0700,
Joe Touch wrote:
> Hash: SHA1
> Eric has raised the point that we should expect the TCP-AO system
> (TCP-AO and its required key management system [KMS]) to ensure unique
> connection keys.
> draft-01 outlines the information that would be used to provide this
> information (i.e., derivative of the ISN, etc.).
> Eric raised concerns about whether this function can reasonably be
> external to TCP-AO (e.g., inside the KMS) or inside the KMS, and about
> the vagueness of the description. The current document was intended as a
> starting point for that discussion, FWIW.
> One observation is that the KMS manages keys for connections - i.e., the
> socket pair (addr/port pair) - but has no info on ISNs. It can establish
> keys for that socket pair in the TSAD, but cannot generate appropriate
> session keys in advance of a connection being established.
> Let's assume that the KMS includes the socket pair in the connection key
> when it inserts it into the TSAD (or that this can occur trivially for
> wildcard source port entries by re-hashing with the appropriate port
> when the first packet instantiates the entry). As a result, the ISNs are
> the only missing component to the connection key.
> As was suggested before, use ISNs as follow:
> 	SYN (without ACK) - use src_ISN from SYN, dst_ISN=0
> 	all other packets - use src_ISN, dst_ISN from first SYN rec'd
> There are (at least) two ways to achieve this:
> 1) prepend src_ISN, dst_ISN to each incoming packet for MAC calculation
> 2) overwrite the TSAD keys established by the KMS
> 	i.e., on first SYN emitted
> 		key=hash(key, src_ISN)
> 	on SYN-ACK received
> 		key=hash(key, dst_ISN)
> #1 has the advantage that it appears to work for simultaneous open, in
> which the SYNs are keyed based on different ISN info in each direction,
> but are received properly
> #2 reduces the per-packet cost by the length of two ISNs, by investing
> in the hash at connection establishment. However, it appears to prohibit
> simultaneous open. Can anyone suggest a solution that supports
> simultaneous open?

Why does this prohibit simultaneous open? Because you're assuming
that there's only one possible key for a given host/port quartet?


tcpm mailing list