Open Stack

As lack of cloudpipe is one of the reasons to prevent existing nova 
network users from migrating to quantum, it makes sense to give SSL VPN 
a higher priority.

Yi

On 4/25/13 3:17 AM, Michael Shieh wrote:
> 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
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> 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/20130426/9ebfede5/attachment.html>