Re: [anonsec] Comments on connection latching draft

Nicolas Williams <Nicolas.Williams@sun.com> Sun, 09 December 2007 06:49 UTC

Return-path: <anonsec-bounces@postel.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1Fyb-0000pa-54 for btns-archive-waDah9Oh@lists.ietf.org; Sun, 09 Dec 2007 01:49:21 -0500
Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1Fya-0000qS-OT for btns-archive-waDah9Oh@lists.ietf.org; Sun, 09 Dec 2007 01:49:21 -0500
Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lB96i9CL016551; Sat, 8 Dec 2007 22:44:09 -0800 (PST)
Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lB96hqDd016498 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for <anonsec@postel.org>; Sat, 8 Dec 2007 22:43:53 -0800 (PST)
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lB96hqpJ008294 for <anonsec@postel.org>; Sun, 9 Dec 2007 06:43:52 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lB96hpmI040460 for <anonsec@postel.org>; Sat, 8 Dec 2007 23:43:51 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lB96hpAT011144; Sun, 9 Dec 2007 00:43:51 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lB96hoIF011143; Sun, 9 Dec 2007 00:43:50 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Sun, 9 Dec 2007 00:43:50 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Paul Wouters <paul@xelerance.com>
Message-ID: <20071209064350.GB11013@Sun.COM>
Mail-Followup-To: Paul Wouters <paul@xelerance.com>, Sam Hartman <hartmans-ietf@mit.edu>, anonsec@postel.org
References: <tsld4tjjsw3.fsf@mit.edu> <20071206235738.GA8628@Sun.COM> <Pine.LNX.4.64.0712062348120.11458@newtla.xelerance.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.64.0712062348120.11458@newtla.xelerance.com>
User-Agent: Mutt/1.5.7i
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: nicolas.williams@sun.com
Cc: anonsec@postel.org, Sam Hartman <hartmans-ietf@mit.edu>
Subject: Re: [anonsec] Comments on connection latching draft
X-BeenThere: anonsec@postel.org
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Discussions of anonymous Internet security." <anonsec.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/anonsec>, <mailto:anonsec-request@postel.org?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/anonsec>
List-Post: <mailto:anonsec@postel.org>
List-Help: <mailto:anonsec-request@postel.org?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/anonsec>, <mailto:anonsec-request@postel.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: anonsec-bounces@postel.org
Errors-To: anonsec-bounces@postel.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228

On Thu, Dec 06, 2007 at 11:50:06PM -0500, Paul Wouters wrote:
> On Thu, 6 Dec 2007, Nicolas Williams wrote:
> > > Why must implementations make available nat state?  I'm unconvinced
> > > that is well enough defined to actually be useful.
> >
> > I think this is Michael's requirement.
> 
> I think this might have to do with detecting multiple clients behind
> the same NAT router.

The information is available, therefore requiring that it be made
available seems reasonable.  Making this a recommendation is also
reasonable.

> > >    o  Any IPsec channel created with a given peer while another
> > >       distinct, established IPsec channel exists with the same source
> > >       and destination addresses SHOULD be bound to the same peer.
> > >
> > >
> > > How does this interact with nats?
> >
> > Hmmm, badly :)
> 
> Why not make it souce and destination address plus port?

Did you mean only one port, and if so, the destination port, or both
ports?  (Connection latching already does this for all five elements of
the 5-tuple, so if your answer is "both" then note that that's the whole
point of connection latching :)

_______________________________________________