VPNaaS: Certificate support for IPSec

[Paul Michali]

Problem: Currently, when creating VPN IPSec site-to-site connections, the end user can only create tunnels using pre-shared keys for authentication. There is no way to use (the far superior) certificates, which are preferred for production environments.

Solution: We can leverage off of Barbican to add certificate support for VPNaaS IPSec connections.

Importance: Adding support for specifying certificates, will help with the acceptance and deployment of the VPNaaS feature.

[Paul Michali (pcm)]

I can work on this, if/when approved by drivers team.

[Armando Migliaccio (armando-migliaccio)]

Guidelines, details on how to write RFE's, and the process for handling features if you have already submitted specs in the past, but are yet to be complete. can be found here:

https://github.com/openstack/neutron/blob/master/doc/source/policies/blueprints.rst

For more details, please reach out on #openstack-neutron or openstack-dev ML [neutron].

[Paul Michali (pcm)]

@Armando, I'm trying to (already) follow the new RFE process. This is a new request, and not an existing blueprint/spec. Am I missing anything needed for an RFE?

If/when approved, I can sign-up for this and provide spec (if needed) and code.

[Kyle Mestery (mestery)]

Paul from this [1], you should change the description around the below. As written, this isn't a good RFE. That is only meant to convey where we're hoping to get this process to. It's a new process, so we'll all work together to make it better.

In other words, when you write an RFE you should ask yourself the following questions:

What is that I (specify what user - a user can be a human or another system) cannot do today when interacting with Neutron? On the other hand, is there a Neutron component X that is unable to accomplish something?
Is there something that you would like Neutron handle better, ie. in a more scalable, or in a more reliable way?
What is that I would like to see happen after the RFE is accepted and implemented?
Why do you think it is important?
Once you are happy with what you wrote, add 'rfe' as tag, and submit. Do not worry, we are here to help you get it right! Happy hacking.

[1] https://github.com/openstack/neutron/blob/master/doc/source/policies/blueprints.rst#rfe-submission-guidelines

[Paul Michali (pcm)]

I'll update the description. When I wrote the RFE, the submission
guidelines weren't available (at least when I checked just before
submitting).

On Tue, Jun 2, 2015 at 12:46 PM Kyle Mestery <email address hidden>
wrote:

> Paul from this [1], you should change the description around the below.
> As written, this isn't a good RFE. That is only meant to convey where
> we're hoping to get this process to. It's a new process, so we'll all
> work together to make it better.
>
> In other words, when you write an RFE you should ask yourself the
> following questions:
>
> What is that I (specify what user - a user can be a human or another
> system) cannot do today when interacting with Neutron? On the other hand,
> is there a Neutron component X that is unable to accomplish something?
> Is there something that you would like Neutron handle better, ie. in a
> more scalable, or in a more reliable way?
> What is that I would like to see happen after the RFE is accepted and
> implemented?
> Why do you think it is important?
> Once you are happy with what you wrote, add 'rfe' as tag, and submit. Do
> not worry, we are here to help you get it right! Happy hacking.
>
> [1]
>
> https://github.com/openstack/neutron/blob/master/doc/source/policies/blueprints.rst
> #rfe-submission-guidelines
> <https://github.com/openstack/neutron/blob/master/doc/source/policies/blueprints.rst#rfe-submission-guidelines>
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1459427
>
> Title:
> VPNaaS: Certificate support for IPSec
>
> Status in OpenStack Neutron (virtual network service):
> New
>
> Bug description:
> Since Barbican provides certificate management/storage, and LBaaS has
> successfully used the certificates, this RFE proposes to provide
> certificate support for VPN IPSec site-to-site connections.
>
> The expectation is that the user would use Barbican to create the
> certificate, and then reference the certificate when creating an IPSec
> connection.
>
> This would require an REST/CLI API change to accept certificate ID vs
> PSK, minor database change to store the certificate ID, *Swan driver
> modifications to apply the certificate to the template, and
> unit/functional test updates for these changes.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/neutron/+bug/1459427/+subscriptions
>

[Paul Michali (pcm)]

The description is updated. Please let me know if there is more information needed.

[Paul Michali (pcm)]

One question is on which certificate types to support in addition to X.509, if any. Thoughts? The *Swan implementations seem to support several types. Asking on ML.

[Paul Michali (pcm)]

Additionally, the thought here was to peel out the authentication parameter from the IPSec site-to-site connection create API, and instead have a new "authentication credentials" API that would allow the selection of the type of authentication (initially PSK and X.509 certificates). The IPSec site-to-site connection API could then reference the authentication credential ID, thus allowing these credentials to be used for more than one IPSec connection, and to use the mechanism for more than one type of VPN service.

Thought here would be to include this information in the authentication credentials resource:
    id - UUID
    name - String (255)
    description - String (255)
    auth_type - Enum (psk, x509)
    cert_id - UUID
    passphrase - String(255)

The thought is that the cert_id would be used for X.509 and refer to the Barbican ID. The passphrase could be used for pre-shared keys(PSK), and with X.509 (optionally) as a passphrase for certificates.

Is there a better organization for these last three fields?

For CLI client, we could have:

vpn-auth-credential-list
vpn-auth-credential-delete <UUID>
vpn-auth-credential-show <UUID>
vpn-auth-credential-create [--name <string>] [--description <string>] XXX

For XXX, we need to be able to select the type, certificate UUID (if X.509), and passphrase (optional for X.509). I'm not sure what way to propose these items. One could be:

--type {psk --passphrase <string> | x509 --cert-id <UUID> [--passphrase <string>] }

Maybe another is specifying as a dictionary using the option --info, as in (examples shown):

--info type=psk,passphrase="secret"
--info type=x509,cert=1af89...,passphrase="secret"

The passphrase would be optional on the x509 type. Another would be without the type being an option (examples show):

psk --passphrase="secret"
x509 --cert-id=8f8ea43... --passphrase="secret"

Again, passphrase would be optional for the X509 certificate.

Are there any other ideas for handling the database layout, and the CLI API?

Does the approach of separating out the authentication credentials from the IPSec connection make sense?

Can there be options after arguments?

[Paul Michali (pcm)]

More questions...

Currently, with VPN, when one does a ipsec-site-connection-show UUID, the pre-shared key (PSK) value is shown. I take it that it would be OK to show that (and the certification passphrase, if any) in the vpn-auth-credential-show?

Also, currently, the PSK in the REST API is shown as a string w/o secret=True. I take it that for the new authentication credentials REST API definition, we should use secret=True for the passphrase? Is anything done in the database field definitions? I didn't see anything for other passwords in neutron.

When deleting an authentication credential, should we give the option (--all? --purge? --delete-certificate?) to also remove the certificate from Barbican, or make the user handle that separately (with Barbican commands)?

When applying the certificate in the device driver, it looks like *Swan requires a certificate file to be provided. I was thinking I could create a temp file as part of the namespace with the certificate, and provide that to the template used for the *Swan config file. Once started, I could see two variations here, but not sure if they both will work.

One is to keep the certificate file, and when the connection is deleted the namespace is deleted and files removed, so the file will be gone. This is not as secure, as the file is in the file system of the host for a period of time.

Another is to delete the certificate file, after *Swan has been started up. This is more secure, but I'm not sure it'll work.

The question (finally) is what happens if a connection is modified? I don't know if *Swan will delete the connection and then recreate it with the changes, or if it just updates the config file and then does a restart of the process. If the latter (and I think it may be) then the second solution will not work, unless we change it to do a delete/create (this is what is done in the Cisco driver, BTW). Thoughts?

[Kyle Mestery (mestery)]

Moving to confirmed. I think the idea of integrating with barbican for certificate usage is a good idea. I would suggest talking to Phil from the LBaaS team, as I believe he did the work there to integrate LBaaS with barbican.

[Paul Michali (pcm)]

Thanks for the pointer. I have been talking to Doug and Brandon to get some pointers on what was done for the Listeners in LBaaS.

[Paul Michali (pcm)]

Very useful feature for VPNaaS so that it can be production usable, IMHO. Needs assignee.

[Armando Migliaccio (armando-migliaccio)]

If someone is not working on it, this is probably gonna die on the vine

[Armando Migliaccio (armando-migliaccio)]

Lack of resources.

[Launchpad Janitor (janitor)]

[Expired for neutron because there has been no activity for 60 days.]

[Jan Vondra (janvondra)]

Any update with the issue? Barbican seems ready to be used as certificate storage and it would be nice to have a certificate based IPSec VPN.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/515328

[OpenStack Infra (hudson-openstack)]

Change abandoned by Slawek Kaplonski (<email address hidden>) on branch: master
Review: https://review.opendev.org/515328
Reason: According to what we agreed during Shanghai PTG, I abandon this patch for now due to no activity. If You would be interested in continue work on this, feel free to restore the patch.

[Lajos Katona (lajos-katona)]

Closing this now, as it was inactive for years, feel free to reopen and propose patches if you need this feature.