Subject: Fwd: [vpn4dc] Question on the problem

From: Marshall Eubanks <[email-masked]>
Date: Mon, 31 Oct 2011 19:56:08 -0400

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: "Luyuan Fang (lufang)" <[email-masked]>
Date: Mon, 31 Oct 2011 23:54:17 -0500

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

---------- 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]

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