Re: [IPsec] I-D Action: draft-nir-ipsecme-cafr-00.txt

[Yoav Nir <[e-mail]>]

Thinking it over, there is one significant advantage to what you're proposing. Suppose our exchanges are like this:

 1. IKE_INITIAL exchange
 2. IKE_AUTH exchange (for re-authentication)
 3. IKE Informational (for moving the Child SAs)
 4. IKE Informational (for deleting the old IKE SA)

#3 can then be run over the old IKE SA. The notification will have the IKE SPIs of the new IKE SA. And this makes the crypto unnecessary - the Notification could be simple the IKE SPIs, and the only verification necessary is that the authenticated identity is the same. We could even unify #3 and #4 into a single Informational, but it should be the initiator of the new IKE SA that sends it.

I think I like that suggestion.

Yoav
 
On Aug 14, 2013, at 5:07 PM, Valery Smyslov <[e-mail]> wrote:

>>> isn't it better to do Child SAs movement in a separate Informational Exchange,
>>> rather than in IKE_AUTH?
>>> 
>>> Pros:
>>> 1. No race conditions
>> 
>> You would then have three operations that you need to do:
>> a. Re-authenticate - create a new IKE SA
>> b. Move the IPsec SAs
>> c. Delete the old IKE SA
>> 
>> Each of (b) and (c) could be done by any peer, not necessarily the same one that did (a). If we get a DELETE before all the IPsec SAs
>> were transferred, some SAs could be deleted, or worse - they could be deleted on only one peer.
> 
> Well, similar race conditions are already existed in IKEv2 and are covered
> in section 2.25. And I believe, if you properly describe all possible collisions and
> due actions, those situations, when some SAs are transferred and some not etc.
> will not happen. Note, that code to deal with collisions according with 2.25
> is already in IKEv2, you need only to update conditions to send TEMPORARY_FAILURE
> notification.
> 
>>> 2. No additional complication to already over-complicated IKE_AUTH
>> 
>> It adds one more thing for the peers to do during IKE_AUTH, but it doesn't make a difference if the extra thing is within IKE_AUTH or
>> immediately after. If the issue is the length of the packet, I believe we are already solving this.
> 
> No, size is not an issue here. But complexity of processing logic for IKE_AUTH is an issue.
> 
>>> 3. More generic solution, so can be used in other situations,
>>>  for example in case IKA SA is cloned (draft-mglt-ipsecme-keep-old-ike-sa).
>> 
>> Interesting point. That draft does not, in fact, state what happens to the child SAs. Since the old SA is kept, I guess they remain, and when
>> the old IKE SA does eventually get deleted, the child SAs are also deleted. Nor does it help to specify that they move: the new IKE SA
>> might get deleted first.
> 
> I remember the author was asked at the meeting what to do with child SAs,
> and he answrered that ability to move them is the next step, that is not covered in the current
> version of the draft (if I got it right).
> 
> 
> Email secured by Check Point