Open Stack

+1
>From nova parity perspective, we should implement [1] first.

From: Michael Shieh [mailto:michael at varmour.com]
Sent: Thursday, April 25, 2013 3:17 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Networking] OpenStack Networking VPN first step

Hi Nachi,

I see these are 2 very different use cases:

[1] is the VPN to support remote access users to connect to the Openstack networks.  This would allow roaming users to connect with security policy defined by Openstack admin, without user intervene.

[2] IPsec is used for site-to-site connection, a must for Amazon VPC type deployment.  If Openstack networks are set up in the cloud for enterprise tenants, this would provide secure connectivities between Openstack networks and enterprise networks.  Security policies are agreed and configured by both sides.  (In Amazon VPC, it can generate security policy for some firewall vendors to import into the firewall of enterprise networks to reduce the configuration complexity).  IPsec could be used for remote access as well (through Xauth or IKEv2) but it's not as simple as [1].  AFAIK, few companies deploy IPsec for remote access.

As [1] has been used in Nova while [2] is still new in Quantum, I vote for [1] so current users have a mechanism to connect to Openstack network to manage or share the resources.  Besides, IPsec alone may not be enough for VPC deployment, as most likely it needs dynamic routing support to detect the tunnel liveness.

Michael


On Wed, Apr 24, 2013 at 4:53 PM, Nachi Ueno <nachi at ntti3.com<mailto:nachi at ntti3.com>> wrote:
Hi folks

I would like to ask your opinions.
[1] Nova parity VPN (Cloudpipe) is OpenStack Networking VPN first step.
Amazon VPC compatible api(*) is also great candidate to start.
And it is using IPSec.
The IPSec has more widely used than SSL-VPN in industry.
so, How about start with IPSec?

Currently, Cloudpipe is using SSL-VPN, However, Cloudpipe was intended to
let users to access to the VLAN, so I tend to think any VPN method is
OK if we can
accomplish it.

so if you want to start with SSL-VPN, please let us know.
In that case, we will start with SSL-VPN.

(*) may be not fully same API, but similer model

[2] Generic VPN Service model
It looks like there is no strong opinion to have "mode" attribute on
Generic VPN Service.
so we would like to remove this attribute.

I registered the BP for Generic VPN service here.
https://blueprints.launchpad.net/quantum/+spec/generic-vpn-service

Is this OK for you guys?

Thanks
Nachi

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130425/f9dfc946/attachment.html>