Re: [tcpm] tcp-auth-opt issue: support for NATs

Joe Touch <touch@ISI.EDU> Thu, 07 August 2008 18:36 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 9D1C73A69AB; Thu, 7 Aug 2008 11:36:02 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 236E83A69AB for <>; Thu, 7 Aug 2008 11:36:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id m1irX5fxY9f2 for <>; Thu, 7 Aug 2008 11:36:01 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4EFA73A6935 for <>; Thu, 7 Aug 2008 11:36:01 -0700 (PDT)
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id m77IaJws021503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Aug 2008 11:36:21 -0700 (PDT)
Message-ID: <>
Date: Thu, 07 Aug 2008 11:35:38 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20080708)
MIME-Version: 1.0
To: Eric Rescorla <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.95.6
X-ISI-4-43-8-MailScanner: Found to be clean
Cc: Adam Langley <>,
Subject: Re: [tcpm] tcp-auth-opt issue: support for NATs
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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"

Hash: SHA1

Eric Rescorla wrote:
|> | Because the side doing the passive open doesn't know which client
|> | is connecting and it may have multiple instances of the same key-id?
|> | I don't understand the purpose of the time. Just do trial verifications
|> | with each key.
|> That's a reason we have a keyID, which, together with the socket pair,
|> should exactly specify what key to use and avoids this sort of trial. If
|> we can live with trials, we can remove the keyID and things align much
|> better.
| Yes, but this only works if you either (1) know the address of
| peers in advance or (2) never assign the same key-id to two
| different peers.

<indiv hat on>

If we require the socket pair, then the keyID need be unique only within
a connection, and we should never need to test different keys -- even
with key rollover, the key used should be deterministic.

Supporting NATs can be done in two different ways:

1. require the KMS to determine the socket pair as received, and
calculate the hash based on the as-received values

	this does not require testing different keys, but puts
	additional burden on the KMS

2. require a mode where the socket pair is not included in the MAC

	this will require testing different keys,
	it also requires the KMS install keys in certain ways
	(i.e., wildcarded on source port and dest IP addr, at least)

I have not yet seen a reason to support secure transport connections for
NAT'd devices made on this list. If there isn't, perhaps it'd be
preferable to leave the protocol simpler and just not support NAT mode.

Alternately, perhaps we could note that there could be modes where
certain header fields are excluded, but that this would be described in
a separeate extension - i.e., not in this doc.

Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -

tcpm mailing list