Re: [anonsec] Dan's comments (Re: Connection Latching draft review (draft-ietf-btns-connection-latching-04.txt))

Nicolas Williams <Nicolas.Williams@sun.com> Mon, 14 January 2008 21:55 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 1JEXHA-0000DU-7K for btns-archive-waDah9Oh@lists.ietf.org; Mon, 14 Jan 2008 16:55:24 -0500
Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEXH9-0006cz-O0 for btns-archive-waDah9Oh@lists.ietf.org; Mon, 14 Jan 2008 16:55:24 -0500
Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0ELhbDd012086; Mon, 14 Jan 2008 13:43:37 -0800 (PST)
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0ELgm4x011853 for <anonsec@postel.org>; Mon, 14 Jan 2008 13:42:49 -0800 (PST)
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m0ELglse008044 for <anonsec@postel.org>; Mon, 14 Jan 2008 21:42:48 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m0ELgl4s062040 for <anonsec@postel.org>; Mon, 14 Jan 2008 14:42:47 -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 m0ELgkse004405; Mon, 14 Jan 2008 15:42:46 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m0ELgk65004404; Mon, 14 Jan 2008 15:42:46 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Mon, 14 Jan 2008 15:42:46 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Stephen Kent <kent@bbn.com>
Message-ID: <20080114214245.GB4374@Sun.COM>
Mail-Followup-To: Stephen Kent <kent@bbn.com>, Black_David@emc.com, anonsec@postel.org, Daniel McDonald <Dan.McDonald@Sun.COM>
References: <8CC6CEAB44F131478D3A7B429ECACD91085EA3@CORPUSMX20A.corp.emc.com> <20080110223247.GZ810@Sun.COM> <20080110231609.GD810@Sun.COM> <p0624051ac3b168a58557@[192.168.0.101]>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <p0624051ac3b168a58557@[192.168.0.101]>
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, Black_David@emc.com, Daniel McDonald <Dan.McDonald@sun.com>
Subject: Re: [anonsec] Dan's comments (Re: Connection Latching draft review (draft-ietf-btns-connection-latching-04.txt))
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: 7d33c50f3756db14428398e2bdedd581

On Mon, Jan 14, 2008 at 04:18:03PM -0500, Stephen Kent wrote:
> Nico & Dan,
> 
> the SPD has always been a persistent database. the newly added PAD 
> also is persistent. It's the SAD that is transient, i.e., need not 

Had I gotten this wrong?  No.  Dan may not be totally up to speed with
RFC4301 terminology, but I wouldn't dismiss what he has to say on
account of that.

> have any entries unless SAs have been created, and those entries 
> vanish when the SAs they represent vanish. The notion of dynamic 
> modification of the SPD is a relatively new concept, not part of the 
> original design, but not ruled out by it. Also note that the 
> de-correlated SPD model introduced in 4301 works very well for a 
> persistent database, but could be costly to maintain if the SPD is 
> frequently updated.

Are you asking that the connection latching I-D address how to perform
dynamic updates of a de-correlated SPD?
_______________________________________________