[tptacek]

I think for this audience a good clarification is:

* HTTP/1.1: 1 request per RTT per connection

* HTTP/2 multiplexing: 100 requests per RTT per connection

* HTTP/2 rapid reset: indefinite requests per connection

In each case attackers are grinding down a performance limitation they had with previous generations of the attack over HTTP. It is a request flood; the thing people need to keep in mind is that HTTP made these floods annoying to generate.

[maxfurman]

What does RTT stand for? My gut says "Round Trip (something)" but I could certainly be wrong.

[hathawsh]

The HTTP spec defines it as Round Trip Time, but in this little discussion thread, "round-trip transaction" would be a better fit.

https://developer.mozilla.org/en-US/docs/Glossary/Round_Trip...

[ynik]

I wonder why exactly this attack can't be pulled off with HTTP/1.1 and TCP RST for cancellation. It seems that (even with SYN cookies involved) an attacker could create new connections, send HTTP request, then quickly after send a RST.

Is it just that the kernel doesn't really communicate TCP RST all that well to the application, so the HTTP server continues to count the connection against the "open connection limit" even though it isn't open anymore?

[immibis]

The server kernel won't communicate the new connection to the application until you go through SYN-SYNACK-ACK.

[wbl]

The problem for the attacker is they then run into resource limits on the TCP connections. The resets are essential to get the consumption not counting.

[jsnell]

Indeed, that's a crucial clarification. Thanks.

[altairprime]

In the style of the above clarification, how would you describe HTTP/3 in "x requests (per y)? per connection"?

[blauditore]

What happens if you send more? Does it just get ignored by the server?

[jsnell]

For most current HTTP/2 implementations it'll just be ignored, and that is a problem. We've seen versions of the attack doing just that, as covered in the variants section of the article.

Servers should switch to closing the connection if clients exceed the stream limit too often, not just ignoring the bogus streams.