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

Stephen Kent <> Mon, 14 January 2008 23:33 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1JEYoX-00066A-7p for; Mon, 14 Jan 2008 18:33:57 -0500
Received: from ([]) by with esmtp (Exim 4.43) id 1JEYoW-0008CB-RL for; Mon, 14 Jan 2008 18:33:57 -0500
Received: from (localhost []) by (8.13.8/8.13.8) with ESMTP id m0ENOOtA019963; Mon, 14 Jan 2008 15:24:24 -0800 (PST)
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id m0ENO2Su019868 for <>; Mon, 14 Jan 2008 15:24:03 -0800 (PST)
Received: from ([] helo=[]) by with esmtp (Exim 4.60) (envelope-from <>) id 1JEYew-0001Jw-3F; Mon, 14 Jan 2008 18:24:02 -0500
Mime-Version: 1.0
Message-Id: <p06240522c3b18a586b3a@[]>
In-Reply-To: <20080114214245.GB4374@Sun.COM>
References: <> <20080110223247.GZ810@Sun.COM> <20080110231609.GD810@Sun.COM> <p0624051ac3b168a58557@[]> <20080114214245.GB4374@Sun.COM>
Date: Mon, 14 Jan 2008 16:57:29 -0500
To: Nicolas Williams <>
From: Stephen Kent <>
X-ISI-4-43-8-MailScanner: Found to be clean
Cc:,, Daniel McDonald <>
Subject: Re: [anonsec] Dan's comments (Re: Connection Latching draft review (draft-ietf-btns-connection-latching-04.txt))
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Discussions of anonymous Internet security." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228

At 3:42 PM -0600 1/14/08, Nicolas Williams wrote:
>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.

since, as I said, the SPD has ALWAYS been defined as persistent, this 
misunderstanding is not attributable to a lack of familiarity with 

>  > 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?

no. I was just noting the most recent (2 years old) text supporting 
the fact that the SPD was not nominally viewed as dynamic.