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: Matthew Cini Sarreo <mcins1_at_nospam>
Date: Tue Sep 22 2009 - 06:26:42 GMT
To: ipsec@ietf.org


I agree with Dave Wierbowsk, deletion will still occur (for the old IKE SA) so deleting it while Host B is retransmitting (or waiting for some timer to retrasmit) seems to make most sense. Host B notices the delete payload (or NO_ADDITIONAL_SAS), stops retransmitting the request and go on as if there was only one rekeying requested (the one requested by Host A). I don't see a reason to delay the deletion.

Regards,
Matt

2009/9/22 Matthew Cini Sarreo <mcins1@gmail.com>

>
> I agree with Dave Wierbowsk, deletion will still occur (for the old IKE SA)
> so deleting it while Host B is retransmitting (or waiting for some timer to
> retrasmit) seems to make most sense. Host B notices the delete payload (or
> NO_ADDITIONAL_SAS), stops retransmitting the request and go on as if there
> was only one rekeying requested (the one requested by Host A). I don't see a
> reason to delay the deletion.
>
> Regards,
> Matt
>
> 2009/9/22 David Wierbowski <wierbows@us.ibm.com>
>
>> >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
>>
>>
>



IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec