Open Stack

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.Venkatachalam at 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:EvgenyF at 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:nachi at 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 <enikanorov at 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.gran at 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.gran at theguardian.com]
> >>> Sent: Thursday, December 05, 2013 8:22 AM
> >>> To: openstack-dev at 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 at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev