Open Stack

Hi paul,

this is also something that we would like to introduce for BGP/MPLS VPNs
[2].

We choose to allow tenants to attach existing networks ( it might evolve to
subnets) to bgpvpn-connection objects, by updating the bgpvpn-connection
object, which is the equivalent of the ipsec-site-connection object.

So I think that Option B is suitable here.

Concerning backward compatibility, I think VPNaas is still considered as
experimental, am I wrong? Do you have to provide backward compatbility in
this case?

Mathieu

[2] https://review.openstack.org/#/c/177740/

On Wed, May 13, 2015 at 8:59 PM, Paul Michali <pc at michali.net> wrote:

> Hi,
>
> There has been, over the years, some mention about having VPN IPSec
> connections supporting multiple CIDRs for local (left side) private
> networks, in addition to the current support for multiple peer CIDRs (right
> side).
>
> I'm raising the question again with these goals:
>
> 1) Determine if the reference IPSec implementations support this capability
> 2) Determine if there is a community desire to enhance VPN to support this
> capability (for all VPN types)
> 3) See what would be the best way to handle this (changes to API and model)
> 4) Identify any consequences of making this change.
>
> Note: My assumption here is something that could be used for any type of
> VPN connection - current IPSec, future BGP/MPLS VPN, DM VPN, etc.
>
> Here is some information that was gathered from people on the VPN team so
> far. Please correct any inaccuracies and comment on the items...
>
> (1) It looks like OpenSwan and Libreswan will support this capability.
> StrongSwan will support this with IKEv2. For IKEv1, a Cisco Unity plugin
> extensions is needed. I'm not sure what that implies [1].
>
> (2) Do we, as a community, want to enhance VPNaaS to provide this
> capability of N:M subnets for VPN implementations? Putting on my vendor
> hat, I can see cases where customers want to be able to only create one
> connection and reference multiple subnets on each end. Is there a desire to
> do this and bake it into the reference implementation (thus making it
> available for other implementations)?
>
> (3) Currently, the vpn service API includes the router and subnet ID. The
> IPSec connection command includes the peer CIDR(s). For reference, here are
> two of the APIs:
>
> usage: neutron vpn-service-create [-h] [-f
> {html,json,shell,table,value,yaml}]
>                                   [-c COLUMN] [--max-width <integer>]
>                                   [--prefix PREFIX]
>                                   [--request-format {json,xml}]
>                                   [--tenant-id TENANT_ID]
> [--admin-state-down]
>                                   [--name NAME] [--description DESCRIPTION]
>                                   ROUTER SUBNET
>
> usage: neutron ipsec-site-connection-create [-h]
>                                             [-f
> {html,json,shell,table,value,yaml}]
>                                             [-c COLUMN]
>                                             [--max-width <integer>]
>                                             [--prefix PREFIX]
>                                             [--request-format {json,xml}]
>                                             [--tenant-id TENANT_ID]
>                                             [--admin-state-down] [--name
> NAME]
>                                             [--description DESCRIPTION]
>                                             [--mtu MTU]
>                                             [--initiator
> {bi-directional,response-only}]
>                                             [--dpd
> action=ACTION,interval=INTERVAL,timeout=TIMEOUT]
>                                             --vpnservice-id VPNSERVICE
>                                             --ikepolicy-id IKEPOLICY
>                                             --ipsecpolicy-id IPSECPOLICY
>                                             --peer-address PEER_ADDRESS
>                                             --peer-id PEER_ID --peer-cidr
>                                             PEER_CIDRS --psk PSK
>
> I could envision several ways to handle this (feel free to add more). Here
> are some thoughts on this...
>
> A) Allow multiple subnets for the vpn service API. The implication here is
> that all types of VPN connections would be able to support multiple subnets.
>
> vpn-service-create ... ROUTER LOCAL_CIDRS
>
> Issue here is that, if a change is desired on a subnet for a specific
> connection, the service must be updated.
>
> Today, I think one has to delete the connections from the service, and
> then can update the service. Would need to have ability to update a
> service, but still there is concern about the effect on other connections.
> It just doesn't seem like the right thing to me.
>
>
> B) Remove the subnet from the vpn service API and add it to the IPSec
> connection API, like is done with peer CIDR selection, allowing multiples.
> Different VPN types could do the same thing for their connection API.
>
> ipsec-site-connection ... LOCAL_CIDRS PEER_CIDRS ...
>
> This seems better, as different types of VPN can decide if they want to
> support this capability and implement their connection API accordingly.
>
> If the handling of this is in a base API, then other VPN types could
> possibly reuse? Issue is that this is a non-backward compatible API change.
> It does seem like a logical implementation to me though.
>
> C) Hybrid of A&B, keep the subnet on the vpn service API, and allow the
> connection API to (optionally) add additional subnets.
>
> vpn-service-create ROUTER SUBNET
> ipsec-site-connection ... LOCAL_CIDRS PEER_CIDRS ...
>
> We could require them to repeat the CIDR for the subnet that was specified
> in the service API (essentially ignoring that subnet arg, or we could
> specify additional CIDRs or subnets in the connection API.
>
> This seems to be backward compatible, but is awkward. If the user wants to
> update a connection, and change the subnet that is mentioned in the vpn
> service, we have the same issue as option A (granted, it is not handled
> well today either).
>
> (4) Obviously, if we change the existing API, there there is the question
> of how do we handle backward compatibility? By doing this change, will we
> be creating other issues?
>
> I'm not sure why the subnet needed to be specified in the service API,
> unless the assumption was that there would only be one subnet for all
> connections on the service. Anyone know why? I don't think it is used,
> until you make a connection.
>
> Please express your thoughts!
>
> Paul Michali (pc_m)
>
> [1] https://wiki.strongswan.org/projects/strongswan/wiki/ConnSection
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> 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/20150520/86e4c253/attachment.html>