Re: Fragmentation for headers: why jumbo != continuation.

On Thu, Jul 10, 2014 at 5:59 PM, Greg Wilkins <gregw@intalio.com> wrote:

>
> On 11 July 2014 10:41, Roberto Peon <grmocg@gmail.com> wrote:
>
>> Flow control of headers ends up being problematic even when there is no
>> compressor, since, on the flip side of this coin, you can't always predict
>> which headers are necessary for interpretation of a request, and thus you
>> end up with smart attackers sending all but that last thing for every
>> stream and affecting a much more effective slowloris attack.
>
>
> This is true.  But if we can break the dependencies between the order that
> we decompress headers, then I think both proposals are pretty much the same.
>
> With fragmented but not flow controlled headers, and proxy or endpoint is
> still going to have to wait/buffer until the fragment holding the necessary
> information arrives.
>

Yup, but there are usecases where 'the necessary information' is the null
set (trusted senders), and others where it is found quite quickly (e.g. if
the client is smart/lucky enough to present the necessary headers).


>
> I think we should not tie ourselves too much in knots over what bad actors
> can do... so long as a bad actor can only screw with their own stream and
> can't take more resources from an impl that it is prepared to commit.
>
> however, I don't think the will is there to start again from framing
> layer, so happy to ignore my suggestion for the purposes of this thread.
>

When acting as a server (or a proxy) and listening to the clients on the
untrusted internet, one will experience malicious clients.
The issue with these clients is that the memory (and cpu, etc.) they
consume could be better spent on other, hopefully non-malicious clients to
improve their experience.
A trivial example of this is the server's willingness to keep the
connection open, and thus be able to receive and react to queries without
having the client pay for the connection startup and TLS termination
latency again.
A server's willingness to do this will be related directly to the number of
clients it can handle at that moment (for a well constructed server/proxy).

In other words, if malicious clients can consume more memory (amongst other
resources, but this is the easiest attack vector), it can cause a
degradation in the quality of the service that the server can provide other
clients.
This is the reason why the design intent was to receive one set of headers
at a time, though in a streaming fashion-- it limits the attack surface
while not affecting anything in the common case where headers are small.

-=R

>
> cheers
>
>
> --
> Greg Wilkins <gregw@intalio.com>
> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that
> scales
> http://www.webtide.com  advice and support for jetty and cometd.
>