I agree with Dave Wierbowsk, deletion will still occur (for the old IKE SA) so deleting it while Host B is retransmitting (or waiting for some timer to retrasmit) seems to make most sense. Host B notices the delete payload (or NO_ADDITIONAL_SAS), stops retransmitting the request and go on as if there was only one rekeying requested (the one requested by Host A). I don't see a reason to delay the deletion.
Regards, Matt 2009/9/22 Matthew Cini Sarreo <mci...@gmail.com> > > I agree with Dave Wierbowsk, deletion will still occur (for the old IKE SA) > so deleting it while Host B is retransmitting (or waiting for some timer to > retrasmit) seems to make most sense. Host B notices the delete payload (or > NO_ADDITIONAL_SAS), stops retransmitting the request and go on as if there > was only one rekeying requested (the one requested by Host A). I don't see a > reason to delay the deletion. > > Regards, > Matt > > 2009/9/22 David Wierbowski <wierb...@us.ibm.com> > >> >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 >> >> >
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
