Bad Actors, was: Fragmentation for headers: why jumbo != continuation.

On 11 July 2014 11:08, Roberto Peon <grmocg@gmail.com> wrote:

>
>
>
> On Thu, Jul 10, 2014 at 5:59 PM, Greg Wilkins <gregw@intalio.com> wrote:
>
>
>>
>> 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.
>>
>>
> 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.
>
>
I think we are in strenuous agreement here.   Yes we will definitely see
bad actors on the web.   We must not let bad actors affect other streams.
We must not let bad actors go beyond the resources we are prepared to
commit to any actors.

Now if we can detect a bad actor before it hits the resource limits we have
made for good or bad actors, then that is a bonus.

So given that, I'm not sure how streamable/fragmentable headers helps with
bad actor detection.   A bad actor can still leave the a :method field to
absolute last and refuse to send the last header frame or even the last
byte of the last header frame.    This can be near impossible to
distinguish from a good actor on a bad network - timeouts will have apply.

I can't really see how adding flow control to the mix changes any of this
very much.

But anyway - not really relevant to the point you are trying to make in the
other thread.

cheers


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.