>Tero states: > The basic case is where both ends notice this is simultaneous > rekey, and can delay moving of the CHILD_SAs until they know which > one wins. The more complex case happens where there is dropped > packets and one end does not detect simultaneous rekey until it has > already finished its rekey and moved CHILD_SAs. As the basic case > can be processed in similar way as the more complex case, this > example here only covers the more complex case. > > In this case host A and B has IKE SA up and running and both ends > decide to rekey it: > > Host A Host B > ----------- ----------- > send req1: ... Ni1 ... --> > <-- send req2: ... Ni2 ... > --> recv req1 > > Now if the req2 is dropped for some reason, the Host A does not > know there is simultaneous rekey, but host B will know it when it > receives the req1. It will process the req1, but it cannot yet move > the CHILD_SAs as it does not know the Nr2. It postpones the > CHILD_SA moving until the req2/resp2 rekey finishes. It sends resp1 > back to the Host A to answer req1 IKE SA rekey: > > <-- send resp1: ... Nr1 ... > recv resp1 <-- > > Now the Host A has finished the IKE SA rekey without knowing it was > simultaneous rekey. It will move the CHILD_SAs from the old IKE SA > to new rekeyed IKE SA A. It MUST NOT immediately delete the old IKE > SA, but instead wait for some time to see in case there was > simultaneous rekey ongoing or not. When Host B retransmits its req2 > the Host A will notice that there was simultaneous rekey going on, > and it will send normal reply to that: > I see no reason why Host A MUST NOT immediately delete the old IKE SA. 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. > 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. > --> recv resp2 Host B should receive the NO_ADDITIONAL_SAS notification and it should realize that Host A did not detect the simultaneous rekey. Host B should now move the child SAs from the original IKE SA to the one initiated by Host A. In reality, it's more likely that Host B has already received Host A's delete notification and will ignore the response. > > 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.
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. > > When Host B receives the resp2 it knows that simultaneous rekey is > finished, and it can check the nonces and move CHILD_SAs from the > original IKE SA to either IKE SA A or B depending which had lowest > nonce. If it was IKE SA A, the host B needs to start timer to > delete IKE SA B. > > Depending who created the winning rekeyed IKE SA decides who is > going to delete the old IKE SA, i.e. the one who created the > winning IKE SA also cleans up the old IKE SA. > > Note, that Host B processing is identical to the basic case where > host notices during processing that there is simultaneous rekey > ongoing. > > In case the Host A didn't wait for long enough before start > deleting old IKE SA there can be case where host B is still trying > to retransmit its req2 in the old IKE SA when it receives the > delete to the old IKE SA. In that case it knows that Host A has NOT > received any of its requests, thus is unaware that there is > simultaneous rekey ongoing, thus it can safely stop retrasnmitting > req2, and allow old IKE SA to be deleted, and move all CHILD_SAs to > the IKE SA A created by Host A. And it can do the same when it immediately gets a delete for the original IKE SA or a NO_ADDITIONAL_SAS notification. If you want to defer the delete of the IKE SA that's fine with me. I just don't want to have to do that. I see no value in doing it, especially given the text above indicate one has to handle the delete case anyway. Dave Wierbowski
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
