Subject: [IPsec] Fwd: New Version Notification for draft-nir-ipsecme-cafr-03.txt

From: Yoav Nir <[email-masked]>
Date: Tue, 15 Oct 2013 06:51:02 +0000

Third version of this draft, now including Tero's comments.

Begin forwarded message:

From: <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-nir-ipsecme-cafr-03.txt
Date: October 15, 2013 9:49:06 AM GMT+03:00
To: Yoav Nir <[email-masked]<mailto:[email-masked]>>

A new version of I-D, draft-nir-ipsecme-cafr-03.txt
has been successfully submitted by Yoav Nir and posted to the
IETF repository.

Filename: draft-nir-ipsecme-cafr
Revision: 03
Title: Handing Over Child SAs Following Re-Authentication in IKEv2
Creation date: 2013-10-15
Group: Individual Submission
Number of pages: 7
URL:             http://www.ietf.org/internet-drafts/draft-nir-ipsecme-cafr-03.txt
Status:          http://datatracker.ietf.org/doc/draft-nir-ipsecme-cafr
Htmlized:        http://tools.ietf.org/html/draft-nir-ipsecme-cafr-03
Diff:            http://www.ietf.org/rfcdiff?url2=draft-nir-ipsecme-cafr-03

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.

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<http://tools.ietf.org>.

The IETF Secretariat

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 30 Oct 2013 11:23:08 +0400

Hi Yoav,

> Third version of this draft, now including Tero's comments.

some comments on new version.

First, some stuff seems to be left from previous version, which
supposed that new IKE SPIs are sent in both directions:
 - third bullet in Section 2.2
 - figure 2 in Section 3

Then, there is a related issue with re-authentication.
Your draft says, that re-authentication is done as part of a risk management
policy. Usually it is a security gateway, that enforces such a policy.
The problem is, that with EAP authentication, gateway cannot
initiate re-authentication. The only thing it can do - delete existing
IKE SA in hope, that client will reestablich it anew. And with
this behaviour you draft becomes much less useful.

I think, that it could be solved, if we define new notification,
that could be optionally sent from gateway to client, informing him
that gateway is going to delete IKE SA in some time
interval (indicating that interval in the notification).
If cafr is supported by client and he is willing to use it,
client will start re-authentication before the end of
the interval. If not - gateway will just delete IKE SA
after the interval has ended.

Valery.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 30 Oct 2013 08:11:03 +0000

> - third bullet in Section 2.2

Right. Will fix.

> after the interval has ended.

Good idea!  :-)

http://tools.ietf.org/html/rfc4478

Think I should mention that in the draft?

Yoav

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 30 Oct 2013 14:32:23 +0400

> http://tools.ietf.org/html/rfc4478

Sorry, I completely forgot about this RFC.
Happened funny :-)

> Think I should mention that in the draft?

I think yes. 

BTW, it is only experimental, while your draft's 
intended status is standards track.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 30 Oct 2013 10:59:34 +0000

On Oct 30, 2013, at 12:32 PM, Valery Smyslov <[email-masked]> wrote:

> BTW, it is only experimental, while your draft's intended status is standards track.

At one time I asked Pasi (the security AD at the time) about updating it to PS (there were 3-4 interoperating implementations at the time), and he said that it wasn't worth the trouble because even full standards could reference it - downrefs are allowed.