Subject: Re: Fwd: [vpn4dc] Question on the problem

From: Robert Raszuk <[email-masked]>
Date: Tue, 01 Nov 2011 13:03:17 +0100

Hi Fred,

In the light of your below message it would be very interesting to hear 
your point of view on IPSec like "VPN as a Service" approach with 
provider's neutral auto-discovery service ?

It seems that it can address L2VPN, L3VPN as well as VPN4DC set of 
requirements in a much more general way.

Problem statement has been described in:
http://tools.ietf.org/html/draft-ko-vaas-problem-statement-01

Thx,
R.

> Forwarding for Fred Baker.
>
> ---------- Forwarded message ----------
> From: Fred Baker<[email-masked]>
> Date: Mon, Oct 31, 2011 at 8:58 AM
> Subject: [vpn4dc] Question on the problem
> To: [email-masked]
>
>
> I have started reading the vpn4dc drafts, and especially the problem
> statements, and find myself scratching my head. Starting with the title
> "VPN for Data Center", I really wonder if the topic is starting from a
> proposed solution before settling on a problem.
>
> Let me ramble a bit, and then tell me I'm wrong.
>
> It seems to me that your primary issue is that you have a set of hosts that
> want to communicate with each other securely. These hosts might be physical
> or virtual, and might be in the same data center or in different data
> centers. The important thing is that they be able to authenticate
> communications with each other, and then do things that they are authorized
> to do based on those communications. The things that they do might differ.
> Within one community, the hosts might all be peers accomplishing the job of
> the cloud, whatever that is - order processing, content delivery, take your
> pick. Within another community, the issue might be the management of
> virtual machines, and you might have a relatively small number of control
> systems that talk with a large number of client machines.
>
> The term "VPN" implies to me that you have chosen a solution. It might be
> an MPLS VPN, which is to say that you have transport but depend on higher
> layer services for encryption, authentication, and authorization. In IPsec,
> "VPN" the term "VPN" generally refers to the tunnel mode, and is a way of
> overlaying one network on another. In the case, that doesn't make a lot of
> sense to me in this context - You don't appear to be overlaying networks
> per se, merely making sure that messages you receive and process are from
> trusted peers.
>
> If the primary issue is one of trust, we could discuss TLS, https (if the
> only application protocol is a web protocol), or IPsec's transport mode. In
> any of those, the issue is largely one of key distribution, and the use of
> those keys for encryption and authentication to manage communications among
> a set of communicating entities.
>
> What am I missing? What makes this specifically a Virtual Private Network?
> Why is this not a key distribution problem based on existing technologies?
> _______________________________________________
> vpn4dc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vpn4dc
>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 01 Nov 2011 13:16:32 +0100

Hi Luyuan,

I think the time has come to allow customers freedom to choose how they 
are going to interconnect their DC sites without relaying and being 
locked to the same service provider they have used for the last 12 years 
to deliver their VPN connectivity.

By such decoupling they are free to choose arbitrary data center 
physical or virtual location without worrying that their SP does not 
have a presence in the DC proximity.

In particular if I am interested to secure my on demand public cloud 
resources I would hardly be able to accomplish that by current VPN 
static connectivity model. It really needs to be local provider 
independent, on demand dynamic secure discovery service.

Thx,
R.

> Hi Fred,
>
> Thanks a lot for the discussion.
>
> You are right about the DC host to host communication. Now we need to
> get clear on the 'securely' thing.
>
> Here is background of the vpn4dc initiative:  SPs already have large VPN
> deployment, they are moving fast on providing scalable cloud services.
> The MPLS VPN typically ends at PEs, not reaching to hosts/end systems.
> The provisioning is segmented (SP network segment, SP DC segment,
> Enterprise segment, content provider segment), and today they are often
> facing long service turning up time. - this is the practical problems
> Ning first presented to us.
>
> After a couple of months study, we decided we would not be able to solve
> everything for the end-to-end provisioning in one effort, but we could
> possibly solve the  host-to-host layer 3 - ip or mpls, vpn connectivity
> problems in one initiative - vpn4dc. Why vpn? because they are existing
> services, one of the most widely deployed features over the last 12
> years. Enterprise customers are asking SPs to extend the vpns to the end
> systems.
>
> We know that MPLS/BGP VPN or other IP tunneling mechanisms provide
> routing isolation, not encryption. Many folks consider the routing
> isolation provides certain degree of security, good enough for them,
> while others think security means  encryption. We are not going to enter
> that debate here.
>
> Our intention is to focus on the vpn connectivity issues, not
> cryptography techniques, nor key distribution/key management, we will
> leave these to the Security Area.
>
> Let me send next mail to get more feedbacks from all.
>
> Thanks,
> Luyuan
>
>
>
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Marshall Eubanks
> Sent: Monday, October 31, 2011 7:56 PM
> To: L3VPN; Fred Baker (fred)
> Subject: Fwd: [vpn4dc] Question on the problem
>
>
>
> It seems to me that your primary issue is that you have a set of hosts
> that want to communicate with each other securely. These hosts might be
> physical or virtual, and might be in the same data center or in
> different data centers. The important thing is that they be able to
> authenticate communications with each other, and then do things that
> they are authorized to do based on those communications. The things that
> they do might differ. Within one community, the hosts might all be peers
> accomplishing the job of the cloud, whatever that is - order processing,
> content delivery, take your pick. Within another community, the issue
> might be the management of virtual machines, and you might have a
> relatively small number of control systems that talk with a large number
> of client machines.
>
> The term "VPN" implies to me that you have chosen a solution. It might
> be an MPLS VPN, which is to say that you have transport but depend on
> higher layer services for encryption, authentication, and authorization.
> In IPsec, "VPN" the term "VPN" generally refers to the tunnel mode, and
> is a way of overlaying one network on another. In the case, that doesn't
> make a lot of sense to me in this context - You don't appear to be
> overlaying networks per se, merely making sure that messages you receive
> and process are from trusted peers.
>
> If the primary issue is one of trust, we could discuss TLS, https (if
> the only application protocol is a web protocol), or IPsec's transport
> mode. In any of those, the issue is largely one of key distribution, and
> the use of those keys for encryption and authentication to manage
> communications among a set of communicating entities.
>
> What am I missing? What makes this specifically a Virtual Private
> Network? Why is this not a key distribution problem based on existing
> technologies?

---

From: Derick Winkworth <[email-masked]>
Date: Tue, 1 Nov 2011 07:42:40 -0700 (PDT)

All:

I, too, agree that the "host-to-host" term is confusing.  Its not about host-to-host.  Its about putting VMs (or other hosts) "into" an existing L3VPN natively.  They could have IP addresses chosen by the L3VPN customer, for instance.  We should be able to turn up a VM and drop it into an L3VPN without installing software or performing configuration on the VM itself.

If the L3VPN does not already exist in the data center where the VM host resides, how can we automate the provisioning of the VRFs, and then automate the attachment of the VM to that VRF?  Manually configuring all of that can be extremely tedious.  Orchestration tools that interface with disparate APIs aren't doing the job well.

Derick

________________________________
From: Luyuan Fang (lufang) <[email-masked]>
To: Marshall Eubanks <[email-masked]>; L3VPN <[email-masked]>; Fred Baker (fred) <[email-masked]>
Sent: Monday, October 31, 2011 11:54 PM
Subject: RE: [vpn4dc] Question on the problem

Hi Fred,

You are right about the DC host to host communication. Now we
need to get clear on the ‘securely’ thing. 
 
Here is background of the vpn4dc initiative:  SPs already
have large VPN deployment, they are moving fast on providing scalable cloud
services. The MPLS VPN typically ends at PEs, not reaching to hosts/end
systems. The provisioning is segmented (SP network segment, SP DC segment,
Enterprise segment, content provider segment), and today they are often facing long
service turning up time. – this is the practical problems Ning first
presented to us. 
 
After a couple of months study, we decided we would not be able
to solve everything for the end-to-end provisioning in one effort, but we could
possibly solve the  host-to-host layer 3 - ip or mpls, vpn connectivity problems
in one initiative – vpn4dc. Why vpn? because they are existing services, one
of the most widely deployed features over the last 12 years. Enterprise customers
are asking SPs to extend the vpns to the end systems.
 
We know that MPLS/BGP VPN or other IP tunneling mechanisms provide
routing isolation, not encryption. Many folks consider the routing isolation
provides certain degree of security, good enough for them, while others think security
means  encryption. We are not going to enter that debate here.
 
Our intention is to focus on the vpn connectivity issues, not
cryptography techniques, nor key distribution/key management, we will leave
these to the Security Area.  

Thanks,
Luyuan
 
From:[email-masked] [mailto:[email-masked]] On Behalf Of Marshall
Eubanks
Sent: Monday, October 31, 2011 7:56 PM
To: L3VPN; Fred Baker (fred)
Subject: Fwd: [vpn4dc] Question on the problem
 
---------- Forwarded message ----------
From: Fred Baker <[email-masked]>
Date: Mon, Oct 31, 2011 at 8:58 AM
Subject: [vpn4dc] Question on the problem
To: [email-masked]

I have started reading the vpn4dc drafts, and especially the problem
statements, and find myself scratching my head. Starting with the title
"VPN for Data Center", I really wonder if the topic is starting from
a proposed solution before settling on a problem.

It seems to me that your primary issue is that you have a set of hosts that
want to communicate with each other securely. These hosts might be physical or
virtual, and might be in the same data center or in different data centers. The
important thing is that they be able to authenticate communications with each
other, and then do things that they are authorized to do based on those
communications. The things that they do might differ. Within one community, the
hosts might all be peers accomplishing the job of the cloud, whatever that is -
order processing, content delivery, take your pick. Within another community,
the issue might be the management of virtual machines, and you might have a
relatively small number of control systems that talk with a large number of
client machines.

The term "VPN" implies to me that you have chosen a solution. It
might be an MPLS VPN, which is to say that you have transport but depend on
higher layer services for encryption, authentication, and authorization. In
IPsec, "VPN" the term "VPN" generally refers to the tunnel
mode, and is a way of overlaying one network on another. In the case, that
doesn't make a lot of sense to me in this context - You don't appear to be
overlaying networks per se, merely making sure that messages you receive and
process are from trusted peers.

If the primary issue is one of trust, we could discuss TLS, https (if the only
application protocol is a web protocol), or IPsec's transport mode. In any of
those, the issue is largely one of key distribution, and the use of those keys
for encryption and authentication to manage communications among a set of
communicating entities.

What am I missing? What makes this specifically a Virtual Private Network? Why
is this not a key distribution problem based on existing technologies?
_______________________________________________
vpn4dc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vpn4dc

---

From: Lucy yong <[email-masked]>
Date: Tue, 01 Nov 2011 15:35:12 +0000

All,

It is more about hosts’ virtual private network.  VPN4DC is aiming on L3VPN as the solution for hosts’ virtual private network.

Lucy

From: [email-masked] [mailto:[email-masked]] On Behalf Of Derick Winkworth
Sent: Tuesday, November 01, 2011 9:43 AM
To: Luyuan Fang (lufang); Marshall Eubanks; L3VPN; Fred Baker (fred)
Subject: Re: [vpn4dc] Question on the problem

All:

Derick

You are right about the DC host to host communication. Now we need to get clear on the ‘securely’ thing.

Here is background of the vpn4dc initiative:  SPs already have large VPN deployment, they are moving fast on providing scalable cloud services. The MPLS VPN typically ends at PEs, not reaching to hosts/end systems. The provisioning is segmented (SP network segment, SP DC segment, Enterprise segment, content provider segment), and today they are often facing long service turning up time. – this is the practical problems Ning first presented to us.

After a couple of months study, we decided we would not be able to solve everything for the end-to-end provisioning in one effort, but we could possibly solve the  host-to-host layer 3 - ip or mpls, vpn connectivity problems in one initiative – vpn4dc. Why vpn? because they are existing services, one of the most widely deployed features over the last 12 years. Enterprise customers are asking SPs to extend the vpns to the end systems.

We know that MPLS/BGP VPN or other IP tunneling mechanisms provide routing isolation, not encryption. Many folks consider the routing isolation provides certain degree of security, good enough for them, while others think security means  encryption. We are not going to enter that debate here.

Our intention is to focus on the vpn connectivity issues, not cryptography techniques, nor key distribution/key management, we will leave these to the Security Area.

Thanks,
Luyuan

From: [email-masked] [mailto:[email-masked]] On Behalf Of Marshall Eubanks
Sent: Monday, October 31, 2011 7:56 PM
To: L3VPN; Fred Baker (fred)
Subject: Fwd: [vpn4dc] Question on the problem

---------- Forwarded message ----------
From: Fred Baker <[email-masked]<mailto:[email-masked]>>
Date: Mon, Oct 31, 2011 at 8:58 AM
Subject: [vpn4dc] Question on the problem
To: [email-masked]<mailto:[email-masked]>

I have started reading the vpn4dc drafts, and especially the problem statements, and find myself scratching my head. Starting with the title "VPN for Data Center", I really wonder if the topic is starting from a proposed solution before settling on a problem.

It seems to me that your primary issue is that you have a set of hosts that want to communicate with each other securely. These hosts might be physical or virtual, and might be in the same data center or in different data centers. The important thing is that they be able to authenticate communications with each other, and then do things that they are authorized to do based on those communications. The things that they do might differ. Within one community, the hosts might all be peers accomplishing the job of the cloud, whatever that is - order processing, content delivery, take your pick. Within another community, the issue might be the management of virtual machines, and you might have a relatively small number of control systems that talk with a large number of client machines.

The term "VPN" implies to me that you have chosen a solution. It might be an MPLS VPN, which is to say that you have transport but depend on higher layer services for encryption, authentication, and authorization. In IPsec, "VPN" the term "VPN" generally refers to the tunnel mode, and is a way of overlaying one network on another. In the case, that doesn't make a lot of sense to me in this context - You don't appear to be overlaying networks per se, merely making sure that messages you receive and process are from trusted peers.

If the primary issue is one of trust, we could discuss TLS, https (if the only application protocol is a web protocol), or IPsec's transport mode. In any of those, the issue is largely one of key distribution, and the use of those keys for encryption and authentication to manage communications among a set of communicating entities.

What am I missing? What makes this specifically a Virtual Private Network? Why is this not a key distribution problem based on existing technologies?
_______________________________________________
vpn4dc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/vpn4dc

---

From: Pedro Marques <[email-masked]>
Date: Tue, 1 Nov 2011 10:35:51 -0700

Fred,
Authentication and private networks are orthogonal topics; both are
necessary. In a shared facility it is necessary to control the IP
network access of machines (virtual or otherwise) of a given
admin-domain. For instances such networks are often closed to the
outside world. This does not replace the need to authenticate at the
application level.

As with any other application security is applied in layers. VPNs are
needed in this space by the same reason they are needed in another
other space. I'm sure you are not going to advocate that we should
just get rid of firewalls and private enterprise networks. It is well
understood that end-to-end IP unfettered access is unrealistic for
security and administrative reasons.

The term VPN states a requirement. I believe it is preferable than to
use the term "VLAN" which is more common in this space, where the
implication is that the VLAN is not connected to the outside world
other than through an appliance.

Application level security within a VPN is still required. But that
doesn't not replace the need for a private network. I don't believe it
is productive to argue otherwise. It is simply not acceptable for the
VMs of user A to be able to send arbitrary IP packets to the VMs of
user B.

  Pedro.

On Mon, Oct 31, 2011 at 4:56 PM, Marshall Eubanks
<[email-masked]> wrote:
> statements, and find myself scratching my head. Starting with the title "VPN
> for Data Center", I really wonder if the topic is starting from a proposed
> solution before settling on a problem.
>
> pick. Within another community, the issue might be the management of virtual
> machines, and you might have a relatively small number of control systems
> that talk with a large number of client machines.
>
> The term "VPN" implies to me that you have chosen a solution. It might be an
> MPLS VPN, which is to say that you have transport but depend on higher layer
> services for encryption, authentication, and authorization. In IPsec, "VPN"
> the term "VPN" generally refers to the tunnel mode, and is a way of
> sense to me in this context - You don't appear to be overlaying networks per
> se, merely making sure that messages you receive and process are from
> trusted peers.
>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 01 Nov 2011 19:02:22 +0100

Pedro,

> In a shared facility it is necessary to control the IP
> admin-domain.

+

> VMs of user A to be able to send arbitrary IP packets to the VMs of

Do you think that it is acceptable of arbitrary host in the internet to 
send IP packet to any other host ? If not then how are you protecting 
considering draft-marques-l3vpn-end-system the datacenter host from 
being reachable by anyone ?

Correct me if I have misread the proposal but it seems you are 
protecting VMs running over those host by terminating IP GRE tunnels in 
the hosts and allowing only selected IP reachability to reach particular 
set of VMs.

I do not see how is this any more secure as interconnecting VMs over 
IPsec and filtering (be it on the host level) any other IP traffic 
between same admin-domain groups such VMs are provisioned to be part of.

Thx,
R.

---

From: Pedro Marques <[email-masked]>
Date: Tue, 1 Nov 2011 11:18:57 -0700

On Tue, Nov 1, 2011 at 11:02 AM, Robert Raszuk <[email-masked]> wrote:

>
> Do you think that it is acceptable of arbitrary host in the internet to send
> IP packet to any other host ?

That is a very imprecise question. The "internet" is generally the set
of consumer devices plus the web front-ends that provide content. That
set of devices gets to exchange traffic.

> If not then how are you protecting considering
> draft-marques-l3vpn-end-system the datacenter host from being reachable by
> anyone ?

Data center networks are private networks. Front-end devices talk to
both the external network and the private network to fetch data.

For most data-centers it would very likely be illegal for the data
center machines to be reachable through the internet. There are laws
in most countries protecting confidentially of data and having direct
access to the internet would most like constitute negligence. It
should. Certainly as a consumer i would feel unacceptable if my
private data was kept on a system with internet access. By the same
token "company-A" VMs should not be able to communicate directly with
VMs from "company-B".

>
> I do not see how is this any more secure as interconnecting VMs over IPsec
> and filtering (be it on the host level) any other IP traffic between same
> admin-domain groups such VMs are provisioned to be part of.
>

IPsec is also used to implement private networks. The term VPN also
covers IPsec VPNs.
Fred's email questions the requirement for VPNs between different
admin-domains. Application level authentication is simply not a
replacement for a virtual private network.

  Pedro.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 01 Nov 2011 20:16:06 +0100

Hi Pedro,

> private data was kept on a system with internet access.

How would you envision practically to open holes in the current data 
center security model for GRE tunnels to reach data center hosts ?

Would it be automated or manual operation ? Perhaps considering this 
discussion it could be great to update any set of proposals with such 
details. Considering model proposed in your draft I do not think this is 
out of scope.

However if VMs would be able to initiate a VPN it may be just VPN 
membership discovery server allocating required VPN credentials which 
would seemed required.

I am of the opinion that host OS given VMs are build over should not be 
involved in VM to VM secure inter-connectivity.

 > By the same token "company-A" VMs should not be able to
 > communicate directly with VMs from "company-B".

That is in fact another reason why such VPN isolation should rather not 
require configuration of number of other elements then VMs itself.

> replacement for a virtual private network.

The way I read Fred's message is not that. I think he just questions why 
only MPLS-VPN model should be used as VM to VM VPN solution.

Thx,
R.

---

From: Pedro Marques <[email-masked]>
Date: Tue, 1 Nov 2011 12:55:02 -0700

Robert,

>
> How would you envision practically to open holes in the current data center
> security model for GRE tunnels to reach data center hosts ?

Several of the problem statement documents envision data-center
gateways that interconnect the private VM networks to private
enterprise networks. The typical assumption tends to be that the
enterprise private network is being transported over MPLS, with a
carrier providing the enterprise VPN.

You have references to both "option B" interconnects between the DC
network and SP networks and also attempts to revive the "option D"
approach from years back (per VPN forwarding state with aggregate
option B style ebgp session).

The same interconnection model would be applicable to a VPN carried
over GRE instead of MPLS, i believe.

In a similar vain the the interconnect can be a simple IPsec tunnel
from the enterprise side plus a web app configuring its respective IP
prefixes. This is the model in use today in the most common public
services.

> details. Considering model proposed in your draft I do not think this is out
> of scope.

This is certainly within the scope of the problem statement drafts and
more than one touch on the issue, although not in enough detail in
order to describe a solution (which makes sense since they are problem
statements).

>
> However if VMs would be able to initiate a VPN it may be just VPN membership
> discovery server allocating required VPN credentials which would seemed
> required.

The requirement here is the inverse. The VM is imposed a private
network topology.

> involved in VM to VM secure inter-connectivity.

The host OS is already involved. The host OS must ensure containment
between VMs and must ensure that a VM cannot spill over to other VM in
the same host and in anyway read its memory influence it.

> only MPLS-VPN model should be used as VM to VM VPN solution.

There are many technologies capable of delivering VPNs and it is
reasonable to discuss the pros and cons of each.

  Pedro.

---

From: Derick Winkworth <[email-masked]>
Date: Tue, 1 Nov 2011 16:27:11 -0700 (PDT)

Robert:

##########
That is in fact another reason why such VPN isolation should rather not require configuration of number of other elements then VMs itself.

#########

Can you elaborate on this statement?  On the face of it, I could not disagree more.  We absolutely want to containerize VMs in the network and not have any dependencies at all on configuration within the VM itself..

Derick

________________________________
From: Robert Raszuk <[email-masked]>
To: Pedro Marques <[email-masked]>
Cc: L3VPN <[email-masked]>; Fred Baker <[email-masked]>
Sent: Tuesday, November 1, 2011 2:16 PM
Subject: Re: [vpn4dc] Question on the problem

Hi Pedro,

> private data was kept on a system with internet access.

How would you envision practically to open holes in the current data center security model for GRE tunnels to reach data center hosts ?

Would it be automated or manual operation ? Perhaps considering this discussion it could be great to update any set of proposals with such details. Considering model proposed in your draft I do not think this is out of scope.

However if VMs would be able to initiate a VPN it may be just VPN membership discovery server allocating required VPN credentials which would seemed required.

I am of the opinion that host OS given VMs are build over should not be involved in VM to VM secure inter-connectivity.

> communicate directly with VMs from "company-B".

That is in fact another reason why such VPN isolation should rather not require configuration of number of other elements then VMs itself.

> replacement for a virtual private network.

The way I read Fred's message is not that. I think he just questions why only MPLS-VPN model should be used as VM to VM VPN solution.

Thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 02 Nov 2011 00:46:58 +0100

Hi Derick,

Very glad you have asked.

When I establish a VPN from any of my hosts, from my CE router(s) or 
from my smartphones I do not tell my providers that I need my device to 
securely participate in the VPN.

I fail to see why adding VM to any VPN would need to be any harder or 
any different than the examples provided above.

Note that VMs can be short lived and placed in arbitrary data center 
locations on the network. Who do you tell that you need to join a VPN ?

In other words if I would like to buy a VM resources from any cloud 
providers (for example: Amazon, Google ...) all I should need is to log 
in to such VPN and establish a VPN connection to the rest of my 
enterprise network - smartphones included.

Thx,
R.

> Robert:
>
> ########## That is in fact another reason why such VPN isolation
> should rather not require configuration of number of other elements
> then VMs itself.
>
> #########
>
> Can you elaborate on this statement?  On the face of it, I could not
> disagree more.  We absolutely want to containerize VMs in the network
> and not have any dependencies at all on configuration within the VM
> itself..
>
> Derick

---

From: Derick Winkworth <[email-masked]>
Date: Tue, 1 Nov 2011 18:10:37 -0700 (PDT)

Answers in-line.

________________________________
From: Robert Raszuk <[email-masked]>
To: Derick Winkworth <[email-masked]>
Cc: Pedro Marques <[email-masked]>; L3VPN <[email-masked]>; Fred Baker <[email-masked]>
Sent: Tuesday, November 1, 2011 6:46 PM
Subject: Re: [vpn4dc] Question on the problem

Hi Derick,

----------
When I establish a VPN from any of my hosts, from my CE router(s) or from my smartphones I do not tell my providers that I need my device to securely participate in the VPN.
----------

Your VPN is implied.  Your VMs are not able to directly communicate with the VMs of another of Google's customers by default.  I wonder how Google achieves this separation... 

-----
I fail to see why adding VM to any VPN would need to be any harder or any different than the examples provided above.
----

The complexity is hidden from you in the case of Google or Amazon.  It would be hidden from the tenant in the case of VPN4DC.  the difference is that, as a MPLS network operator, the tenant's private networks already exist at the edge of my data center in the form of virtual-routers.  My customers would like the VMs I provision for them to appear native to their L3VPN network.  Think virtual-datacenter for private networks.

----------
Note that VMs can be short lived and placed in arbitrary data center locations on the network. Who do you tell that you need to join a VPN ?
----------

The tenant tells noone.   I, on the other hand, would like to automate turning up a VM and attaching it to a customers L3VPN so it appears native to their private network and provide the same illusion of simplicity to my tenant as Google or Amazon provides to customers who find internet-based cloud services acceptable.

-------
In other words if I would like to buy a VM resources from any cloud providers (for example: Amazon, Google ...) all I should need is to log in to such VPN and establish a VPN connection to the rest of my enterprise network - smartphones included.
----------

You realize there is more going on under the hood in your example than you have indicated?

Thx,
R.

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Tue, 1 Nov 2011 21:33:56 -0500

Hi Derick,

Sorry about the confusion on the ‘host-to-host”, agreed to reword, as several others raised the same question.

I like your descriptions, that was exactly what motivated many of us to start this initiative. 

Automate the provisioning for VM to join the correct VPNs through control protocols is one of the key problems we aim to solve.

Thanks for your comments.

Luyuan

From: Derick Winkworth [mailto:[email-masked]] 
Sent: Tuesday, November 01, 2011 10:43 AM
To: Luyuan Fang (lufang); Marshall Eubanks; L3VPN; Fred Baker (fred)
Subject: Re: [vpn4dc] Question on the problem

All:

Derick

Hi Fred,

Thanks,

Luyuan

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 1 Nov 2011 22:38:09 -0400

---------- Forwarded message ----------
From: Fred Baker <[email-masked]>
Date: Tue, Nov 1, 2011 at 3:48 PM
Subject: Re: [vpn4dc] Question on the problem
To: [email-masked]
Cc: Pedro Marques <[email-masked]>, Marshall Eubanks
<[email-masked]>, L3VPN <[email-masked]>

On Nov 2, 2011, at 2:02 AM, Robert Raszuk wrote:

> Do you think that it is acceptable of arbitrary host in the internet to send IP packet to any other host ?

I think NIST has this right in their 2009 description of the Smart
Grid project. Note that in the electrical grid, there are a lot of
parties that for very good reasons should not be able to directly
communicate - you don't want script kiddies DDOSing electrical
generators or switching systems, which have timing requirements on the
order of 1/4 Hz (4 ms) and kill people when that is disrupted, for
example. But the statement of direction states that "...the Network
should enable an application in a particular domain to communicate
with an application in any other domain in the information network,
with proper management control over who and where applications can be
interconnected.”

In other words, it should be *capable* of connecting any two systems,
and should have appropriate controls to prevent unauthorized
connectivity, both in the network and at the host itself.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 02 Nov 2011 08:38:45 +0100

Hi Derick,

> Your VMs are not able to directly communicate
> with the VMs of another of Google's customers by default.  I wonder
> how Google achieves this separation...

I can buy VM from my or any hosting provider in the Internet in few 
seconds and this VM will have full access to the Internet ON by default 
and for that matter to any other VM running in public space. In some 
cases I can either upload which image such VM should be booted with.

My hosting provider does not have any link to you as the SP. So even if 
I am your L3VPN customer how are you going to attach such VM to be part 
of my VPN ? How long such attachment will take you ? How are you going 
to convince my hosting provider to enable host level separation per some 
solutions proposed already.

--

The other topic is when you as the L3VPN SP own data center/cloud and 
would like to enhance your current MPLS-VPN service offering to offer to 
your customers an additional VM resources. If this is the model you are 
describing that I am completely fine with it. However while this is a 
valid model this is only a subset of VPN models for secure data center 
inter-connectivity requirements.

Best regards,
R.

> ----- I fail to see why adding VM to any VPN would need to be any
> harder or any different than the examples provided above. ----
>
> The complexity is hidden from you in the case of Google or Amazon.
> It would be hidden from the tenant in the case of VPN4DC.  the
> difference is that, as a MPLS network operator, the tenant's private
> networks already exist at the edge of my data center in the form of
> virtual-routers.  My customers would like the VMs I provision for
> them to appear native to their L3VPN network.  Think
> virtual-datacenter for private networks.
>
>
> ---------- Note that VMs can be short lived and placed in arbitrary
> data center locations on the network. Who do you tell that you need
> to join a VPN ? ----------
>
> The tenant tells noone.   I, on the other hand, would like to
> automate turning up a VM and attaching it to a customers L3VPN so it
> appears native to their private network and provide the same illusion
> of simplicity to my tenant as Google or Amazon provides to customers
> who find internet-based cloud services acceptable.
>
> ------- In other words if I would like to buy a VM resources from any
> cloud providers (for example: Amazon, Google ...) all I should need
> is to log in to such VPN and establish a VPN connection to the rest
> of my enterprise network - smartphones included. ----------
>
> Thx, R.
>> should rather not require configuration of number of other
>> elements then VMs itself.
>>
>> #########
>>
>> Can you elaborate on this statement?  On the face of it, I could
>> not disagree more.  We absolutely want to containerize VMs in the
>> network and not have any dependencies at all on configuration
>> within the VM itself..
>>
>> Derick

---

From: <[email-masked]>
Date: Wed, 2 Nov 2011 13:01:22 +0000

Hi Robert,

You wrote 02 November 2011 07:39
> To: Derick Winkworth
> Cc: L3VPN; Fred Baker

You (and Fred before you) make some excellent points Robert.  I hope folks are listening to these.  The whole notion of 'L3' vs 'L2' is seriously flawed as we all should know by now.  There are many layer networks operating at L3 in all 3 network modes of co-cs, co-ps and cl-ps...the network mode is a function of how one carves up space/freq/time resource dimensions and labels them for different client instances.  Indeed if this were not true then IETF would not be working on GMPLS (co-cs) or MPLS-TP (co-ps) to augment IP (cl-ps).  Note - The notion of a single instance of routing running IP to Optics is flawed for many reasons and at the heart of many of the problems here.

The so-called 'L3 VPNs' have no need to use MPLS...we can use any server technology here to create the client/server separation of a client IP layer network from whatever mode of technology lies under it....though having pukka single source connections for the server layer network technology is a key requirement if one wants strong control of resource allocation/separation to each client. 

The primary reason IP is so important is not the flawed OSI L3 RM nonsense, but the simple fact that it contains adaptation functions that allows the interfacing with external (to the network) message/file/stream application types.  Indeed, the whole purpose of *any* networking case is to allow these external message/file/stream applications to communicate over a large geographic distance.

Network technologies that have these message/file/stream application adaptation functions are what I have called a TOS (Top-of-Stack) layer network.  And it is only here that both public network services and peering at E-NNIs between different operating parties are required, eg Internet or PSTN say...the PSTN is a 64kbit/s co-cs layer network primarily oriented towards interfacing only with stream (voice) applications 

For all 'VPN' cases what we need is some form of client/server layer network relationship.  It is trivially easy to prove that any non-TOS layer network does not require peering E-NNIs....that is the route of folks who either don't understand the technical nature of the problem or simply want to generate unnecessary work/problems/costs.  

The key client/server 'VPN' requirement relates to transparency and this means strong functional separation of the DP/CP/MP of each client layer network instance from each other.  This is achieved one way in rfc4364 but it is not the only way...indeed operators have been doing client/server VPNs a long time before rfc4364 arrived on the scene (the PDH and SDH hierarchies for example are exactly this in a very simple form).  The clever bits in rfc4364 relate to how BGP4 is used by the SP to broker client IP layer CP/routing separation.....this client layer CP/routing aspect can be decoupled from the need for client/server DP separation, and the server layer network here has no need to be MPLS.

regards, Neil

---

From: Lucy yong <[email-masked]>
Date: Sat, 12 Nov 2011 21:40:15 +0000

I really like what  Derick describes below. This is exactly the first goal we want to achieve in VPN4DC.  I really wish to read this mail early.

Summary is here:

A MPLS network operator, the tenant's private networks already exist at the edge of my data center in the form of virtual-routers.  My customers would like the VMs I provisions for them to appear native to their L3VPN network.

I, on the other hand, would like to automate turning up a VM and attaching it to a customers L3VPN so it appears native to their private network and provide the same illusion of simplicity to my tenant.

End.

The problem statement is that existing L3VPN protocols can not support automate turning up a VM and attaching it to a customers L3VPN.

Thanks Derick. Hope people can reach the same view and agree the value to work on this.

Cheers,
Lucy

From: [email-masked] [mailto:[email-masked]] On Behalf Of Derick Winkworth
Sent: Tuesday, November 01, 2011 8:11 PM
To: [email-masked]
Cc: L3VPN; Fred Baker
Subject: Re: [vpn4dc] Question on the problem

Answers in-line.

Hi Derick,

----------

-----

----------

-------

Thx,
R.

---

From: Lucy yong <[email-masked]>
Date: Sat, 12 Nov 2011 21:40:19 +0000

Please see inline.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Wednesday, November 02, 2011 2:39 AM
To: Derick Winkworth
Cc: L3VPN; Fred Baker
Subject: Re: [vpn4dc] Question on the problem

Hi Derick,

My hosting provider does not have any link to you as the SP.
[[LY]] This is not in the scope of the situation that VPN4DC start with. VPN4DC assumes that provider has PE nearby the hosting provider.

 So even if 
I am your L3VPN customer how are you going to attach such VM to be part 
of my VPN ? How long such attachment will take you ? 
[[LY]] This is the problem we try to target here. Hope the ability of automated VM turning-up and attaching to L3VPN can short it down to seconds.

How are you going 
to convince my hosting provider to enable host level separation per some 
solutions proposed already.
[[LY]] Good point. Hosting provider needs host level separation in DC. Hosting provider convince you not Network Provider.

--

The other topic is when you as the L3VPN SP own data center/cloud and 
would like to enhance your current MPLS-VPN service offering to offer to 
your customers an additional VM resources. 
[[LY]] This can be one deployment scenario. We do not want to limit this one scenarios.

If this is the model you are 
describing that I am completely fine with it. However while this is a 
valid model this is only a subset of VPN models for secure data center 
inter-connectivity requirements.
[[LY]] Yes, you make the point.

BR,
Lucy

Best regards,
R.