Open Stack

+1
I agree. Lets focus on client SSL Termination at LB for Juno release.

Thanks,
Vivek

From: <Eichberger>, German <german.eichberger at hp.com<mailto:german.eichberger at hp.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Thursday, May 22, 2014 at 12:53 PM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron][LBaaS]TLS API support for authentication

Hi Sam,

I totally agree – this will definitely reduce our scope and increase the chance of getting this in.

I am still (being influenced by Unix methodology) thinking that we should explore service chaining more for that. As I said earlier, re-encryption feels more like a VPN type thing than a load balancer. Hence, I can imagine a very degenerated VPN service which re-encrypts things with SSL. But, admittedly, I am looking at that as a software engineer and not a network engineer :)

German

From: Samuel Bercovici [mailto:SamuelB at Radware.com]
Sent: Thursday, May 22, 2014 11:44 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron][LBaaS]TLS API support for authentication

Hi Everone,

I would like to defer addressing client authentication and back-end-server authentication for a 2nd phase – after Juno.
This means that from looking on https://etherpad.openstack.org/p/neutron-lbaas-ssl-l7 , under the “SSL/TLS Termination capabilities”, not addressing 2.2 and 3.
I think that this would reduce the “effort” of storing certificates information to the actual ones used for the termination.
We will leave the discussion on storing the required trusted certificates and CA chains for later.

Any objections?

Regards,
            -Sam.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140523/2eb373a2/attachment.html>