Open Stack

Replies Inline!



> -----Original Message-----
> From: Evgeny Fedoruk [mailto:EvgenyF at Radware.com]
> Sent: Thursday, December 12, 2013 5:56 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)
> 
> Thanks for your review Vijay
> 
> 1. Pass-Info is for the backend. Used for informing the Back-End regarding
> SSL termination details.

Will SSL Termination details be passed through HTTP headers? If so, what will be the http header names? 
Also "ssl_policy.pass_info"  is a string, how does it work?
	
Do you see a strong use case? Otherwise this can be skipped for phase-1.

> 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?


"Trusted Certificate" seems fine. 

"ssl_trusted_key (new)" datamodel and its properties are still not changed. You might want to rename ssl_trusted_key* => ssl_trusted_certificate*
ssl_trusted_key_id  also can be renamed

> 6. Renamed Certificate's public key to certificate.
> 
There are still keys used in place of certificate

public_key : PEM-formatted string

> 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
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev