Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150513/912e47d0/attachment.html>