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

["Laganier, Julien" <julienl at qualcomm.com>]

Hi Nico,

Nicolas Williams wrote:
> 
> OK, this way the changes are much smaller and localized -- only the
> description of CREATE_CONNECTION_LATCH() changes, to:
> 
>    o  CREATE_CONNECTION_LATCH(5-tuple, [type and quality-of-protection
>       parameters], [peer ID], [local ID]) -> latch handle | error
> 
>          If a) the requested latch does not exist (or exists, but is in
>          the CLOSED state), b) all the latch parameters are provided, or
>          if suitable SAs exist in the SAD from which to derive them, and
>          c) if there are no conflicts with the SPD and SAD, then this
>          creates a connection latch in the ESTABLISHED state.  If the
>          latch parameters are not provided and no suitable SAs exist in
>          the SAD from which to derive those parameters, then the key
>          manager MUST initiate child SAs, and if need be, IKE_SA, from
>          which to derive those parameters.
> 
>          The key manager MAY delay the child SA setup and return
>          immediately after the policy check, knowing that the ULP that
>          requested the latch will subsequently output a packet that
>          will trigger the SA establishment.  Such an implementation may
>          require an additional state in the connection latch state
>          machine, a "LARVAL" state, that is not described herein.
> 
>          If the connection latch ultimately cannot be established,
>          either because of conflicts or because no SAs can be
>          established with the peer at the destination address, then an
>          error is returned to the ULP.  (If the key manager delayed SA
>          establishment, and SA establishment ultimately fails, then the
>          key manager has to inform the ULP, possibly asynchornously.
>          This is one of several details that implementors who use a
>          LARVAL state must take care of.)
> 
> How's that?
> 
> This way the change is small enough that it wouldn't have required WG
> discussion.  I should have thought of this.  Thanks Julien!

Hmm. Better, but somehow I'd rather take the 2 last paragraphs about the "larval" state completely out, because right now it IMHO says either too much or too less. It's not precise enough to tell an implementer who hasn't followed that discussion what to do yet it outlines at alternative to the key manager establishing the SA straight and the ULP latching the connection on the SA.

If you want to keep the "larval" text in, I've did some wordsmithing below that you might want to consider:
 
>          The key manager MAY delay the child SA setup and return
>          immediately after the policy check, knowing that the ULP that
>          requested the latch will subsequently output a packet that
>          will trigger the SA establishment.  Such an implementation may
>          require an additional transient state in the connection latch state
>          machine, a "LARVAL" state, to which the connection is latched pending
>          establishment of the SA. The "LARVAL" state is not described further herein.
> 
>          If the connection latch ultimately cannot be established,
>          either because of conflicts or because no SAs can be
>          established with the peer at the destination address, then an
>          error is returned to the ULP.  (Note that if the key manager delayed SA
>          establishment, and SA establishment ultimately fails, then the
>          key manager has to inform the ULP, possibly asynchronously.
>          This is one of several details that implementers who use a
>          LARVAL state must take care of.)

--julien