Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED

From: Mike Sullenberger <[email-masked]>
Date: Mon, 12 Mar 2012 14:56:56 -0800 (PST)

Steve,

I do not think changing the name to "Dynamic Mesh VPN" is a good idea.
The first thing that is going to happen is that it is going to be 
shortened to "DMVPN" and then we have conflict with Cisco DMVPN, which
would be confusing and also "DMVPN" is a registered trademark.  It
would be best to use some other synonym for "Dynamic Mesh".

Mike.

>Upon reflection, I can see how "Point to Point VPNs" is problematic
>as a description of the problem. Really it's more about dynamically
>creating SAs so that any endpoint or gateway can communicate directly
>with any other, as permitted by policy. And how can we do this in a
>manageable manner in a large-scale environment where endpoints are
>mobile and configurations and policies change often?
>
>So "Dynamic Mesh VPNs" is fine with me. Whatever the WG feels is best.
>
>Thanks,
>
>Steve
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf
>> Of Ulliott, Chris
>> Sent: Wednesday, March 07, 2012 4:53 PM
>> To: [email-masked]'
>> Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED
>> 
>> Classification:UNCLASSIFIED
>> 
>> How about "dynamic mesh VPNs" as a title as I think the dynamic part is
>> key here and probably an important aspect of the use cases.
>> 
>> Chris
>> 
>> [This message has been sent by a mobile device]
>> 
>> ----- Original Message -----
>> From: Yaron Sheffer [mailto:[email-masked]]
>> Sent: Wednesday, March 07, 2012 09:17 PM
>> To: IPsecme WG <[email-masked]>
>> Subject: [IPsec] P2P VPN draft
>> 
>> Hi Steve,
>> 
>> a few initial comments.
>> 
>>   * The draft is short and clear. Thanks for that!
>>   * I have a problem with the title (and even more, with the "file
>>     name" of the draft). P2P is usually perceived as peer-to-peer,
>>     which skews the discussion towards one particular use case, that
>>     of endpoint-to-endpoint. I suggest to use "Mesh IPsec VPN" instead.
>>   * I am unclear about 2.2: so what if you "suddenly need to exchange a
>>     lot of data". How is it different from normal IP traffic load
>>     management? The text is simply too vague here. Ideally, should we
>>     expect the traffic to migrate to other gateways? To go directly
>>     between endpoints? To establish priorities on existing gateways?
>> 
>> Thanks,
>> 
>>      Yaron

+------------------------------------------------+
| Mike Sullenberger; DSE                         |
| [email-masked]                .:|:.:|:.         |
| Customer Advocacy              CISCO           |
+------------------------------------------------+

---

From: "Ulliott, Chris" <[email-masked]>
Date: Mon, 12 Mar 2012 23:16:02 +0000

Good catch! 

I've also thought of an additional use case, as I extend / change a network within a data centre etc, it would be helpful if the crypto gateway could learn of the new networks (through routing perhaps) and make them available through the encrypted tunnels.

Chris

----- Original Message -----
From: Mike Sullenberger [mailto:[email-masked]]
Sent: Monday, March 12, 2012 10:56 PM
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>; Ulliott, Chris
Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED

Steve,

Mike.

****************************************************************************
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: Stephen Hanna <[email-masked]>
Date: Mon, 12 Mar 2012 20:22:00 -0400

Of course, you're right. The acronym DMVPN makes this
a very bad choice. Thanks for pointing that out.

I'll throw out a few ideas here:

Dynamic Direct VPN (DDVPN)
Shortcut VPN (SVPN)
Dynamic Scalable VPN (DSVPN)
Dynamic Efficient VPN (DEVPN)

Other ideas or comments on these are most welcome.

Thanks,

Steve

> From: Mike Sullenberger [mailto:[email-masked]]
> Sent: Monday, March 12, 2012 6:57 PM
> To: Stephen Hanna
> Cc: [email-masked]; [email-masked]

---

From: Stephen Hanna <[email-masked]>
Date: Mon, 12 Mar 2012 20:28:03 -0400

On Chris' new use case, I don't think that's a new use case.
I think it's a requirement that spans all the use cases. The
solution must be able to handle network topology changes.
But we're not into requirements yet. Use cases first.

Thanks,

Steve

> From: Ulliott, Chris [mailto:[email-masked]]
> Sent: Monday, March 12, 2012 7:16 PM
> To: [email-masked]'; Stephen Hanna
> Cc: [email-masked]'
> I've also thought of an additional use case, as I extend / change a
> network within a data centre etc, it would be helpful if the crypto
> gateway could learn of the new networks (through routing perhaps) and
> make them available through the encrypted tunnels.
> 
> Chris
> 
> 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.

---

From: "Hu, Jun (Jun)" <[email-masked]>
Date: Tue, 13 Mar 2012 13:13:08 -0500

How about Dynamic Secure VPN(DSVPN)  or Dynamic Secure Mesh VPN(DSMVPN)? 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Hanna
Sent: Monday, March 12, 2012 5:22 PM
To: Mike Sullenberger
Cc: [email-masked]; [email-masked]
Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED

Of course, you're right. The acronym DMVPN makes this a very bad choice. Thanks for pointing that out.

Thanks,

Steve

> >> How about "dynamic mesh VPNs" as a title as I think the dynamic 
> >> part
> is
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Praveen Sathyanarayan <[email-masked]>
Date: Tue, 13 Mar 2012 13:24:04 -0700

Few of my suggestions here

1.) Cut through VPN
2.) Auto mesh VPN

Thanks,
Praveen

On 3/12/12 5:22 PM, "Stephen Hanna" <[email-masked]> wrote:

Thanks,

Steve

---

From: Mark Boltz <[email-masked]>
Date: Tue, 13 Mar 2012 22:05:15 +0000

I like Juniper's suggestion of "auto mesh VPNs", although other options may be available. I think that dynamic is a good word, but I'd rather anything that can distill to an acronym that would be too ambiguous with DMVPN. Or any other term currently used for proprietary vendor alternatives.

The goal here is to create a vendor-agnostic standards-based solution, right? :-)

--
Mark Boltz, CISSP, CISA, NSA-IEM, CSGI
Director, Federal and Mid-Atlantic
cell: 571.246.2233 office: 202.434.8963 toll free: 866.869.4075
e-mail: [email-masked]<mailto:[email-masked]> fax: 202.318.2333
e-mail: [email-masked]<mailto:[email-masked]>
<http://www.stonesoft.com/>
<http://www.stonesoft.com/><http://www.stonesoft.com/><http://www.stonesoft.com/>
<http://www.stonesoft.com/>

Stonesoft Inc.<http://www.stonesoft.com/us/>
1200 G St. NW, Suite 800
Washington, DC 20005-6705

<http://twitter.com/#!/Stonesoft_US><http://twitter.com/#!/Stonesoft_US><http://twitter.com/#!/Stonesoft_US><http://www.linkedin.com/company/7438><http://www.linkedin.com/company/7438><http://www.linkedin.com/company/7438><http://www.youtube.com/user/stonesoftcorp><http://www.facebook.com/pages/Stonesoft/45937171955><http://www.facebook.com/pages/Stonesoft/45937171955><http://www.facebook.com/pages/Stonesoft/45937171955>
Stonesoft: Network Security. Simplified.<http://www.stonesoft.com/>

On Mar 13, 2012, at 2:13 PM, Hu, Jun (Jun) wrote:

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Stephen Hanna
Sent: Monday, March 12, 2012 5:22 PM
To: Mike Sullenberger
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED

Thanks,

Steve

-----Original Message-----
From: Mike Sullenberger [mailto:[email-masked]]
Sent: Monday, March 12, 2012 6:57 PM
To: Stephen Hanna
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED

Steve,

Mike.

Thanks,

Steve

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On
Behalf
Of Ulliott, Chris
Sent: Wednesday, March 07, 2012 4:53 PM
To: [email-masked]<mailto:[email-masked]>'
Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED

Chris

----- Original Message -----
From: Yaron Sheffer [mailto:[email-masked]]
Sent: Wednesday, March 07, 2012 09:17 PM
To: IPsecme WG <[email-masked]<mailto:[email-masked]>>
Subject: [IPsec] P2P VPN draft

Hi Steve,

a few initial comments.

 * The draft is short and clear. Thanks for that!
 * I have a problem with the title (and even more, with the "file
   name" of the draft). P2P is usually perceived as peer-to-peer,
   which skews the discussion towards one particular use case, that
   of endpoint-to-endpoint. I suggest to use "Mesh IPsec VPN"
instead.
 * I am unclear about 2.2: so what if you "suddenly need to
exchange a
   lot of data". How is it different from normal IP traffic load
   management? The text is simply too vague here. Ideally, should
we
   expect the traffic to migrate to other gateways? To go directly
   between endpoints? To establish priorities on existing gateways?

Thanks,

    Yaron

+------------------------------------------------+
| Mike Sullenberger; DSE                         |
| [email-masked]<mailto:[email-masked]>                .:|:.:|:.         |
| Customer Advocacy              CISCO           |
+------------------------------------------------+
_______________________________________________
IPsec mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Wed, 14 Mar 2012 00:48:02 +0200

> I like Juniper's suggestion of "auto mesh VPNs", although other options may be available. I think that dynamic is a good word, but I'd rather anything that can distill to an acronym that would be t…

Yes, I like Praveen's suggestion too.

> The goal here is to create a vendor-agnostic standards-based solution, right? :-)

Well, we make the standards, so anything we make will be standards-based, no? I'm also not sure what vendor-agnostic means here. As long as everyone can implement it, it doesn't matter how close it is to some vendor's implementation. What I would not like to see is something that makes requirements that not all vendors can meet, such as the ability to dynamically set up virtual interfaces, which is something not all platforms and operating systems provide.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 13 Mar 2012 19:18:51 -0400 (EDT)

> Few of my suggestions here

Coming from FreeS/WAN and Openswan, I'm tempted to call it OEVPN,
where OE stands for Opportunistc Encryption.

Paul (still need to read and comment)

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 14 Mar 2012 09:14:16 +0200

Hi Paul,

the way I read it this is NOT Opportunistic Encryption. The draft makes 
it clear very early on that "Establishing communications between 
participants with no established trust relationship is out of scope for 
this effort."

Thanks,
	Yaron

---

From: Michael Richardson <[email-masked]>
Date: Wed, 14 Mar 2012 11:48:58 -0400

>>>>> "Paul" == Paul Wouters <[email-masked]> writes:
    >> 1.) Cut through VPN 2.) Auto mesh VPN

    Paul> Coming from FreeS/WAN and Openswan, I'm tempted to call it
    Paul> OEVPN, where OE stands for Opportunistc Encryption.

It's not Opportunistic.
It's configured, it's just on-demand.  In Openswan terminology that
would mean a "routed" policy with a DNS lookup.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 14 Mar 2012 14:20:37 -0400 (EDT)

> would mean a "routed" policy with a DNS lookup.

Guess that's what I get for not fully reading the doument yet. I assumed
"P2P" actually meant "peer to peer" which kinda assumes unknown peers
and on the fly configuration.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 14 Mar 2012 12:20:13 -0700

On Mar 14, 2012, at 11:20 AM, Paul Wouters wrote:

> Guess that's what I get for not fully reading the doument yet.

A note to everyone: reading the document sooner rather than later will help make our hour in Paris much more useful.

> I assumed

The term "peer" means no such thing. It means "two parties who communicate without there being a client-server relationship". There are numerous other IETF protocols that use "peer" in this context.

--Paul Hoffman

---

From: yogendra pal <[email-masked]>
Date: Mon, 19 Mar 2012 11:48:51 +0530

Hi All,

After going the draft version, I have suggestion to name this as: "Remote
unknown mesh VPN", shortform: (RUK-MVPN)

Thought behind this name (since Gateway can be configured with its local
and let remote be unknown or 0.0.0.0 (wildcard), this will lead to large
number of endpoints to connect to this Gateway)

Thanks and Regards,
Yogendra Pal
Ericsson, India
+91-9686202644

On Thu, Mar 15, 2012 at 12:50 AM, Paul Hoffman <[email-masked]>wrote:

> A note to everyone: reading the document sooner rather than later will
> help make our hour in Paris much more useful.
>
> > I assumed
> The term "peer" means no such thing. It means "two parties who communicate
> without there being a client-server relationship". There are numerous other
> IETF protocols that use "peer" in this context.
>
> --Paul Hoffman
>

---

From: Yoav Nir <[email-masked]>
Date: Mon, 19 Mar 2012 09:57:16 +0200

As Tero pointed out, some of the use cases don't end up in a full mesh, because sometimes administrators really want a trunk, so the end result could be a mesh among nodes in the same organization, and a trunk to another. Maybe even a partial mesh (with "secondary nodes" behind particularly bad NAT devices connecting to one of many "primary nodes")

So perhaps the name should not include the word "mesh". How about "dynamic discovery VPN" (DD-VPN)?

---

From: Michael Richardson <[email-masked]>
Date: Mon, 19 Mar 2012 10:36:08 -0400

>>>>> "Yoav" == Yoav Nir <[email-masked]> writes:
    Yoav> As Tero pointed out, some of the use cases don't end up in a
    Yoav> full mesh, because sometimes administrators really want a
    Yoav> trunk, so the end result could be a mesh among nodes in the
    Yoav> same organization, and a trunk to another. Maybe even a
    Yoav> partial mesh (with "secondary nodes" behind particularly bad
    Yoav> NAT devices connecting to one of many "primary nodes")

I agree.

    Yoav> So perhaps the name should not include the word "mesh". How
    Yoav> about "dynamic discovery VPN" (DD-VPN)?

I offer:
  On-Demand Dynamic VPN  = ODD-VPN.

---

From: Mark Boltz <[email-masked]>
Date: Mon, 19 Mar 2012 18:12:04 +0000

I agree that the meshing becomes messy. And thus, Yoav's comment on partial mesh and such is valid.

Since the topology is, in my view, based on the use cases and the problem statement as I have understood them, a somewhat nebulous thing, I would offer up a very simple term for the goal:

     ad hoc VPN

As that would thus mean a VPN that is "formed, arranged, or done for a particular purpose only".

I will endeavor to have more commentary on the draft later this evening.

--
Mark Boltz, CISSP, CISA, NSA-IEM, CSGI
Director, Federal and Mid-Atlantic
e: [email-masked]<mailto:[email-masked]>   e: [email-masked]<mailto:[email-masked]>
p: 866.869.4075               c: 571.246.2233
o: 202.434.8963               f: 703.997.4759
w: http://www.stonesoft.com<http://www.stonesoft.com/>

1200 G St. NW, Suite 800

Stonesoft: Network Security. Simplified.

On Mar 19, 2012, at 10:36 AM, Michael Richardson wrote:

"Yoav" == Yoav Nir <[email-masked]<mailto:[email-masked]>> writes:

I agree.

I offer:

] [email-masked]<mailto:[email-masked]> http://www.sandelman.ottawa.on.ca/ |device driver[

---

From: Stephen Hanna <[email-masked]>
Date: Mon, 19 Mar 2012 14:32:16 -0400

I'm concerned that people expect "ad hoc VPN" to include VPN connections between endpoints with no prior trust relationship.

Thanks,

Steve

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Boltz
Sent: Monday, March 19, 2012 2:12 PM
To: IPsecme WG
Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED

     ad hoc VPN

1200 G St. NW, Suite 800

I agree.

I offer:

---

From: Mark Boltz <[email-masked]>
Date: Mon, 19 Mar 2012 18:38:03 +0000

Interesting. I always considered the requirement of a trust relationship of some kind an inherent part of "VPN" (of any kind, SSL, IPsec or otherwise), and assumed most people did.

In no part is trust suggested or otherwise in the Latin "ad hoc", so it is technically an incorrect expectation.

But if the group feels that somehow the simplest correct term is too confusing we can try for something else. :-)

1200 G St. NW, Suite 800

On Mar 19, 2012, at 2:32 PM, Stephen Hanna wrote:

I’m concerned that people expect “ad hoc VPN” to include VPN connections between endpoints with no prior trust relationship.

Thanks,

Steve

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Mark Boltz
Sent: Monday, March 19, 2012 2:12 PM
To: IPsecme WG
Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED

     ad hoc VPN

1200 G St. NW, Suite 800

I agree.

I offer:

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 19 Mar 2012 13:45:40 -0700

> Interesting. I always considered the requirement of a trust relationship of some kind an inherent part of "VPN" (of any kind, SSL, IPsec or otherwise), and assumed most people did. 

Mark, meet Michael Richardson and friends. :-)

> But if the group feels that somehow the simplest correct term is too confusing we can try for something else. :-)

See earlier in this thread on opportunistic VPNs, which this is not.

--Paul Hoffman

---

From: Michael Richardson <[email-masked]>
Date: Mon, 19 Mar 2012 21:40:33 -0400

<#part sign=pgpmime>

>>>>> "Paul" == Paul Hoffman <[email-masked]> writes:
    >> Interesting. I always considered the requirement of a trust
    >> relationship of some kind an inherent part of "VPN" (of any kind,
    >> SSL, IPsec or otherwise), and assumed most people did.

    Paul> Mark, meet Michael Richardson and friends. :-)

Why?  A VPN implies trust, and you leverage it.

An RFC4322 OE system provides privacy, and we go out of our way to
distinguish it from trust.  The letters VPN occur three times in
RFC4322, and each time to help say, "unlike.."

RFC4322 tells you how much to trust the packets (not very much), because
you know from which anchor you got the "trust".  If your trust anchor is
stronger, then you can do more things with them.

What I've said repeatedly is that a system that implements RFC4322 OE
likely already has all the mechanisms to implement P2PVPN.

Here is a section.  We are clearly building a configured tunnel.
The question is how does the configuration occur.  

1.2.  Encryption Regimes

   To aid in understanding the relationship between security processing
   and IPsec, we divide policies controlling network traffic into four
   categories.  The traffic is categorized by destination address using
   longest prefix match.  Therefore, each category is enumerated by a
   set of network prefixes.  The categories are mutually exclusive; a
   particular prefix should only occur in one category.

   * Deny: network prefixes to which traffic is always forbidden.
   * Permit: network prefixes to which traffic in the clear is
     permitted.
   * Opportunistic tunnel: network prefixes to which traffic is
     encrypted if possible, when it otherwise might be sent in the
     clear.
   * Configured tunnel: network prefixes to which traffic must be
     encrypted, and traffic in the clear is never permitted.  A
     traditionally defined Virtual Private Network (VPN) is a form of
     configured tunnel.

---

From: Manish Kumar <[email-masked]>
Date: Wed, 21 Mar 2012 20:20:23 +0530

Although I prefer it over some of the other names, "discovery" isn't making
too good an adjective here. How about "Dynamic Secure VPN" without over
qualifying dynamic ?

Thanks,
Manish

On 19/03/12 1:27 PM, "Yoav Nir" <[email-masked]> wrote:

> As Tero pointed out, some of the use cases don't end up in a full mesh,
> because sometimes administrators really want a trunk, so the end result could
> be a mesh among nodes in the same organization, and a trunk to another. Maybe
> even a partial mesh (with "secondary nodes" behind particularly bad NAT
> devices connecting to one of many "primary nodes")
>