Open Stack

Evgeny--

Two minor nits:

* Your spec lists the new SNI related settings 'sni_list' (and it contains
more than just IDs, so calling it 'sni_container_ids_list' is misleading).
Please be precise in the terms you use, and don't switch them mid
discussion. :)
* Also, I personally really hate long table names when they're unnecessary.
"vipsniassociations" isn't mentioned in your spec anywhere, and frankly, is
a lot worse than "sni_list." I personally prefer "SNIPolicies", but I'm
also OK with a short name like "sni_list".

Otherwise I agree with you on all points.

Stephen





On Tue, Jun 24, 2014 at 3:26 AM, Evgeny Fedoruk <EvgenyF at radware.com> wrote:

>  Vijay, there is no intension for a new TLS settings API.
>
> Creation of a listener with TLS offloading will be one-step.
>
>
>
> When tenant creates listener with TERMINATED-HTTPS protocol he must supply
> default_tls_container_id for offloading.
>
> Not supplying default TLS container id for offloading for TERMINATED-HTTPS
> listener will raise an error.
>
> SNI list may or may not be supplied by the tenant. Default value for SNI
> certificates list is an empty list.
>
>
>
> So listener resource will have another two attributes:
> default_tls_container_id and sni_container_ids_list. These are relevant for
> TERMINATED-HTTPS protocol listeners only. In other cases its default value
> are ‘None’ and empty list.
>
> In schema, Default_tls_container_id will be added to listener object as
> another column.
>
> Sni_container_ids_list wil be managed by new table “vipsniassociations”
> which has listener_id, container_id, and position (for ordering) columns
>
>
>
> Does it make sense?
>
>
>
> Thanks,
>
> Evg
>
>
>
>
>
>
>
>
>
> *From:* Vijay Venkatachalam [mailto:Vijay.Venkatachalam at citrix.com]
> *Sent:* Tuesday, June 24, 2014 12:31 PM
>
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Neutron][LBaaS] Should TLS settings for
> listener be set through separate API/model?
>
>
>
>
>
> To clarify, the request is for a new TLS settings API with
> “default_tls_container_id” & “sni_list”.
>
>
>
> If there is a new API, then we would have an object model reflecting this
> as a separate entity.
>
>
>
> The tenant would do the following
>
>
>
> 1.       Create a listener with TERMINATED_HTTPS
>
> 2.       Set the TLS settings for the listener using
> /v2.0/listener/<listenerid>/tlssettings  (if at all we are having some
> default values this can be reflected here)
>
>
>
> The only good thing is the separation of the TLS settings out of the
> listener API.
>
>
>
> But, I can see 2 downsides
>
> 1.       The loadbalancer creation is a 2 step procedure
>
> 2.       We cannot enforce certificate attachment as part of the create
> of listener.
>
>
>
> If the new API itself has “-1”s then I am perfectly OK with the current
> object model with default_tls_container_id in listener table.
>
>
>
> Thanks,
>
> Vijay V.
>
>
>
>
>
> *From:* Evgeny Fedoruk [mailto:EvgenyF at Radware.com <EvgenyF at Radware.com>]
> *Sent:* Tuesday, June 24, 2014 2:19 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Neutron][LBaaS] Should TLS settings for
> listener be set through separate API/model?
>
>
>
> Vipsniassociations table: Line 147 in last patch of the document
>
>
>
> *From:* Vijay Venkatachalam [mailto:Vijay.Venkatachalam at citrix.com
> <Vijay.Venkatachalam at citrix.com>]
> *Sent:* Tuesday, June 24, 2014 10:17 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Neutron][LBaaS] Should TLS settings for
> listener be set through separate API/model?
>
>
>
>
>
> >>SNI list is managed by separate entity
>
> What is this entity?
>
>
>
> *From:* Evgeny Fedoruk [mailto:EvgenyF at Radware.com <EvgenyF at Radware.com>]
> *Sent:* Tuesday, June 24, 2014 12:25 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Neutron][LBaaS] Should TLS settings for
> listener be set through separate API/model?
>
>
>
> +1 for option 1. SNI list is managed by separate entity, default TLS
> container is part of a listener object. It will have None value when
> listener does not offloads TLS.
>
> Managing another entity for 1:0-1 relationship just for future use seems
> not right to me. Breaking TLS settings apart from listener can be done when
> needed, if needed.
>
>
>
> Thanks,
>
> Evg
>
>
>
>
>
> *From:* Stephen Balukoff [mailto:sbalukoff at bluebox.net
> <sbalukoff at bluebox.net>]
> *Sent:* Tuesday, June 24, 2014 4:26 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Neutron][LBaaS] Should TLS settings for
> listener be set through separate API/model?
>
>
>
> Ok, so we've got opinions on both sides of the argument here. I'm actually
> pretty ambivalent about it. Do others have strong opinions on this?
>
>
>
> On Mon, Jun 23, 2014 at 6:03 PM, Doug Wiegley <dougw at a10networks.com>
> wrote:
>
> Put me down for being in favor of option 1.
>
>
>
> A single attribute in a 1:1 relationship?  Putting that in a new table
> sounds like premature optimization to me; design the database change for
> the future feature when you can see the spec for it.
>
>
>
> Thanks,
>
> Doug
>
>
>
>
>
> *From: *Stephen Balukoff <sbalukoff at bluebox.net>
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" <openstack-dev at lists.openstack.org>
> *Date: *Monday, June 23, 2014 at 5:25 PM
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> *Subject: *Re: [openstack-dev] [Neutron][LBaaS] Should TLS settings for
> listener be set through separate API/model?
>
>
>
> Also to add to pros for 2:
>
>
>
> * Keeping the TLS stuff contained to its own objects means we can have
> separate development resources on each and not worry as much about
> overlapping domains. (TLS-related knowledge and knowledge of dealing with
> TCP / UDP listeners are separate knowledge domains. Or at least, the former
> is a more specialized subset of the latter.)
>
>
>
> Note that what we're proposing means there's essentially a 1:0-1
> relationship between Listener and this new yet-to-be-named object. (0 in
> case the Listener is not terminating TLS.)
>
>
>
> Stephen
>
>
>
> On Mon, Jun 23, 2014 at 3:38 PM, Brandon Logan <
> brandon.logan at rackspace.com> wrote:
>
> Whoops, [Neutron][LBaaS] got taken out of the subject line here.
> Putting it back in.
>
>
> On Mon, 2014-06-23 at 21:10 +0000, Brandon Logan wrote:
> > Okay so we've talked a bit about this in IRC and now I'm sending this
> > out as an update.  Here are the options with pros and cons that have
> > come from that discussion.
> >
> > 1) default_certificate_id is an attribute of the Listener object.
> >
> > Pros:
> > -No extra entity needed
> >
> > Cons:
> > -May bloat Listener object when more attributes are needed for only TLS
> > termination.  Sounds like TLS version and cipher selection will be
> > needed attributes in the future.
> >
> >
> > 2) A separate TLS Entity is created that is referenced by the Listener
> > object.  This entity at first may only contain a certificate_id that
> > references barbican.  Name and description can be allowed as well.
> >
> > Pros:
> > -TLS domain specific attributes contained in its own entity
> > -Future attributes would just be added to this entity and not bloat the
> > Listener object.
> >
> > Cons:
> > -It's another entity
> >
> > In IRC we (sbalukoff, myself) seemed to agree option 2 is right way to
> > go.  Anyone agree or disagree?
> >
> > Thanks,
> > Brandon
> >
> > On Mon, 2014-06-23 at 12:15 -0700, Stephen Balukoff wrote:
> > > The separate entity makes sense for certificates participating in an
> > > SNI configuration, but probably not so much for the 'default'
> > > certificate used when TLS is being terminated.
> > >
> > >
> > > Vijay: You're also right that other TLS-related attributes will
> > > probably get added to the Listener object. This probably makes sense
> > > if they apply to the Listener object as a whole. (This includes things
> > > like TLS version and cipher selection.)
> > >
> > >
> > > I don't see much of a point in creating a separate object to contain
> > > these fields, since it would have a 1:1 relationship with the
> > > Listener. It's true that for non-TLS-terminated Listeners, these
> > > fields wouldn't be used, but isn't that already the case in many other
> > > objects (not just in the Neutron LBaaS sub project)?
> > >
> > >
> > > Thanks,
> > > Stephen
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Mon, Jun 23, 2014 at 9:54 AM, Brandon Logan
> > > <brandon.logan at rackspace.com> wrote:
> > >         Vijay,
> > >         I think the separate entity is still going to happen.  I don't
> > >         think it
> > >         has remvoed.  Or that is may just be my assumption.
> > >
> > >         Thanks,
> > >         Brandon
> > >
> > >         On Mon, 2014-06-23 at 15:59 +0000, Vijay Venkatachalam wrote:
> > >         > Hi:
> > >         >
> > >         >
> > >         > In the “LBaaS TLS termination capability specification”
> > >         proposal
> > >         >
> > >         > https://review.openstack.org/#/c/98640/
> > >         >
> > >         > TLS settings like default certificate container id and SNI
> > >         cert list are part of the listener properties.
> > >         >
> > >         > I think it is better to have this as a separate entity so
> > >         that the listener properties are clean and is not “corrupted”
> > >         with TLS settings.
> > >         >
> > >         > I liked the original SSL proposal better where TLS settings
> > >         was a separate entity.
> > >         >
> > >         > It is just 2 properties now but in future the TLS settings
> > >         would grow and if we are going to introduce a TLS
> > >         profile/params/settings entity later, it is better to do it
> > >         now (albeit with min properties).
> > >         >
> > >         > Thanks,
> > >         > Vijay V.
> > >
> > >         > _______________________________________________
> > >         > 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
> > >
> > >
> > >
> > >
> > > --
> > > Stephen Balukoff
> > > Blue Box Group, LLC
> > > (800)613-4305 x807
> > > _______________________________________________
> > > 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
>
>
>
>
>
> --
> Stephen Balukoff
> Blue Box Group, LLC
> (800)613-4305 x807
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>
> --
> Stephen Balukoff
> Blue Box Group, LLC
> (800)613-4305 x807
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140624/8981f738/attachment.html>