Re: Introducing a Session header...

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

Received on Friday, 20 July 2012 19:39:06 UTC