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

Re: [IPsec] #22 Simultaneous IKE SA rekey text

From: David Wierbowski <wierbows_at_nospam>
Date: Tue Sep 22 2009 - 02:52:58 GMT
To: IPsecme WG <ipsec@ietf.org>


>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