+1 I agree. Lets focus on client SSL Termination at LB for Juno release. Thanks, Vivek
From: <Eichberger>, German <german.eichber...@hp.com<mailto:german.eichber...@hp.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Thursday, May 22, 2014 at 12:53 PM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@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:samu...@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.
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
