Subject: [IPsec] Fwd: New Version Notification for draft-mglt-ipsecme-clone-ike-sa-01.txt

From: Daniel Migault <[email-masked]>
Date: Fri, 4 Apr 2014 11:33:18 +0200

Hi,

Here is the last version of our draft on clone IKE_SA. The main goal is to
be handle to handle multiple interfaces. We believe this version -- the
same as the one posted on March 13 -- is closed to the final one as we have
considered previous reviews.

We would like to have your feed backs, so we can move forward with the
draft. The draft is only 7 pages -- excluding the appendix --, so please
consider reviewing it.

URL:http://www.ietf.org/internet-drafts/draft-mglt-ipsecme-clone-ike-sa-01.txt
Htmlized: http://tools.ietf.org/html/draft-mglt-ipsecme-clone-ike-sa-01

BR,
Daniel

---------- Forwarded message ----------
From: Daniel Migault <[email-masked]>
Date: Thu, Mar 13, 2014 at 9:51 AM
Subject: Fwd: New Version Notification for
draft-mglt-ipsecme-clone-ike-sa-01.txt
To: "[email-masked]" <[email-masked]>
Cc: Valery Smyslov <[email-masked]>

Hi,

Please find the new version for the clone IKE SA draft. This version
includes all comments we received. Feel free to let us know if there
are more comments to address.

BR,
Danie

Abstract:
   This document considers a VPN End User setting a VPN with a security
   gateway where at least one of the peer has multiple interfaces.

   With the current IKEv2, the outer IP addresses of the VPN are
   determined by those used by IKEv2 channel.  As a result using
   multiple interfaces requires to set an IKEv2 channel on each
   interface, or on each paths if both the VPN Client and the security
   gateway have multiple interfaces.  Setting multiple IKEv2 channel
   involves multiple authentications which may each require multiple
   round trips and delay the VPN establishment.  In addition multiple
   authentications unnecessarily increase load to the VPN client and the
   authentication infrastructure.

   This document presents the Clone IKE SA extension, where an
   additional IKEv2 channel is derived from an already authenticated
   IKEv2 channel.  The newly created IKEv2 channel is set without the
   IKEv2 authentication exchange.  The newly created IKEv2 channel can
   then be assigned to another interface using MOBIKE.

-------- Original Message --------
Subject: New Version Notification for draft-mglt-ipsecme-clone-ike-sa-01.txt
Date: Thu, 13 Mar 2014 01:43:41 -0700
From: <[email-masked]>
To: Valery Smyslov <[email-masked]>, Valery Smyslov <[email-masked]>,
"Daniel Migault" <[email-masked]>, Daniel Migault
<[email-masked]>

A new version of I-D, draft-mglt-ipsecme-clone-ike-sa-01.txt
has been successfully submitted by Daniel Migault and posted to the
IETF repository.

Name: draft-mglt-ipsecme-clone-ike-sa
Revision: 01
Title: Clone IKE SA Extension
Document date: 2014-03-13
Group: Individual Submission
Pages: 16
URL:
http://www.ietf.org/internet-drafts/draft-mglt-ipsecme-clone-ike-sa-01.txt
Status:
https://datatracker.ietf.org/doc/draft-mglt-ipsecme-clone-ike-sa/
Htmlized:
http://tools.ietf.org/html/draft-mglt-ipsecme-clone-ike-sa-01
Diff:
http://www.ietf.org/rfcdiff?url2=draft-mglt-ipsecme-clone-ike-sa-01

Abstract:
   This document considers a VPN End User setting a VPN with a security
   gateway where at least one of the peer has multiple interfaces.

   With the current IKEv2, the outer IP addresses of the VPN are
   determined by those used by IKEv2 channel.  As a result using
   multiple interfaces requires to set an IKEv2 channel on each
   interface, or on each paths if both the VPN Client and the security
   gateway have multiple interfaces.  Setting multiple IKEv2 channel
   involves multiple authentications which may each require multiple
   round trips and delay the VPN establishment.  In addition multiple
   authentications unnecessarily increase load to the VPN client and the
   authentication infrastructure.

   This document presents the Clone IKE SA extension, where an
   additional IKEv2 channel is derived from an already authenticated
   IKEv2 channel.  The newly created IKEv2 channel is set without the
   IKEv2 authentication exchange.  The newly created IKEv2 channel can
   then be assigned to another interface using MOBIKE.

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.

The IETF Secretariat

--
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58