ipsec September 2009 archive
Main Archive Page > Month Archives  > ipsec archives
ipsec: [IPsec] #22 Simultaneous IKE SA rekey text

[IPsec] #22 Simultaneous IKE SA rekey text

From: Tero Kivinen <kivinen_at_nospam>
Date: Mon Sep 21 2009 - 12:16:46 GMT
To: Paul Hoffman <paul.hoffman@vpnc.org>

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. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec