Slow read attack in HTTP/2

[Sharan J]

Hi,

Thanks for the response.

Would like to know what happens in the following scenario,

Client sets its initial congestion window size to be very small and
requests for a large data. It updates the window size everytime when it
gets exhausted with a small increment (so send_timeout wont happen as
writes happens always but in a very small amount). In this case won't the
connection remain until the server flushes all the data to the client which
has very less window size?

If the client opens many such connections with many streams, each
requesting for a very large data, then won't it cause DOS?

Thanks,
Sharan



On Fri, Aug 19, 2016 at 5:28 PM, Valentin V. Bartenev <vbart at nginx.com>
wrote:

> On Friday 19 August 2016 17:06:41 Sharan J wrote:
> > Hi,
> >
> > Would like to know what timeouts should be configured to mitigate slow
> read
> > attack in HTTP/2.
> >
>
> A quote from the commit:
>
>  | Now almost all the request timeouts work like in HTTP/1.x connections,
> so
>  | the "client_header_timeout", "client_body_timeout", and "send_timeout"
> are
>  | respected. These timeouts close the request.
>
> and the documentation links:
>
> http://nginx.org/r/client_header_timeout
> http://nginx.org/r/client_body_timeout
> http://nginx.org/r/send_timeout
>
>
> > Referred ->
> > https://trac.nginx.org/nginx/changeset/4ba91a4c66a3010e50b84fc73f05e8
> 4619396885/nginx?_ga=1.129092111.226709851.1453970886
> >
> > Could not understand what you have done when all streams are stuck on
> > exhausted connection or stream windows. Please can you explain me the
> same.
> [..]
>
> Each stream has its own timeout configured by the directives mentioned
> above.
> If there's no progress on a stream during one of these timeouts then the
> stream
> is closed.
>
>   wbr, Valentin V. Bartenev
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20160819/3d186ddb/attachment.html>