Re: [btns] Minor connection-latch problem in AUTH48

["Laganier, Julien" <[e-mail]>]

Nicolas Williams wrote
> 
> On Fri, Oct 16, 2009 at 12:48:16PM -0700, Laganier, Julien wrote:
> > I understand your proposal below tries to removes some sort of
> > chicken-and-egg problem with the ULP creating the latch before
> sending
> > a packet, the latch creation triggering key management to create an
> SA
> > if there's none, and the packet being sent triggering the key
> > management.
> 
> Actually, I was just trying to resolve a three-way conflict in the
> text.  As a secondary goal I thought it would be a good idea to not
> REQUIRE that the key manager initiate IKE/child SAs just because a ULP
> is expected soon to send a packet that will require child SAs.  I think
> that should be at least a MAY, and at most a SHOULD.
> 
> Perhaps the WG would say that we should REQUIRE that the key manager
> initiate IKE/child SAs ahead of any triggering packet as a
> simplification of the model (then we don't need a LARVAL state).  But I
> could certainly see implementors not wanting to do that (for one it
> makes the CREATE_CONNECTION_LATCH() call slow).

I think this is the external behavior that we want to capture. The specifics of how a given implementation achieves that need not to be specified in the RFC as long as the conceptual behavior is clear and guarantees interoperability.

Both style of implementation would conform to that behavior, whether or not the triggering occurs directly as a result of latch creation, or indirectly via triggering by the first packet.
 
> An alternative would be to say "must" instead of "MUST" and then
> explain that if the key manager does not initiate IKE/child SAs as part of the
> CREATE_CONNECTION_LATCH() call, then it must have a LARVAL state that
> we have not defined.

FWIW - from my perspective there's no difference between "must" and "MUST", RFC 2119 says about key word that "These words are often capitalized", but does not make it a must.

> You can see why I think this is a minor problem, but also why it'd be
> better to address it.
> 
> > I'd like to make sure I understand the issue and your proposal, and
> in
> > particular why we can't have the latch DB triggering directly the key
> > manager: The existing text you have quoted below says "... if there
> > exist no child SAs that match the given 5-tuple, and if local policy
> > permits it", which implies that the 5-tuple is matched against the
> > SPD. Couldn't this action trigger the key manager to establish a
> > child SA without having to be triggered by an actual packet?
> 
> Indeed.  We don't absolutely need the LARVAL state.  Perhaps we should
> describe it as an OPTIONAL state, since an implementation might not
> have such a state at all.

I tend to think that we do not need the state at all. It is a valid implementation strategy, but it does not need to be captured in the standard since there are as-valid alternatives (e.g., Latch Manager triggers key Management directly)_

--julien