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

From: Yoav Nir <[email-masked]>
Date: Tue, 13 Aug 2013 20:30:01 +0000

Hi all

For a long time I've felt that re-authentication in IKEv2 has some harsh side effects in both uninterrupted IPsec and in continuation of the internal IP address assignment.

This draft attempts  to solve these issues.

Comments are welcome, and I will be glad if the WG agrees to discuss and adopt this.

Thanks

Yoav

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title           : Adopting Child SAs Following Re-Authentication in IKEv2
> 	Author(s)       : Yoav Nir
> 	Filename        : draft-nir-ipsecme-cafr-00.txt
> 	Pages           : 8
> 	Date            : 2013-08-12
> 
> Abstract:
>   This document describes an extension to the IKEv2 protocol whereby
>   Child SAs are moved to the new IKE SA following re-authentication.
>   This allows for a smoother transition with no loss of connectivity.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-nir-ipsecme-cafr
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-nir-ipsecme-cafr-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 14 Aug 2013 13:52:29 +0400

Hi Yoav,

isn't it better to do Child SAs movement in a separate Informational 
Exchange,
rather than in IKE_AUTH?

Pros:
1. No race conditions
2. No additional complication to already over-complicated IKE_AUTH
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).

Contras:
1. Extra round trip.

Regards,
Valery Smyslov.

> Hi all
>
> For a long time I've felt that re-authentication in IKEv2 has some harsh 
> side effects in both uninterrupted IPsec and in continuation of the 
> internal IP address assignment.
>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 14 Aug 2013 18:07:02 +0400

>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.

>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.

> 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).

---

From: Yoav Nir <[email-masked]>
Date: Wed, 14 Aug 2013 13:24:56 +0000

On Aug 14, 2013, at 12:52 PM, Valery Smyslov <[email-masked]> wrote:

> Hi Yoav,
> 
> isn't it better to do Child SAs movement in a separate Informational Exchange,
> rather than in IKE_AUTH?
> 
> Pros:
> 1. No race conditions

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.

> 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.

>   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.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 14 Aug 2013 21:40:07 +0000

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 <[email-masked]> wrote:

>> 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.
> 
> 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.
> is already in IKEv2, you need only to update conditions to send TEMPORARY_FAILURE
> notification.
> 
>> 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.
> 
>> 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.
> 
> and he answrered that ability to move them is the next step, that is not covered in the current
> Email secured by Check Point