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

Reply via email to