Subject: [IPsec] Large Scale VPN

From: Yoav Nir <[email-masked]>
Date: Thu, 8 Dec 2011 11:55:51 +0200

Hi all.

The discussion has died down a bit, so I thought I'd chime in with proposed charter text. What do people think of the following?  The first paragraph is taken from Steve's email of 18-Nov.

Yoav

In an environment with many IPsec gateways and remote clients that share an established trust infrastructure (in a single administrative domain or across multiple domains), customers want to get on-demand mesh IPsec capability for efficiency. However, this cannot be feasibly accomplished only with today's IPsec and IKE due to problems with address lookup, reachability, policy configuration, etc.

The IPsecME working group will handle this large scale VPN problem by delivering the following:

* The working group will create a problem statement document including use cases, definitions and proper requirements for discovery and updates. This document would be solution-agnostic. Should reach WG last call around October 2012.

* The working group will review and help publish Informational documents describing current vendor proprietary solutions. These should be ready for IETF last call by August 2012.

* The working group will choose a common solution for the discovery and update problems that will satisfy the requirements in the problem statement document. The working group may consider multiple proposals, and then choose one to bring to the standards track.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 8 Dec 2011 08:04:06 -0800

> In an environment with many IPsec gateways and remote clients that share an established trust infrastructure (in a single administrative domain or across multiple domains), customers want to get on…

I don't think "mesh" is a well-defined term here. How about "point-to-point"?

> * The working group will choose a common solution for the discovery and update problems that will satisfy the requirements in the problem statement document. The working group may consider multiple…

We would need a deadline for the last item. I suggest "December 2013".

--Paul Hoffman

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 08 Dec 2011 20:14:32 +0200

We as a group can commit to deliverable #1 and #3 (problem statement and 
standardized solution). But deliverable #2 (vendor protocols) is mostly 
out of our hands. So before we approve this charter, I would like to 
hear from people that represent vendors that they can commit to publish 
such a draft for their favorite solution. With a mostly complete -00 
draft in, say, 4/2012. Please respond to the list or privately to Paul 
and myself.

Also, I suggest to replace the sentence "The working group may consider 
multiple proposals, and then choose one to bring to the standards 
track." by "The working group may standardize one of the vendor 
solutions, a combination of several, or a new protocol." The latter is 
clearer, at least to me.

Thanks,
     Yaron

On 12/08/2011 06:04 PM, Paul Hoffman wrote:
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 8 Dec 2011 10:24:20 -0800

On Dec 8, 2011, at 10:14 AM, Yaron Sheffer wrote:

> We as a group can commit to deliverable #1 and #3 (problem statement and standardized solution). But deliverable #2 (vendor protocols) is mostly out of our hands. So before we approve this charter, I would like to hear from people that represent vendors that they can commit to publish such a draft for their favorite solution. With a mostly complete -00 draft in, say, 4/2012. Please respond to the list or privately to Paul and myself.
> 
> Also, I suggest to replace the sentence "The working group may consider multiple proposals, and then choose one to bring to the standards track." by "The working group may standardize one of the vendor solutions, a combination of several, or a new protocol." The latter is clearer, at least to me.

+1 to both.

--Paul Hoffman

---

From: Yoav Nir <[email-masked]>
Date: Thu, 8 Dec 2011 22:00:56 +0200

> I don't think "mesh" is a well-defined term here. How about "point-to-point"?

point to point sounds to me too much like the old host-to-host IPsec idea that never quite took off. I know this is part of Chris's use case, but I don't think that's our main focus. I can live with either point-to-point or mesh, but either way we'll have to define it in the first deliverable.

> We would need a deadline for the last item. I suggest "December 2013".

Works for me. I was hesitant to suggest a date.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 8 Dec 2011 22:06:31 +0200

On Dec 8, 2011, at 8:14 PM, Yaron Sheffer wrote:

> out of our hands.

That's why I used "review" and "help" rather than "write" or "produce".

> So before we approve this charter, I would like to 

Agree. How about:

In an environment with many IPsec gateways and remote clients that share an established trust infrastructure (in a single administrative domain or across multiple domains), customers want to get on-demand point-to-point IPsec capability for efficiency. However, this cannot be feasibly accomplished only with today's IPsec and IKE due to problems with address lookup, reachability, policy configuration, etc.

* The working group will choose a common solution for the discovery and update problems that will satisfy the requirements in the problem statement document. The working group may standardize one of the vendor solutions, a combination, an superset of such a solution, or a new protocol.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 8 Dec 2011 12:15:16 -0800

On Dec 8, 2011, at 12:00 PM, Yoav Nir wrote:

> point to point sounds to me too much like the old host-to-host IPsec idea that never quite took off.

The points can be (and are likely to be) gateways.

> I know this is part of Chris's use case, but I don't think that's our main focus. I can live with either point-to-point or mesh, but either way we'll have to define it in the first deliverable.

I believe that we need to have a sensible definition for the charter.

Is there a good definition of "mesh VPN" we can add to the proposed charter text? Is there a preference for "point-to-point", maybe with a better definition?

--Paul Hoffman

---

From: Michael Richardson <[email-masked]>
Date: Thu, 08 Dec 2011 15:16:49 -0500

I find the goals and schedule acceptable.

>>>>> "Yoav" == Yoav Nir <[email-masked]> writes:
    Yoav> In an environment with many IPsec gateways and remote clients
    Yoav> that share an established trust infrastructure (in a single
    Yoav> administrative domain or across multiple domains), customers
    Yoav> want to get on-demand mesh IPsec capability for
    Yoav> efficiency. However, this cannot be feasibly accomplished only
    Yoav> with today's IPsec and IKE due to problems with address
    Yoav> lookup, reachability, policy configuration, etc.

    Yoav> The IPsecME working group will handle this large scale VPN
    Yoav> problem by delivering the following:

    Yoav> * The working group will create a problem statement document
    Yoav> including use cases, definitions and proper requirements for
    Yoav> discovery and updates. This document would be
    Yoav> solution-agnostic. Should reach WG last call around October
    Yoav> 2012.

    Yoav> * The working group will review and help publish Informational
    Yoav> documents describing current vendor proprietary
    Yoav> solutions. These should be ready for IETF last call by August
    Yoav> 2012.

    Yoav> * The working group will choose a common solution for the
    Yoav> discovery and update problems that will satisfy the
    Yoav> requirements in the problem statement document. The working
    Yoav> group may consider multiple proposals, and then choose one to
    Yoav> bring to the standards track.
    Yoav> _______________________________________________ IPsec mailing
    Yoav> list [email-masked]
    Yoav> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 08 Dec 2011 22:46:38 +0200

I'm fine with the new text. Again, provided that people come forward 
with a commitment to work on the vendor documents.

Thanks,
Yaron

---

From: Praveen Sathyanarayan <[email-masked]>
Date: Thu, 8 Dec 2011 13:33:26 -0800

I am representing Juniper. Juniper will plan to publish a draft.

Thanks,
Praveen

On 12/8/11 12:46 PM, "Yaron Sheffer" <[email-masked]> wrote:

Thanks,
Yaron

On 12/08/2011 10:06 PM, Yoav Nir wrote:
> In an environment with many IPsec gateways and remote clients that share
>an established trust infrastructure (in a single administrative domain or
>across multiple domains), customers want to get on-demand point-to-point
>IPsec capability for efficiency. However, this cannot be feasibly
>accomplished only with today's IPsec and IKE due to problems with address
>lookup, reachability, policy configuration, etc.
>
> * The working group will create a problem statement document including
>use cases, definitions and proper requirements for discovery and updates.
>This document would be solution-agnostic. Should reach WG last call
>around October 2012.
>
> * The working group will review and help publish Informational documents
>describing current vendor proprietary solutions. These should be ready
>for IETF last call by August 2012.
>
> * The working group will choose a common solution for the discovery and
>update problems that will satisfy the requirements in the problem
>statement document. The working group may standardize one of the vendor
>solutions, a combination, an superset of such a solution, or a new
>protocol.
>

---

From: Yoav Nir <[email-masked]>
Date: Mon, 12 Dec 2011 11:44:32 +0200

Hi all

If we want Paul and Yaron to take this to our AD, we need to show that there are more people who think these work items are a good idea. More people than just me and MCR.  So please show your support (or objections!) soon. An "I think this is a good idea", "I think we should use ternary logic", or "+1" is all it takes.

Yoav

---

From: Stephen Hanna <[email-masked]>
Date: Mon, 12 Dec 2011 10:19:02 -0500

Yes, I definitely think this is a good idea.

Thanks,

Steve

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Yoav Nir
> Sent: Monday, December 12, 2011 4:45 AM
> To: IPsecme WG
> Cc: Paul Hoffman
> Subject: Re: [IPsec] Large Scale VPN
> 
> Hi all
> 
> If we want Paul and Yaron to take this to our AD, we need to show that
> there are more people who think these work items are a good idea. More
> people than just me and MCR.  So please show your support (or
> objections!) soon. An "I think this is a good idea", "I think we should
> use ternary logic", or "+1" is all it takes.
> 
> Yoav
> 
> > In an environment with many IPsec gateways and remote clients that
> share an established trust infrastructure (in a single administrative
> domain or across multiple domains), customers want to get on-demand
> point-to-point IPsec capability for efficiency. However, this cannot be
> feasibly accomplished only with today's IPsec and IKE due to problems
> with address lookup, reachability, policy configuration, etc.
> >
> > * The working group will create a problem statement document
> including use cases, definitions and proper requirements for discovery
> and updates. This document would be solution-agnostic. Should reach WG
> last call around October 2012.
> >
> > * The working group will review and help publish Informational
> documents describing current vendor proprietary solutions. These should
> be ready for IETF last call by August 2012.
> >
> > * The working group will choose a common solution for the discovery
> and update problems that will satisfy the requirements in the problem

---

From: <[email-masked]>
Date: Mon, 12 Dec 2011 10:32:25 -0500

+1, Thanks, --David

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Hanna
> Sent: Monday, December 12, 2011 10:19 AM
> To: Yoav Nir; IPsecme WG
> Cc: Paul Hoffman

---

From: Mark Boltz <[email-masked]>
Date: Mon, 12 Dec 2011 15:50:06 +0000

+1 from me as well. The approach is a good idea, and the WG should proceed as outlined.

Mark

---

From: Suresh Melam <[email-masked]>
Date: Mon, 12 Dec 2011 10:46:37 -0800

+1

thanks,
-suresh

---

From: Michael Ko <[email-masked]>
Date: Mon, 12 Dec 2011 11:35:52 -0800

As I indicated in the side meeting and mailing list discussions, I 
definitely support this going forward.

Mike
----- Original Message ----- 
From: Yoav Nir
To: IPsecme WG
Cc: Paul Hoffman
Sent: Monday, December 12, 2011 1:44 AM
Subject: Re: [IPsec] Large Scale VPN

Hi all

If we want Paul and Yaron to take this to our AD, we need to show that there 
are more people who think these work items are a good idea. More people than 
just me and MCR.  So please show your support (or objections!) soon. An "I 
think this is a good idea", "I think we should use ternary logic", or "+1" 
is all it takes.

Yoav

On Dec 8, 2011, at 10:06 PM, Yoav Nir wrote:
> * The working group will create a problem statement document including use 
> cases, definitions and proper requirements for discovery and updates. This 
> document would be solution-agnostic. Should reach WG last call around 
> October 2012.
>
> describing current vendor proprietary solutions. These should be ready for 
> IETF last call by August 2012.
>

---

From: "Ulliott, Chris" <[email-masked]>
Date: Tue, 13 Dec 2011 09:08:15 +0000

Protective Marking: UNCLASSIFIED

+1, looks good to me!

Chris

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yoav Nir
Sent: Monday, December 12, 2011 9:45 AM
To: IPsecme WG
Cc: Paul Hoffman
Subject: Re: [IPsec] Large Scale VPN

Hi all

Yoav

****************************************************************************
Communications with GCHQ may be monitored and/or recorded 
for system efficiency and other lawful purposes. Any views or 
opinions expressed in this e-mail do not necessarily reflect GCHQ 
policy.  This email, and any attachments, is intended for the 
attention of the addressee(s) only. Its unauthorised use, 
disclosure, storage or copying is not permitted.  If you are not the
intended recipient, please notify [email-masked].  

This information is exempt from disclosure under the Freedom of 
Information Act 2000 and may be subject to exemption under
other UK information legislation. Refer disclosure requests to 
GCHQ on 01242 221491 ext 30306 (non-secure) or email
[email-masked]

****************************************************************************

The original of this email was scanned for viruses by the Government Secure Intranet virus scanning service supplied by Cable&Wireless Worldwide in partnership with MessageLabs. (CCTM Certificate Number 2009/09/0052.) On leaving the GSi this email was certified virus free.
Communications via the GSi may be automatically logged, monitored and/or recorded for legal purposes.

---

From: Addepalli Srini-B22160 <[email-masked]>
Date: Mon, 12 Dec 2011 19:06:33 +0000

+1

Srini

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Suresh Melam
Sent: Monday, December 12, 2011 10:47 AM
To: Mark Boltz
Cc: <[email-masked]>; <[email-masked]> <[email-masked]>; <[email-masked]>
Subject: Re: [IPsec] Large Scale VPN

+1

thanks,
-suresh

On Mon, Dec 12, 2011 at 07:50:06AM -0800, Mark Boltz wrote:
> >>> If we want Paul and Yaron to take this to our AD, we need to show 
> >>> that there are more people who think these work items are a good 
> >>> idea. More people than just me and MCR.  So please show your 
> >>> support (or
> >>> objections!) soon. An "I think this is a good idea", "I think we 
> >>> should use ternary logic", or "+1" is all it takes.
> >>> 
> >>> Yoav
> >>> 
> >>> share an established trust infrastructure (in a single 
> >>> administrative domain or across multiple domains), customers want 
> >>> to get on-demand point-to-point IPsec capability for efficiency. 
> >>> However, this cannot be feasibly accomplished only with today's 
> >>> IPsec and IKE due to problems with address lookup, reachability, policy configuration, etc.
> >>>> 
> >>>> The IPsecME working group will handle this large scale VPN 
> >>>> problem by
> >>> delivering the following:
> >>>> 
> >>> including use cases, definitions and proper requirements for 
> >>> discovery and updates. This document would be solution-agnostic. 
> >>> Should reach WG last call around October 2012.
> >>>> 
> >>> documents describing current vendor proprietary solutions. These 
> >>> should be ready for IETF last call by August 2012.
> >>>> 
> >>> and update problems that will satisfy the requirements in the 
> >>> problem statement document. The working group may standardize one 
> >>> of the vendor solutions, a combination, an superset of such a 
> >>> solution, or a new protocol.
> >>>