[openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit

Stephen Balukoff sbalukoff at bluebox.net
Tue Jun 10 20:11:39 UTC 2014

Hi Evgeny,

Comments inline.

On Tue, Jun 10, 2014 at 4:13 AM, Evgeny Fedoruk <EvgenyF at radware.com> wrote:

>  Hi All,
> Carlos, Vivek, German, thanks for reviewing the RST doc.
> There are some issues I want to pinpoint final decision on them here, in
> ML, before writing it down in the doc.
> Other issues will be commented on the document itself.
> 1.       Support/No support in JUNO
> Referring to summit’s etherpad
> https://etherpad.openstack.org/p/neutron-lbaas-ssl-l7,
> a.       SNI certificates list was decided to be supported. Was decision
> made not to support it?
> Single certificate with multiple domains can only partly address the need
> for SNI, still, different applications
> on back-end will need different certificates.
SNI support is a "show stopper" for us if it's not there. We have too many
production services which rely on SNI working for us not to have this
feature going forward.

I'm not sure I understand what you're proposing when you say "Single
certificate with multiple domains can only partly address the need for SNI,
still, different applications on back-end will need different certificates."

In order to "fully" support SNI, you simply need to be able to specify
alternate certificate/key(s) to use indexed by the hostname with which the
non-default certificate(s) correspond. And honestly, if you're going to
implement TLS termination support at all, then adding SNI is a pretty
trivial next step.

 b.      Back-end re-encryption was decided to be supported. Was decision
> made not to support it?
So, some operators have said they need this eventually, but I think the
plan was to hold off on both re-encryption and any kind of client
certificate authentication in this release cycle.  I could be remembering
the discussion on this incorrectly, though, so others should feel free to
correct me on this.

 c.       With front-end client authentication and back-end server
> authentication not supported,
> Should certificate chains be supported?
Certificate chains are a different beast entirely. What I mean by that is:
 Any given front-end (ie. "server") certificate issued by an authoritative
CA today may need intermediate certificates supplied for most browsers to
trust the issued certificate implicitly. (Most do, in my experience.)
Therefore, in order to effectively do TLS offload at all, we need to be
able to supply an intermediate CA chain which will be supplied with the
server cert when a client connects to the service.

If you're talking about the CA bundle or chain which will be used to verify
client certificates when we offer that feature...  then no, we don't need
that until we offer the feature.

>  2.       Barbican TLS containers
> a.       TLS containers are immutable.
> b.      TLS container is allowed to be deleted, always.
>                                                                i.      Even
> when it is used by LBaaS VIP listener (or other service).
>                                                              ii.      Meta
> data on TLS container will help tenant to understand that container is in
> use by LBaaS service/VIP listener
>                                                             iii.      If
> every VIP listener will “register” itself in meta-data while retrieving
> container, how that “registration” will be removed when VIP listener stops
> using the certificate?

So, there's other discussion of these points in previous replies in this
thread, but to summarize:

* There are multiple strategies for handling barbican container deletion,
and I favor the one suggested by Adam of creating "shadow" versions of any
referenced containers. I specifically do not like the one which allows for
dangling references, as this could mean the associated listener breaks
weeks or months after the barbican container was deleted (assuming no
eventing system is used, which it sounds like people are against.)

* Meta data on container is a good idea, IMO. Perhaps we might consider
simply leaving "generic" meta-data which is essentially a note to the
barbican system, or any GUI referencing the cert to check with the LBaaS
service to see which listeners are using the cert?  This wouldn't need to
be cleaned up, because if the container actually isn't in use by LBaaS
anymore, then LBaaS would simply respond that nothing is using the cert

> Please comment on these points and review the document on gerrit (
> https://review.openstack.org/#/c/98640)
> I will update the document with decisions on above topics.

I shall try to make sure I have time to review the document later today or


Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140610/2be02256/attachment.html>

More information about the OpenStack-dev mailing list