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