David Wierbowski writes: > I see no reason why Host A MUST NOT immediately delete the old IKE SA.
Deleting the IKE SA immediately makes it impossible to know what happened to other exchanges going on the same IKE SA. Waiting for 30 seconds or so after rekey would allow those other exchanges to finish before the old IKE SA is deleted. The current IKEv2 document does not specify what happens to the ongoing exchanges when IKE SA is deleted. In normal case that does not matter, as all the IKE SA state goes away when SA is deleted, thus it is simply the case that all exchanges are immediately discarded and all CHILD_SAs on the IKE SA are deleted. This is not the case on the rekey case, as here there might be CREATE_CHILD_SAs and other exchanges ongoing on the IKE SA when it is rekeyed. Now if the IKE SA is deleted immediately without waiting those to finish when rekey finishes the other end does not know what the node deleting the IKE SA did for those exchanges. It might have silently discarded them, or it might have already processed them but their responses were lost because of network error etc. This causes the peers state to get out of sync, which will lead problems and will cause IKE SAs to be deleted completely later. > In fact I think is SHOULD immediately delete the old IKE SA. By this > I mean it should mark the SA as being deleted, it should send a delete > payload, and it should refuse to create any additional SAs. I agree it should mark the SA so that it is no longer used for the new SAs initiated from this end, but the other end might have its own exchanges ongoing when the rekey started, and waiting those to finish makes protocol work better. When both end mark the old SA as being "old", meaning no new exchanges are started on it, but old exchanges are allowed to finished then when those old exchanges are finished, then the old IKE SA should be deleted (and all operations done on the old IKE SA should be moved to the winning SA). > > recv req1 <-- > > send resp2: ... Nr2 ... --> > Host A should respond with NO_ADDITIONAL SAS in this case because > Host A did not detect a simultaneous rekey and should have immediately > deleted the original IKE_SA. NO_ADDITIONAL_SAS is not correct error for this case, as we are talking about IKE SAs not about CHILD_SAs. The NO_ADDITIONAL_SAS description clearly says it is used when no more CHILD_SAs are to be used. Sending some more suitable error could most likely also work, but still the IKE SA cannot be deleted immediately. It can only be deleted when ongoing exchanges have been finished. I have not checked out if your suggested version works with all possible combinations of simulatenous rekeys, but from the first look it seems it might also work. On the other hand there is no text indicating such behavior in the IKEv2 document, so it is protocol change compared to the old text which said that simulatenous rekey is processed by checking out the nonces. The rekeys in this case are simulatenous even when Host A didn't initially detect that. > > After sending that reply that also creates the second IKE SA B in > > Host A and then Host A can check all the four nonces and see which > > of them is lowest, and it will then move all the CHILD_SAs to that > > new IKE SA having lowest nonce unless they were already there (i.e. > > if the IKE SA A had lowest nonce, Host A has already moved the > > CHILD_SAs there, if IKE SA B had lowest nonce, host A needs to move > > CHILD_SAs from the IKE SA A to this IKE SA B, and start timer to > > delete IKE SA A). > Why do you want to mandate all this complication for a case that will > occur infrequently? You are impacting every IKE_SA rekey, not just > the simultaneous case. I doubt that anybody delays the delete of an > IKE_SA on a rekey based on RFC 4306. At the very least I'm sure there > are implementations that do not delay the delete. Requiring this > delay is a protocol change and one that I do not see the need for. We do delay the delete, as we do want to wait for the ongoing exchanges to finish. On the other hand we are almost only one of the implementations who also implement the window size > 1, which means we have cases where might have several CREATE_CHILD_SA exchanges initiated by the host B ongoing when host A decides to do rekey on the IKE SA. That delay does not have anything to do with simultaneous rekey, it is needed to allow the ongoing exchanges to finish before old IKE SA is deleted. On the other hand RFC4306 specifies exactly ONE way to handle simulatenous rekey and that is by checking the nonces. The rekey is simulatenous even when one host didn't immediately detect it as simulatenous because some packet was lost. I agree now that "MUST NOT immediately delete" was too strong, so "SHOULD NOT immediately delete" is better. If implementation does not implement larger window sizes, and is used in environments where there is very limited number of CHILD SAs per IKE SA, so the probability of getting CREATE_CHILD_SA just when other ends decides to rekey is so small, that it does not matter even if the whole IKE SA gets deleted in that case then it can ignore that SHOULD. > If Host A deletes the IKE_SA immediately then either Host B will see > the delete and be able to infer that there is no simultaneous rekey or > Host B may also get a NO_ADDITIONAL SAS notification and be able to > infer that there is no simultaneous rekey. Regardless what host A thinks there was still simultaneous rekey ongoing, and RFC4306 gives only one way to solve that so sending error in that case is against RFC4306. That is also protocol change. If we do protocol change, I would rather make it so we always for example make the original initiator to win in case of simulatenous IKE SA rekey case, and not care about nonces at all... -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
