Thanks for your review Vijay 1. Pass-Info is for the backend. Used for informing the Back-End regarding SSL termination details. 2. Added cipher-suites groups 3. Added default policy 4. Added SNI support. I think our model should support it, since EC2 supports it. 5. Renamed "Trusted Key" to "Trusted Certificate". I thought CA is obvious, "Back-End Certificate" is an option too, What do you think? 6. Renamed Certificate's public key to certificate.
Regards, Evg -----Original Message----- From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com] Sent: Wednesday, December 11, 2013 2:05 PM To: OpenStack Development Mailing List (not for usage questions) Cc: Abhishek Gautam Subject: Re: [openstack-dev] [Neutron][LBaaS] Vote required for certificate as first-class citizen - SSL Termination (Revised) Thanks for the detailed write-up Evg. What is the use of SSLPolicy.PassInfo? Managing as individual ciphers is a pain, Can we introduce an entity called cipher groups? This enables to provide built-in cipher groups (HIGH, LOW, DES etc) as well. At the least we can provide this in the UI+CLI layer. Also, it will be good to have a built-in DEFAULT ssl policy, which contains default set of SSL protocols, ciphers etc. which is to be used when sslpolicy is not provided. Is there a need for binding multiple certificates for a VIP, because SNI is not modeled now? We could have vip_id as the key in vip_ssl_certificate_assoc. Also, it will be good to have the following nomenclature corrected: TrustedKey: This entity refers to a CA certificate, usage key can be avoided. My suggestion is to call it CA or cacert. SSLCertificate.PublicKey: The property contains a server certificate (actually PublicKey + more info). My suggestion is to call the property as certificate Thanks, Vijay V. > -----Original Message----- > From: Evgeny Fedoruk [mailto:evge...@radware.com] > Sent: Sunday, December 08, 2013 10:24 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Neutron][LBaaS] Vote required for > certificate as first-class citizen - SSL Termination (Revised) > > Hi All. > The wiki page for LBaaS SSL support was updated. > Please see and comment > https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL#Vip_SSL_Association > > Thank you! > Evg > > -----Original Message----- > From: Samuel Bercovici > Sent: Thursday, December 05, 2013 9:14 PM > To: OpenStack Development Mailing List (not for usage questions) > Cc: Evgeny Fedoruk; Samuel Bercovici > Subject: RE: [openstack-dev] [Neutron][LBaaS] Vote required for > certificate as first-class citizen - SSL Termination (Revised) > > Correct. > > Evgeny will update the WIKI accordingly. > We will add a flag in the SSL Certificate to allow specifying that the > private key can't be persisted. And in this case, the private key > could be passed when associating the cert_id with the VIP. > > Regards, > -Sam. > > -----Original Message----- > From: Nachi Ueno [mailto:na...@ntti3.com] > Sent: Thursday, December 05, 2013 8:21 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Neutron][LBaaS] Vote required for > certificate as first-class citizen - SSL Termination (Revised) > > Hi folks > > OK, It looks like we get consensus on > separate resource" way. > > Best > Nachi > > 2013/12/5 Eugene Nikanorov <enikano...@mirantis.com>: > > Hi, > > > > My vote is for separate resource (e.g. 'New Model'). Also I'd like > > to see certificate handling as a separate extension/db mixing(in > > fact, persistence > > driver) similar to service_type extension. > > > > Thanks, > > Eugene. > > > > > > On Thu, Dec 5, 2013 at 2:13 PM, Stephen Gran > > <stephen.g...@theguardian.com> > > wrote: > >> > >> Hi, > >> > >> Right, sorry, I see that wasn't clear - I blame lack of coffee :) > >> > >> I would prefer the "Revised New Model". I much prefer the ability > >> to restore a loadbalancer from config in the event of node failure, > >> and the ability to do basic sharing of certificates between VIPs. > >> > >> I think that a longer term plan may involve putting the > >> certificates in a smarter system if we decide we want to do things > >> like evaluate trust models, but just storing them locally for now > >> will do most of what I think people want to do with SSL termination. > >> > >> Cheers, > >> > >> > >> On 05/12/13 09:57, Samuel Bercovici wrote: > >>> > >>> Hi Stephen, > >>> > >>> To make sure I understand, which model is fine "Basic/Simple" or "New". > >>> > >>> Thanks, > >>> -Sam. > >>> > >>> > >>> -----Original Message----- > >>> From: Stephen Gran [mailto:stephen.g...@theguardian.com] > >>> Sent: Thursday, December 05, 2013 8:22 AM > >>> To: openstack-dev@lists.openstack.org > >>> Subject: Re: [openstack-dev] [Neutron][LBaaS] Vote required for > >>> certificate as first-class citizen - SSL Termination (Revised) > >>> > >>> Hi, > >>> > >>> I would be happy with this model. Yes, longer term it might be > >>> nice to have an independent certificate store so that when you > >>> need to be able to validate ssl you can, but this is a good intermediate > >>> step. > >>> > >>> Cheers, > >>> > >>> On 02/12/13 09:16, Vijay Venkatachalam wrote: > >>>> > >>>> > >>>> LBaaS enthusiasts: Your vote on the revised model for SSL Termination? > >>>> > >>>> Here is a comparison between the original and revised model for > >>>> SSL > >>>> Termination: > >>>> > >>>> *************** > >>>> Original Basic Model that was proposed in summit > >>>> *************** > >>>> * Certificate parameters introduced as part of VIP resource. > >>>> * This model is for basic config and there will be a model > >>>> introduced in future for detailed use case. > >>>> * Each certificate is created for one and only one VIP. > >>>> * Certificate params not stored in DB and sent directly to loadbalancer. > >>>> * In case of failures, there is no way to restart the operation > >>>> from details stored in DB. > >>>> *************** > >>>> Revised New Model > >>>> *************** > >>>> * Certificate parameters will be part of an independent > >>>> certificate resource. A first-class citizen handled by LBaaS plugin. > >>>> * It is a forwarding looking model and aligns with AWS for > >>>> uploading server certificates. > >>>> * A certificate can be reused in many VIPs. > >>>> * Certificate params stored in DB. > >>>> * In case of failures, parameters stored in DB will be used to > >>>> restore the system. > >>>> > >>>> A more detailed comparison can be viewed in the following link > >>>> > >>>> > https://docs.google.com/document/d/1fFHbg3beRtmlyiryHiXlpWpRo1oWj8F > >>>> qVe > >>>> ZISh07iGs/edit?usp=sharing > >> > >> > >> -- > >> Stephen Gran > >> Senior Systems Integrator - theguardian.com Please consider the > >> environment before printing this email. > >> ------------------------------------------------------------------ > >> Visit theguardian.com > >> On your mobile, download the Guardian iPhone app > theguardian.com/iphone > >> and our iPad edition theguardian.com/iPad Save up to 33% by subscribing > to > >> the Guardian and Observer - choose the papers you want and get full > >> digital access. > >> Visit subscribe.theguardian.com > >> > >> This e-mail and all attachments are confidential and may also be > >> privileged. If you are not the named recipient, please notify the > >> sender and delete the e-mail and all attachments immediately. > >> Do not disclose the contents to another person. You may not use the > >> information for any purpose, or store, or copy, it in any way. > >> > >> Guardian News & Media Limited is not liable for any computer > >> viruses or other material transmitted with or as part of this > >> e-mail. You should employ virus checking software. > >> > >> Guardian News & Media Limited > >> > >> A member of Guardian Media Group plc Registered Office PO Box 68164 > >> Kings Place > >> 90 York Way > >> London > >> N1P 2AP > >> > >> Registered in England Number 908396 > >> > >> ------------------------------------------------------------------- > >> -- > >> ----- > >> > >> > >> _______________________________________________ > >> OpenStack-dev mailing list > >> OpenStack-dev@lists.openstack.org > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev