[jsnell]

It depends on what you think a "request flood" attack is.

With HTTP/1.1 you could send one request per RTT [0]. With HTTP/2 multiplexing you could send 100 requests per RTT. With this attack you can send an indefinite number of requests per RTT.

I'd hope the diagram in this article (disclaimer: I'm a co-author) shows the difference, but maybe you mean yet another form of attack than the above?

[0] Modulo HTTP/1.1 pipelining which can cut out one RTT component, but basically no real clients use HTTP/1.1 pipelining, so its use would be a very crisp signal that it's abusive traffic.

[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.

[arisudesu]

By request flood I mean, request flood, as in sending insanely high number of requests per unit of time (second) to the target server to cause exhaustion of its resources.

You're right, with HTTP/1.1 we have single request in-flight (or none in keep-alive state) at any moment. But that doesn't limit number of simultaneous connections from a single IP address. An attacker could use the whole port space of TCP to create 65535 (theoretically) connections to the server and to send requests to them in parallel. This is a lot, too. In pre-HTTP/2 era this could be mitigated by limiting number of connections per IP address.

In HTTP/2 however, we could have multiple parallel connections with multiple parallel requests at any moment, this is by many orders higher than possible with HTTP/1.x. But the preceeding mitigation could be implemented by applying to the number of requests over all connections per IP address.

I guess, this was overlooked in the implementations or in the protocol itself? Or rather, it is more difficult to apply restrictions because of L7 protocol multiplexing because it's entirely in the userspace?

Added: The diagram in the article ("HTTP/2 Rapid Reset attack" figure) doesn't really explain why this is an attack. In my thinking, as soon as the request is reset, the server resources are expected to be freed, thus not causing exhaustion of them. I think this should be possible in modern async servers.

[jsnell]

> But that doesn't limit number of simultaneous connections from a single IP address.

Opening new connections is relatively expensive compared to sending data on an existing connection.

> In my thinking, as soon as the request is reset, the server resources are expected to be freed,

You can't claw back the CPU resources that have already been spent on processing the request before it was cancelled.

> By request flood I mean, request flood, as in sending insanely high number of requests per unit of time (second) to the target server to cause exhaustion of its resources.

Right. And how do you send an insanely high number of requests? What if you could send more?

Imagine the largest attack you could do by "sending an insanely high number requests" with HTTP/1.1 with a given set of machine and network resources. With H/2 multiplexing you could do 100x that. With this attack, another 10x on top of that.

[toast0]

> An attacker could use the whole port space of TCP to create 65535 (theoretically) connections to the server and to send requests to them in parallel.

This is harder for the client than it is for the server. As a server, it's kind of not great that I'm wasting 64k of my connections on one client, but it's harder for you to make them than it is for me to receive them, so not a huge deal with today's servers.

On this attack, I think the problem becomes if you've got a reverse proxy h2 frontend, and you don't limit backend connections because you were limiting frontend requests. Sounds like HAProxy won't start a new backend request until the pending backend requests is under the session limit; but google's server must not have been limiting based on that. So cancel the frontend request, try to cancel the backend request, but before you confirm the backend request is canceled, start another one. (Plus what the sibling mentioned... backend may spend a lot of resources handling the requests that will be canceled immediately)

[immibis]

You're wrong about that. It's hard to make 65k new connections on your average client OS, but a packet generator has no problem with it.