Re: Prague side meeting: HTTP/2 concurrency and request cancellation (CVE-2023-44487)

> 2023/10/13 20:34、Poul-Henning Kamp <phk@phk.freebsd.dk>のメール:
> 
> --------
> Stefan Eissing writes:
> 
>>> Does any published data exist on how "100" relates to how many streams
>>> real-life legit clients /actually/ open on a new H2 connection ?
>> 
>> See > https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/
>> 
>> They tried to lower it and found a page where browsers do open 100 
>> requests right away.
> 
> Yes, already saw that.
> 
> But 100 is not a hard limit, it is barely even guidance, so I wonder
> what the actual, legit, in use in the wild, maximum is ?
> 
> 100 ?  200 ?  1000 ?
> 
> It would be nice if we had some actual statistics to guide us, rather
> than justing picking 100 out of the blue ?

I think that is a totally valid argument.

At the same time, for the clients that would implement the MAX_STREAMS extension (assuming that we standardize such an extension), we can choose whatever value and write down in the spec that clients implementing that extension should adhere to the new limit.

I would not mind going as strict as 10, for example, as that is a penalty for only one RTT until the client receives the MAX_STREAMS frame.

But honestly, I do not have an appetite to implement such an extension at the moment, as I already have, and am required to have safeguards for vanilla H2. As much as I like discussing about how better we can do by defining protocol extensions, I kind of wonder if there is any H2  developer interested in implementing the extension.

> 
> -- 
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe    
> Never attribute to malice what can adequately be explained by incompetence.

Received on Friday, 13 October 2023 11:51:39 UTC