Open Stack

Extra subnets is suitable for attribute of IKE connections, but not
the whole VPN service. Because customer usually want fine-grained
control of which local subnet could communicate to remote subnets.

On Wed, May 20, 2015 at 11:21 PM, Mathieu Rohon <mathieu.rohon at gmail.com> wrote:
> However after thinking about it more deeply, option A might be suitable if
> the vpn-service becomes more generic, and usable by other vpn objects
> (ipsec-site-connection, bgpvpn-connection....).
> I would become an object that the tenant can update to attach CIDR it wants
> to export in its VPN.
> To transform the vpn-service object in a generic vpn description, we need to
> remove the mandatory ROUTER attribute, so that we can use it for l2vpn
> either.
>
> Hope we can discuss that on friday morning
>
> On Wed, May 20, 2015 at 5:12 PM, Paul Michali <pc at michali.net> wrote:
>>
>> Hi Mathieu,
>>
>> In Kilo, VPNaaS APIs were no longer marked as experimental. We need to
>> understand the implication of changing the API. I'm not sure how much VPNaaS
>> is being used by OpenStack users at this time, either.  I'm hoping to seek
>> out answers to this at the summit.
>>
>> If anyone has suggestions, comments, information on this, please chime in.
>> I'll likely make a BP for multiple subnets, when I get back from the summit.
>>
>> Lastly, I'm planning on trying to get people interested in VPN to meet on
>> Friday morning at the summit to discuss all the VPN topics that have been
>> coming up.
>>
>> Regards,
>>
>> Paul Michali (pc_m)
>>
>> On Wed, May 20, 2015 at 7:54 AM Mathieu Rohon <mathieu.rohon at gmail.com>
>> wrote:
>>>
>>> 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
>>>>
>>>
>>>
>>> __________________________________________________________________________
>>> 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
>>
>>
>> __________________________________________________________________________
>> 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
>>
>
>
> __________________________________________________________________________
> 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
>