Re: [IPsec] Another round of IKEv2-bis issues

[David Wierbowski <[e-mail]>]

>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.

What is wrong with using a valid child SA?  If you are claiming
the child SA is not valid because it's IKE SA on host A no longer
exists then I'll agree.  When host A lost the IKE SA because the
security processor failed it should have cleaned up any SAs created
by the IKE SA.  That does not mean all SAs created by the IKE SA need
be on the same security processor.  That's just your rule and how you
decided to handle the situation.  You could have kept knowledge of
this relationship outside of the security processor.  I see no reason
to dictate how to handle this situation in the RFC.

>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.

Well if host A did not properly cleanup up all child SAs I agree this
could happen, but so what?  Everyone is happy.  Data is being
exchanged as per the child SA.  If host A did kill the child SA then
dead peer detection would kick in as desired.

It's probably more of an issue if the security processor
containing a child SA died while the IKE SA was
in another security processor, but I contend that in this scenario an
implementation could be smart enough to know what child SAs are
associated with each security processor and properly clean up.  In
this case it would even be able to send a delete.

>
>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.

It's all a matter of bookkeeping.  If they can fail separately you just
need to keep track of what needs to be cleaned up when a failure occurs.
The method you suggest is perhaps a good one and the easiest, but
it is not the only one.

>
>> So I propose we remove it entirely.
>

I'm fine with removing it.

>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.

I do not agree.  The rule is simple.  If an IKE fails cleanup all Child
SAs created by it.  In the case of a security processor failure you are
guaranteed to have that happen if you keep the child SA on the same
security processor, but that does not means that is the only way to
do that.  You have some distribution logic in place to begin with.  That
logic can save enough state to perform the proper cleanup.  I see no
reason to address how this cleanup occurs in this RFC.

--
[e-mail]
_______________________________________________
IPsec mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ipsec


Dave Wierbowski