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

[Nicolas Williams <[e-mail]>]

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!

Nico
--