[anonsec] A note about connection latchin.

kent at bbn.com (Stephen Kent) Mon, 10 September 2007 20:29 UTC

From: kent at bbn.com (Stephen Kent)
Date: Mon, 10 Sep 2007 16:29:15 -0400
Subject: [anonsec] A note about connection latchin.
In-Reply-To: <20070910202228.GO27512@Sun.COM>
References: <20070907220757.GL22639@Sun.COM> <p0624051bc30b325c9907@[128.89.89.71]> <20070910202228.GO27512@Sun.COM>
Message-ID: <p06240540c30b5983c630@[128.89.89.71]>

At 3:22 PM -0500 9/10/07, Nicolas Williams wrote:
>On Mon, Sep 10, 2007 at 01:44:32PM -0400, Stephen Kent wrote:
>>  At 5:07 PM -0500 9/7/07, Nicolas Williams wrote:
>>  >a) ULPs interface with IPsec via "template" PAD and SPD entries that get
>>  >   "cloned" upon triggering events.
>>  >
>>  >   For example, a TCP connect() would create a template PAD entry with
>>  >   the connection's 5-tuple as child SA constraints, prior to sending
>>  >   the TCP SYN packet.  A TCP listen() would create a template PAD entry
>>  >   with the listener's 3-tuple as child SA constraints, prior to
>>  >   accepting any TCP SYN packets.
>>
>>  For SPD entries, the applicable term is "populate from packet" and we
>>  have a flag for that.  PAD entries don't have 5-tuples, so did you
>>  mean SPD above? If so, do you want to specify the template PAD entry
>>  separately above?
>
>Although PFP seems appropriate, it's not quite sufficient.  Since my
>post on Friday I've realized just how best to describe connection
>latching as an extension of the IPsec child SA authorization process.
>
>As for what I meant by referenceing 5-tuples and PAD entries, keep in
>mind that I wrote "template PAD entries" -- which in my I-D as it stood
>on Friday (not submitted) referred to something somewhat different from
>PAD entries.  I'm abandoning that terminology; it's not just confusing:
>there's a better way to describe the state that is being created.
>
>Nico
>--

never mind .... :-)

Steve