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.
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
