Open Stack

Hi Vijay,



On Wed, Jul 16, 2014 at 9:07 AM, Vijay Venkatachalam <
Vijay.Venkatachalam at citrix.com> wrote:

>
>
> Do you know if the SSL/SNI IETF spec details about conflict resolution. I
> am assuming not.
>
>
>
> Because of this ambiguity each backend employs its own mechanism to
> resolve conflicts.
>
>
>
> There are 3 choices now
>
> 1.       The LBaaS extension does not allow conflicting certificates to
> be bound using validation
>
> 2.       Allow each backend conflict resolution mechanism to get into the
> spec
>
> 3.       Does not specify anything in the spec, no mechanism introduced
> and let the driver deal with it.
>
>
>
> Both HA proxy and Radware uses configuration as a mechanism to resolve.
> Radware uses order while HA Proxy uses externally specified DNS names.
>
> NetScaler implementation uses the best possible match algorithm
>
>
>
> For ex, let’s say 3 certs are bound to the same endpoint with the
> following SNs
>
> www.finance.abc.com
>
> *.finance.abc.com
>
> *.*.abc.com
>
>
>
> If the host request is  payroll.finance.abc.com  we shall  use  *.
> finance.abc.com
>
> If it is  payroll.engg.abc.com  we shall use  *.*.abc.com
>
>
>
> NetScaler won’t not allow 2 certs to have the same SN.
>
>
>

Did you mean "CN" as in "Common Name" above?

In any case, it sounds like:

1. Conflicts are going to be relatively rare in any case
2. Conflict resolution as such can probably be left to the vendor. Since
the Neutron LBaaS reference implementation uses HAProxy, it seems logical
that this should be considered "normal" behavior for the Neutron LBaaS
service-- though again the slight variations in vendor implementations for
conflict resolution are unlikely to cause serious issues for most users.

If NetScaler runs into a situation where the SCN of a cert conflicts with
the SCN or SAN of another cert, then perhaps they can return an
'UnsupportedConfigruation' error or whatnot? (I believe we're trying to get
the ability to return such errors with the flavor framework, correct?)

In any case, is there any reason to delay going forward with a model and
code that:
A. Uses an 'order' attribute on the SNI-related objects to resolve name
conflicts.
B. Includes a ubiquitous library for extracting SCN and SAN that any driver
may use if they don't use the 'order' attribute?

Thanks,
Stephen


-- 
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/20140716/b1e3b548/attachment.html>