Resent-Date: Fri, 12 Jul 2013 19:49:29 +0000
Resent-Message-Id: <E1UxjLN-0002xp-Ln@frink.w3.org>
From: Yoav Nir <ynir@checkpoint.com>
To: Willy Tarreau <w@1wt.eu>
CC: Poul-Henning Kamp <phk@phk.freebsd.dk>, Mark Nottingham <mnot@mnot.net>,
 Sam Pullara <spullara@gmail.com>, James M Snell <jasnell@gmail.com>,
 "Martin Thomson" <martin.thomson@gmail.com>,
 Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
Thread-Topic: HTTP router point-of-view concerns
Thread-Index: AQHOfcCOZ2fHYp9biUaCEWX0LISz35leleMAgAAFrACAABKEAIAAzZcAgAAKzQCAAAHDAIAA5EwAgAAGJQCAAEn9gIAAE/4AgAByqAA=
Date: Fri, 12 Jul 2013 19:46:46 +0000
Message-ID: <22115082-53F8-433C-9497-755800803B93@checkpoint.com>
References: <CA+qvzFPUpcm6kUtJx+rTw8Dpp4Gtx4Bmr3XPDhjNsjchUfN9_w@mail.gmail.com>
 <51DE1E32.9010801@treenet.co.nz>
 <CAP+FsNdcYhA=V5Z+zbt70b5e7WmcmXgjG5M9L3vfXeXfTwmRnw@mail.gmail.com>
 <51DE327C.7010901@treenet.co.nz>
 <CABkgnnXeqD6wh0dcJ1Dz=4PLAJNkDeGcCuzMr9ATd_7xS7nbGQ@mail.gmail.com>
 <CABP7RbcUkLf3CTAB4jwicnsiKWLGVY6=hX0k=0256SR_gcVt9A@mail.gmail.com>
 <092D65A8-8CB7-419D-B6A4-77CAE40A0026@gmail.com>
 <3835.1373612286@critter.freebsd.dk>
 <CD9E163F-1225-4DA8-9982-8BDBD16B1051@mnot.net>
 <1772.1373629495@critter.freebsd.dk> <20130712125628.GC28893@1wt.eu>
In-Reply-To: <20130712125628.GC28893@1wt.eu>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <EB2D65B3FDFFF64F9AFB550C2CBCA4C3@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Received-SPF: pass client-ip=194.29.34.68; envelope-from=ynir@checkpoint.com;
 helo=smtp.checkpoint.com
Subject: Re: HTTP router point-of-view concerns
Archived-At: <http://www.w3.org/mid/22115082-53F8-433C-9497-755800803B93@checkpoint.com>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

Hi

This thread has forked to discussing session management. I'd like to call y=
our attention to the fact that in the past, this working group was consider=
ed too busy with HTTP/2.0 to spend time on things like session management o=
r HTTP authentication schemes. For this reason it was suggested that the We=
bSec working group work on session management.=20

Right now, on the WebSec mailing list ([1]) there is a thread ([2]) about t=
aking on this work. Being engineers, the discussion there is veering toward=
s solutions before there's even an agreed-upon problem statement, but that'=
s besides the point. If you are interested in defining an alternative to se=
ssion management based on session cookies, please subscribe ([3]) to the We=
bSec mailing list and say so.=20

Thanks

Yoav

[1] http://www.ietf.org/mail-archive/web/websec/current/threads.html
[2] http://www.ietf.org/mail-archive/web/websec/current/msg01680.html
[3] https://www.ietf.org/mailman/listinfo/websec

On Jul 12, 2013, at 3:56 PM, Willy Tarreau <w@1wt.eu> wrote:

> Hi Poul-Henning,
>=20
> On Fri, Jul 12, 2013 at 11:44:55AM +0000, Poul-Henning Kamp wrote:
>> In message <CD9E163F-1225-4DA8-9982-8BDBD16B1051@mnot.net>, Mark Notting=
ham wri
>> tes:
>>=20
>>> This has been brought up a number of times. I think what we need is a =
=3D
>>> concrete proposal *with* a detailed plan for a workable transition to =
=3D
>>> the new mechanism -- which seems to be the (or at least one) sticking =
=3D
>>> point whenever this comes up.
>>=20
>> I have given a concrete example multiple times, it's very simple:
>>=20
>> 	The client always sends along a session-identifier of N (128?)
>> 	bits.
>>=20
>> 	If the first bit is zero, this is an anonymous, transient
>> 	session, not (to be) associated with any other session.
>>=20
>> 	If the first bit is one, this is a persistent session
>> 	identifier, which the server can use to look up any relevant
>> 	state or information from previous instances of this
>> 	session, in its local database.
>>=20
>> 	This replaces the Cookie: and Set-Cookie: headers, which
>> 	SHALL NOT be sent in the HTTP/2.0 protocol.
>>=20
>> Advantages:
>>=20
>> 	We get a fixed size session-identifier for HTTP routers to
>> 	use for flow-routing.
>>=20
>> 	We get an actual (client controlled) session-concept, rather
>> 	than all sorts of ad-hoc simulations with cookies.
>>=20
>> 	Data with privacy-concerns are stored on the server not on
>> 	random clients the user happens to borrow or use.
>>=20
>> 	The overhead of encrypting and signing the data in cookies
>> 	is avoided, since they are stored on the server side where
>> 	nobody can fudge them.
>>=20
>> Backwards compatibility:
>>=20
>> 	It should be obvious that simulating the Cookie concept for
>> 	framework compatibility on the server side is a trivial
>> 	matter of programming:  Rather than send set-cookies, write
>> 	them to a database, indexed by the session-id.  Rather than
>> 	receive Cookie: headers, look them up in the database.
>>=20
>> There, solved.
>=20
> Not really in fact. While I tend to generally agree with the points
> you make for scalability, this one does not scale. One of the big
> benefits of cookies is that client is responsible for synchronizing
> information between multiple servers *if needed*. When you're building
> an architecture using anycast DNS + ECMP + L4 load balancers to reach
> your servers, you can't predict if a client will come back to the same
> place to retrieve its context, and having the ability to make it hold
> *some* data is really useful.
>=20
> If you store everything on server-side, you're forced to synchronize
> everything between all servers of all datacenters because you don't
> even know where your client will go with next hit, let alone parallel
> requests. And this is clearly not possible on many of the platforms
> where both of our products are deployed to achieve connection rates
> in the 6 digits.
>=20
> So there *is* some use to store data on the client, it's just that it
> has been long abused to store session identifiers because it was the
> only mechanism available.
>=20
> While I'd like to see a simple session management system (like the one
> you propose maybe, even if it does not cover the case of low entropy
> client devices), I don't want to see the cookies disappear. I just want
> to be able to rely on session ID without having to parse cookies when
> that's not needed.
>=20
> Regards,
> Willy