|Main Archive Page > Month Archives > ipsec archives|
Paul Hoffman writes: > #22 - Add section on simultaneous IKE SA rekey
> There was no discussion. We will bring this up one more time
> because it is important, but if there is not more interest and
> more inclination to review Tero's text, we will write a short
> note in the document that simultaneous IKE SA rekey is an issue
> but nothing else.
I would propose cut & pasting the simultaneous IKE SA rekey issue from the clarifications RFC 4718, and adding some more text: ---------------------------------------------------------------------- X.Y.Z Simultaneous IKE_SA Rekeying
Probably the most complex case occurs when both peers try to rekey the IKE_SA at the same time. Basically, the text in Section 2.8 applies to this case, however, it is important to ensure that the CHILD_SAs are inherited by the right IKE_SA.
After the CREATE_CHILD_SA exchanges, two new IKE_SAs exist between A and B; the one containing the lowest nonce inherits the CHILD_SAs. The old IKE SA is deleted by the node which created the winning IKE SA. The loosing IKE SA is deleted by the node which created it.
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: recv req1 <-- send resp2: ... Nr2 ... --> --> recv resp2
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).
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. -- firstname.lastname@example.org _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec