Yoav Nir writes:
> Issue #181 - Section 2.4 unclear on Child SA failing
> ====================================================
> Section 2.4 says "If Child SAs can fail independently from one
> another without the associated IKE SA being able to send a delete
> message, then they MUST be negotiated by separate IKE SAs". It is
> not clear what this means. Does it apply to implementations? If so,
> how can an implementation know whether or not the first clause is
> true?  
> 
> I propose removing the sentence, or greatly clarifying it.
> 
> Tero and Dave commented. Dave proposed alternative text, replacing
> "they" with "each set of Child SAs": 
> 
> If sets of Child SAs can fail independently from one another without
> the associated IKE SA being able to send a delete message, then each
> set of Child SAs MUST be negotiated by separate IKE SAs. 
> 
> But I think this misses Sean's point, that while an implementation
> might be able to know whether child SAs fail independently in
> itself, it has no way of knowing this about the peer.

Why should it know it about the peer? If the other end used same IKE
SA to negotiate the Child SAs, then those Child SAs cannot fail
independently.

This case is only for the local implementors, it does not have any
protocol implications, except that other end can assume that if Child
SA A, and Child SA B are negotiated using same IKE SA C, then if A
works, that means that B also works (or the Child SA is deleted using
IKE SA C).

The current text does not say anything what happens if the host Z
tries to create Child SA A and Child SA B using IKE SA C, and host X
notices that it cannot guarantee, that they cannot fail independently.
Most likely host X will then return error, but most likely it can also
make Child SA A and B so that they cannot fail independently, i.e.
allocate them from the same security processor.

I.e. if we make example where we have host A, having multiple security
processors F, G, and H. Each of those security processors is able to
run full IPsec, including multiple IKE SAs and Child SAs. Each of
those security processors is separate, i.e. SAs are not shared between
them, thus each IKE SA and Child SA is on only one of them. Also in
this example we assume that one of those security processors can fail
independently from others, i.e. even if one of them crashes, or looses
state, the others can stay up. The device itself will then of course
need some kind of internal "switch" inside, which will "route" IKE and
Child SA packets to corresponding security processor.

Now when host A is initiating negotiations it needs to make sure that
the Child SAs and the corrseponding IKE SA are on the same security
processor so if one of them fail, then all of them fail.

If this is not true, then host B reciving packets from host A using
child SA which happened to be on the other security processor than the
IKE SA of that child SA, still thinks the host A is up and running,
even when the IKE SA is already dead. This means that host B will
never start DPD, as it is seeing valid packets from host A coming in,
thus it will never notice that other Child SAs and the IKE SA on the
other security processor are dead, and will happily send data to them
without trying to recover.

As the crash recovery is done on the IKE SA bases, and the crash
recovery assumes that if any of the Child SAs on the IKE SA is alive,
then the IKE SA is also alive, it is important that Child SAs and IKE
SA cannot fail independently. 

> So I propose we remove it entirely.

I do not agree on that. In most cases this is implementation hint that
is not needed, as most environments do not have multiple independent
security processors, but on those environments where we have those, it
is important for correct behavior that implementors implement this
correctly. Those who are really working on implementations on systems
which have multiple independent security processors should understand
what is said in the current text. As those people who do work on such
implementaions is extremely small, I do not think there is need to
add lots of material explaining the situation (as I did here in this
email), but keeping the text in the specification is still needed.
-- 
kivinen@iki.fi