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. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
