Subject: [IPsec] Working Group LC: draft-ietf-ipsecme-ipsec-ha-03

From: Yaron Sheffer <[email-masked]>
Date: Sun, 16 May 2010 15:53:58 +0300

This is to begin a 2 week working group last call for 
draft-ietf-ipsecme-ipsec-ha-03 
(http://tools.ietf.org/html/draft-ietf-ipsecme-ipsec-ha-03). The target 
status for this document is Informational.

Please send your comments to the ipsec list by May 30, 2010, as 
follow-ups to this message.

Brief comments of the form: "I have read this draft and it looks fine" 
are also welcome.

Quick heads up: this is a requirements definition draft. Once we have 
determined consensus around it, we would like to move forward with 
solutions. Individual solution drafts are welcome as usual, but we would 
like to establish at some point a design team to hash out a common 
solution document. Let us know by private mail if you're interested.

Thanks,
	Yaron

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 25 May 2010 21:14:28 +0300

With 5 more days to go, this is a quick reminder to review the problem 
statement draft so we can move it along, and get to the juicy protocol 
stuff.

This time around, we will take silence as agreement.

Thanks,
	Yaron

---

From: Jean-Michel Combes <[email-masked]>
Date: Wed, 26 May 2010 15:22:07 +0200

Hi,

please, find my review of this document:

1.  Introduction

   IKEv2, as described in [RFC4306] and [RFC4718], and IPsec, as
   described in [RFC4301] and others, allows deployment of VPNs between
   different sites as well as from VPN clients to protected networks.

<JMC>
Instead of mentioning [RFC4306) and [RFC4718], maybe replace with
[draft-ietf-ipsecme-ikev2bis]?
<JMC>

[snip]

2.  Terminology

[snip]

   "Failover" is the event where a one member takes over some load from
   some other member.  In a hot standby cluster, this hapens when a
   standby memeber becomes active due to a failure of the former active

<JMC>
s/memeber/member
<JMC>

[snip]

3.  The Problem Statement

<JMC>
I didn't see anything about potential collisions (e.g. SPI for a
specific SA on a member of the cluster is already used on another
member) during a failover: is such an issue out of scope?
<JMC>

Thanks in advance for your reply.

Best regards.

JMC.

2010/5/25 Yaron Sheffer <[email-masked]>:
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Yoav Nir <[email-masked]>
Date: Thu, 27 May 2010 10:03:35 +0300

1. I didn't want to make ha-03 dependent on bis, but since bis is now approved, we may as well do it.

2. OK

3. It should be out of scope, because this is internal to the cluster. We are not going to require a peer to accept having two SAs with the same SPIs with the same peer, so it's up to the members to prevent this using their own out-of-scope method. It is possible to mention this and then say that it's out of scope, if people think this is necessary. 

Yoav

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jean-Michel Combes
Sent: Wednesday, May 26, 2010 4:22 PM
To: Yaron Sheffer
Cc: IPsecme WG
Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ipsec-ha-03

Hi,

1.  Introduction

<JMC>

[snip]

2.  Terminology

[snip]

<JMC>
s/memeber/member
<JMC>

[snip]

3.  The Problem Statement

<JMC>

Best regards.

JMC.

Scanned by Check Point Total Security Gateway.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 27 May 2010 11:36:24 +0300

How about the following text?

3.8  Allocation of SPIs
   SPIs for child and IKE SAs MUST be unique with the same peer. However, in
   a cluster, both members may create SAs and assign SPIs to them, so a 
   collision is possible. We believe that peers should not be required to
   accept duplicate SPIs for different SAs, and that this needs to be 
   prevented by the cluster members by some out-of-scope method.

Yoav

-----Original Message-----
<snip/>

3.  The Problem Statement

<JMC>

<snip/>

---

From: Jean-Michel Combes <[email-masked]>
Date: Thu, 27 May 2010 12:31:57 +0200

Hi Yoav,

> 1. I didn't want to make ha-03 dependent on bis, but since bis is now approved, we may as well do it.

OK.

> 3. It should be out of scope, because this is internal to the cluster. We are not going to require a peer to accept having two SAs with the same SPIs with the same peer, so it's up to the members t…

OK.

Thx.

Best regards.

JMC.

---

From: Jean-Michel Combes <[email-masked]>
Date: Thu, 27 May 2010 12:32:59 +0200

Hi again,

>   prevented by the cluster members by some out-of-scope method.

It's fine for me.

Best regards.

JMC.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 27 May 2010 10:18:23 -0400

>    prevented by the cluster members by some out-of-scope method.

The text above seems rather indirect. How about:

3.8  Allocation of SPIs
    The SPI associated with each child SA, and with each IKE SA, MUST be
    unique relative to the peer of the SA.  Thus, in the context of a
    cluster, each cluster member MUST generate SPIs in a fashion that
    avoids collisions (with other cluster members) for these SPI values.
    The means by which cluster members achieve this requirement is a local
    matter, outside the scope of this document.

Steve

---

From: Yoav Nir <[email-masked]>
Date: Thu, 27 May 2010 17:34:00 +0300

Works for me.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Kent
Sent: Thursday, May 27, 2010 5:18 PM
To: Yoav Nir
Cc: IPsecme WG
Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ipsec-ha-03

3.8  Allocation of SPIs

Steve

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 30 May 2010 08:53:23 -0700

At 9:14 PM +0300 5/25/10, Yaron Sheffer wrote:
>With 5 more days to go, this is a quick reminder to review the problem statement draft so we can move it along, and get to the juicy protocol stuff.

So, the WG LC on this document is over today, and I think the authors have heard lots of good input. Let's give them some space to do the -04 (soon, hopefully), and if the changes don't cause any more serious discussion, we can take it to IETF Last Call and then start thinking protocol.

--Paul Hoffman, Director
--VPN Consortium