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

Eric Rescorla <ekr@networkresonance.com> Thu, 07 August 2008 18:19 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 [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5036D3A6BF6; Thu, 7 Aug 2008 11:19:48 -0700 (PDT)
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 8E79C3A6C4B for <tcpm@core3.amsl.com>; Thu, 7 Aug 2008 11:19:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.671
X-Spam-Level:
X-Spam-Status: No, score=-0.671 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
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 gJUv9A23813n for <tcpm@core3.amsl.com>; Thu, 7 Aug 2008 11:19:46 -0700 (PDT)
Received: from kilo.rtfm.com (unknown [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 66DDB3A69D4 for <tcpm@ietf.org>; Thu, 7 Aug 2008 11:19:28 -0700 (PDT)
Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 04B5B52A03A; Thu, 7 Aug 2008 11:20:04 -0700 (PDT)
Date: Thu, 07 Aug 2008 11:20:04 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: Joe Touch <touch@ISI.EDU>
In-Reply-To: <489B3B72.8030604@isi.edu>
References: <4890F4BE.6060302@isi.edu> <396556a20807301622l4cb33deuff73cd13d7a75ba1@mail.gmail.com> <4890FBE8.1020203@isi.edu> <396556a20807311700w1eda50b0o5da7ae52e6c1691a@mail.gmail.com> <48935FFD.4090805@isi.edu> <396556a20808051826w1a839577q956f379f56db1165@mail.gmail.com> <20080806020257.D1C69525D8F@kilo.rtfm.com> <396556a20808061742y19f8f5fh78fe66bfe4d415be@mail.gmail.com> <20080807011812.DDC8050846@romeo.rtfm.com> <396556a20808071047q5bda8acbje7a8fc9f9bf2e597@mail.gmail.com> <20080807180512.77604529E4D@kilo.rtfm.com> <489B3B72.8030604@isi.edu>
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: <20080807182005.04B5B52A03A@kilo.rtfm.com>
Cc: Adam Langley <agl@imperialviolet.org>, tcpm@ietf.org
Subject: Re: [tcpm] tcp-auth-opt issue: support for NATs
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

At Thu, 07 Aug 2008 11:14:10 -0700,
Joe Touch wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> Eric Rescorla wrote:
> | At Thu, 7 Aug 2008 10:47:30 -0700,
> | Adam Langley wrote:
> |> On Wed, Aug 6, 2008 at 6:18 PM, Eric Rescorla
> <ekr@networkresonance.com> wrote:
> |>> I'm sorry, I must be missing something. what problem are you trying to
> |>> solve?
> |> The above was an sketch of how a passive open socket would work with
> |> TCP AO such that only clients that knew a master key could connect. If
> |> we wish to support a setup, then wildcard key matching would probably
> |> be needed.
> |
> | 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.

-Ekr
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm