<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
I mis quoted it should be in RFC 5246 not 5264.<br>
<div>
<div>On Apr 25, 2014, at 2:50 AM, Carlos Garza <<a href="mailto:carlos.garza@rackspace.com">carlos.garza@rackspace.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
Trevor is referring to our plans on using the SSL session ID of the ClientHello to provide session persistence.
<div>See RFC 5264 section 7.4.1.2 which sends an SSL session ID in the clear (Unencrypted) so that a load balancer with out the decrypting key can use it to make decisions on which</div>
<div>back end node to send the request to. Users browsers while typically use the same session ID for a while between connections. </div>
<div><br>
</div>
<div>Also note this is supported in TLS 1.1 as well in the same section according to RFC 4346. And in TLS 1.0 RFC2246 as well.</div>
<div><br>
</div>
<div> So we have the ability to offer http cookie based persistence as you described only if we have the key but if not we can also offer SSL Session Id based persistence.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
<div>
<div>On Apr 24, 2014, at 7:53 PM, Stephen Balukoff <<a href="mailto:sbalukoff@bluebox.net">sbalukoff@bluebox.net</a>> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div dir="ltr">Hi Trevor,
<div><br>
</div>
<div>If the use case here requires the same client (identified by session cookie) to go to the same back-end, the only way to do this with HTTPS is to decrypt on the load balancer. Re-encryption of the HTTP request may or may not happen on the back-end depending
on the user's needs. Again, if the client can potentially change IP addresses, and the session still needs to go to the same back-end, the only way the load balancer is going to know this is by decrypting the HTTPS request. I know of no other way to make this
work.</div>
<div><br>
</div>
<div>Stephen</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Thu, Apr 24, 2014 at 9:25 AM, Trevor Vardeman <span dir="ltr">
<<a href="mailto:trevor.vardeman@rackspace.com" target="_blank">trevor.vardeman@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div style="direction:ltr;font-size:10pt;font-family:Tahoma">
<div style="direction:ltr">
<div><font face="Arial" size="3">Hey,</font></div>
<div><font face="Arial" size="3"><br>
</font></div>
<div><font face="Arial" size="3">I'm looking through the use-cases doc for review, and I'm confused about one of them. I'm familiar with HTTP cookie based session persistence, but to satisfy secure-traffic for this case would there be decryption of content,
injection of the cookie, and then re-encryption? Is there another session persistence type that solves this issue already? I'm copying the doc link and the use case specifically; not sure if the document order would change so I thought it would be easiest
to include both :)</font></div>
<div><font face="Arial" size="3"><br>
</font></div>
<font face="Arial" size="3">Use Cases: </font><a href="https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis" target="_blank"><font size="3">https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis</font></a></div>
<div style="direction:ltr"><br>
</div>
<div style="direction:ltr"><font face="Arial" size="3">Specific Use Case: <span><span style="vertical-align:baseline;white-space:pre-wrap">A project-user wants to make his
</span><span style="font-weight:bold;vertical-align:baseline;white-space:pre-wrap">secured
</span><span style="vertical-align:baseline;white-space:pre-wrap">web based application (HTTPS) highly available. He has n VMs deployed on the same private subnet/network. Each VM is installed with a web server (ex: apache) and content. The application requires
that a transaction which has started on a specific VM will continue to run against the same VM. The application is also available to end-users via smart phones, a case in which the end user IP might change. The project-user wishes to represent them to the
application users as a web application available via a single IP.</span></span><span class="HOEnZb"><font color="#888888"><br>
</font></span></font><span class="HOEnZb"><font color="#888888">
<div><font face="Arial" size="3"><br>
</font></div>
<div><font face="Arial" size="3">-Trevor Vardeman</font></div>
</font></span></div>
</div>
</div>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<span></span>Stephen Balukoff <br>
Blue Box Group, LLC <br>
(800)613-4305 x807 </div>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
</div>
<br>
</div>
</div>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br>
</blockquote>
</div>
<br>
</body>
</html>