>Tero Stated: > > 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.
I agree with what you stated here, but I feel you are addressing something that is not limited to a simultaneous rekey of the IKE SA. It deals with any rekey of an IKE SA. In my opinion the text is misplaced and should be in a section that deals with handling of outstanding exchanges when an IKE SA is rekeyed. With that said I'm not sure I agree with how you propose to handle the outstanding exchanges. > 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). This sounds like a good idea, but it's not what 4306 required and is a protocol change. Based on 4306 I think when an informational exchange request is received containing the delete of an IKE_SA that the receiver can conclude that most likely any outstanding request will fail once a response to the delete is sent. The receiver of the delete request has ways to deal with this. It can delay sending a response until it receives responses to all outstanding requests. It can send a response immediately and conclude that all outstanding requests will fail. In that case it can restart the outstanding request on a newer IKE_SA or wait for traffic to require the creation of a new SA. If one of the outstanding requests is for a perceived simultaneous rekey it now knows it was not perceived that way by the peer. In this case it should move the child SAs to the newer IKE SA. Even with your solution an implementation has to be able to handle the case where a perceived simultaneous rekey of the IKE SA fails. > > 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. Correct, sorry I misspoke. We actually send NO_PROPOSAL_CHOSEN, but the same logic still applies. I believe we used to send NO_ADDITIONAL_SAS, but due to previous discussion on the mailing list we switched to NO_PROPOSAL_CHOSEN. > 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. > Agreed, so we have two possible protocol changes if we need to mandate one or we could allow implementations solve the problem as they see fit. I think my solution is consistent with what is stated in Section 5.11.4 of RFC 4718. You are introducing the need to detect a simultaneous rekey after the fact. > 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. We have tested our code using a window size greater than 1. > > 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. As I said earlier I think the ongoing exchange issue should be documented separately from the simultaneous rekey case, although I agree there can be a tie to it if your solution is agreed to. > > 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. I think "SHOULD NOT immediately delete" is still too strong. I think "MAY delay the deletion to allow ongoing exchanges to complete" is more appropriate at this point. Dave Wierbowski
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
