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 <p...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
