Re: Introducing a Session header...

[Phillip Hallam-Baker <[e-mail]>]

Perhaps what we could do is to define a TLS extension that could carry
a session ID (possibly even a session authenticator) enclair. This
would:

1) Decrease disincentives to use TLS (i.e. difficulties using it with
load balancers)

2) Provide an incentive to upgrade to support the new session ID scheme.


Given that TLS is regularly supported through a front end box type
approach, it would of course be necessary to still carry the session
id as a HTTP header in addition.


On Fri, Jul 20, 2012 at 3:38 PM, Willy Tarreau <[e-mail]> wrote:
> On Fri, Jul 20, 2012 at 11:18:43AM -0700, James M Snell wrote:
>> Indeed, not to mention the fact that terms like "session" are painfully
>> overloaded. Collecting the list of requirements is a good next step, I
>> think, but we need to be clear on the language used to avoid further
>> confusion.
>>
>> Today, the term "Session" can refer to:
>>
>> 1. The TCP / TLS Connection
>> 2. The concept of routing "Stickiness"
>> 3. Application-level state that persists across multiple http requests, and
>> multiple TCP connections.
>>
>> Cookies, quite unfortunately, have been abused in a variety of ways to
>> implement #2 and #3, generally because there is no protocol-level mechanism
>> provided to support those cases, developers have largely just hacked it in.
>
> Exactly.
>
>> So if we're talking about specific requirements, I would argue that we:
>>
>> A. We need a protocol-level concept of a "Routing Token" to address #2. The
>> use of this mechanism is strictly to provide intermediaries with a method
>> of establishing a generally-persistent routing path for all requests
>> originating from the same client. This token is NOT intended to be used to
>> identify or access shared application state. In fact, it is questionable as
>> to whether this routing token should be visible to the application layer at
>> all. The token could, theoretically, be transmitted entirely in the clear
>> without risk of inappropriate disclosure of sensitive information.
>
> Indeed, and that's what's being done with cookies nowadays, except it
> requires that LBs decipher TLS only to get this cookie ! That's why there
> have been some thoughts about reusing the IPv6 flow label for this [1] [2].
>
>> The one
>> caveat, however, is that there must be a mechanism to protect the integrity
>> of the token. For instance, a form a DoS attack could be carried out by
>> intercepting and changing the routing token, breaking the stickiness of the
>> route or redirecting traffic to an unintended destination.
>
> This example is often given but we regularly need to show that it does not
> really exist in practice. Even if you made it unpredictable or whatever,
> it's trivial for a client to always stick to the same token once obtained.
> Cookies already suffer from this and this is not what is exploited for DDoS
> attacks, what is targetted is weaknesses in the parsers (eg: slowloris),
> and huge amounts of more or less valid requests to try to overwhelm the
> first point (hence the LB). Attackers have no business wasting their time
> enumerating server identifiers to try the domino effect on them, the domino
> effect happens by itself if they're overloaded anyway.
>
>> B. While we need a more reliable Application-level mechanism to deal with
>> #3 (essentially an evolved form of the Cookie mechanism) it does not need
>> to be defined at the protocol level. This is something that can be done
>> orthogonally to any work being done within the protocol. That's not to say
>> we cannot make use of potential new capabilities of HTTP/2.0 to deliver
>> that "more reliable mechanism", just that we do not need to completely
>> define the mechanism within HTTP/2.0.
>
> I tend to agree with a grain of salt. There are some places where you
> find content delivery servers behind the LB and a small farm of login
> servers. The LB then relies on the presence (or even freshness) of the
> application session cookie to decide what farm to send the request to.
> It's not critical because anyway such an architecture needs provisions
> for letting the content server redirect to the login farm when it does
> not know the session. That said, we're possibly at the frontier between
> what is pure routing at low cost and what is L7 processing which will
> always exist anyway with its associated costs.
>
>> Reasonable?
>
> Seems reasonable to me at least.
>
> Willy
>
> [1] http://tools.ietf.org/html/draft-carpenter-flow-label-balancing-01
> [2] http://tools.ietf.org/html/draft-tarreau-extend-flow-label-balancing-00
>
>



-- 
Website: http://hallambaker.com/