[anonsec] A note about connection latchin.

Nicolas.Williams at sun.com (Nicolas Williams) Mon, 10 September 2007 20:22 UTC

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 10 Sep 2007 15:22:29 -0500
Subject: [anonsec] A note about connection latchin.
In-Reply-To: <p0624051bc30b325c9907@[128.89.89.71]>
References: <20070907220757.GL22639@Sun.COM> <p0624051bc30b325c9907@[128.89.89.71]>
Message-ID: <20070910202228.GO27512@Sun.COM>

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