<div dir="ltr"><div><div><div><div>Hi paul,<br><br></div>this is also something that we would like to introduce for BGP/MPLS VPNs [2].<br><br></div>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.<br><br></div>So I think that Option B is suitable here.<br><br></div>Concerning backward compatibility, I think VPNaas is still considered as experimental, am I wrong? Do you have to provide backward compatbility in this case?<br><div><div><br></div><div>Mathieu<br></div><div><br>[2] <a href="https://review.openstack.org/#/c/177740/">https://review.openstack.org/#/c/177740/</a><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 13, 2015 at 8:59 PM, Paul Michali <span dir="ltr"><<a href="mailto:pc@michali.net" target="_blank">pc@michali.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>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).</div><div><br></div><div>I'm raising the question again with these goals:</div><div><br></div><div>1) Determine if the reference IPSec implementations support this capability</div><div>2) Determine if there is a community desire to enhance VPN to support this capability (for all VPN types)</div><div>3) See what would be the best way to handle this (changes to API and model)</div><div>4) Identify any consequences of making this change.</div><div><br></div><div>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.</div><div><br></div><div>Here is some information that was gathered from people on the VPN team so far. Please correct any inaccuracies and comment on the items...</div><div><br></div><div>(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].</div><div><br></div><div>(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)?</div><div><br></div><div>(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:</div><div><br></div><div><div>usage: neutron vpn-service-create [-h] [-f {html,json,shell,table,value,yaml}]</div><div> [-c COLUMN] [--max-width <integer>]</div><div> [--prefix PREFIX]</div><div> [--request-format {json,xml}]</div><div> [--tenant-id TENANT_ID] [--admin-state-down]</div><div> [--name NAME] [--description DESCRIPTION]</div><div> ROUTER SUBNET</div></div><div><br></div><div><div>usage: neutron ipsec-site-connection-create [-h]</div><div> [-f {html,json,shell,table,value,yaml}]</div><div> [-c COLUMN]</div><div> [--max-width <integer>]</div><div> [--prefix PREFIX]</div><div> [--request-format {json,xml}]</div><div> [--tenant-id TENANT_ID]</div><div> [--admin-state-down] [--name NAME]</div><div> [--description DESCRIPTION]</div><div> [--mtu MTU]</div><div> [--initiator {bi-directional,response-only}]</div><div> [--dpd action=ACTION,interval=INTERVAL,timeout=TIMEOUT]</div><div> --vpnservice-id VPNSERVICE</div><div> --ikepolicy-id IKEPOLICY</div><div> --ipsecpolicy-id IPSECPOLICY</div><div> --peer-address PEER_ADDRESS</div><div> --peer-id PEER_ID --peer-cidr</div><div> PEER_CIDRS --psk PSK</div></div><div><br></div><div>I could envision several ways to handle this (feel free to add more). Here are some thoughts on this...<br></div><div><br></div><div>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.</div><div><br></div><div>vpn-service-create ... ROUTER LOCAL_CIDRS</div><div><br></div><div>Issue here is that, if a change is desired on a subnet for a specific connection, the service must be updated.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div>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.</div><div><br></div><div>ipsec-site-connection ... LOCAL_CIDRS PEER_CIDRS ...</div><div><br></div><div>This seems better, as different types of VPN can decide if they want to support this capability and implement their connection API accordingly.</div><div><br></div><div>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.</div><div><br></div><div>C) Hybrid of A&B, keep the subnet on the vpn service API, and allow the connection API to (optionally) add additional subnets.</div><div><br></div><div>vpn-service-create ROUTER SUBNET</div><div>ipsec-site-connection ... LOCAL_CIDRS PEER_CIDRS ...</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>(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?</div><div><br></div><div>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.</div><div><br></div><div>Please express your thoughts!</div><div><br></div><div>Paul Michali (pc_m)</div><div><br></div><div>[1] <span style="color:rgb(0,0,0);line-height:normal;white-space:pre-wrap"><a href="https://wiki.strongswan.org/projects/strongswan/wiki/ConnSection" target="_blank">https://wiki.strongswan.org/projects/strongswan/wiki/ConnSection</a></span></div><div><span style="color:rgb(0,0,0);line-height:normal;white-space:pre-wrap"><br></span></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>