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
--
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.