So a single machine can do ~ 20,000 rps?

Depends, but there seems to be a multiplier effect at play with this attack. A single client request may result in 100x the work for the server. More details here: https://cloud.google.com/blog/products/identity-security/how...

Yep: "a client can send a RST_STREAM frame for a single stream. This instructs the server to stop processing the request and to abort the response, which frees up server resources and avoids wasting bandwidth."

Pretty clever

> Another advantage the attacker gains is that the explicit cancellation of requests immediately after creation means that a reverse proxy server won't send a response to any of the requests. Canceling the requests before a response is written reduces downlink (server/proxy to attacker) bandwidth.

How is this an advantage? Can someone explain please?

The attacking system is shooting a firehose of requests at the target system, but doesn't have to deal with handling any responses being sent back to the requesting systems.

Makes sense, thank you!

It's an advantage because you as a botnet client have made the server side do extra work. You sent two packets, one to request a new connection, and a second to immediately cancel the request. The server on the other hand sees a connection request and does some work like allocating memory and fetching the resource you requested. Once the server starts sending the response back to the client via the reverse proxy, the reverse proxy notices the request is no longer current and just drops the response on the floor. As a result, you made the server do some amount of work and you don't have to worry about saturating your internet connection. They call this a magnification attack because for the cost of two requests you made the server do some multiple of work.

You could add some smarts to the server or reverse proxy that delays starting work in case a cancellation request quickly arrives. This is probably part of the mitigation work they refer to in the article.

This is sort of an aside based on something I read in the article but does anyone know why the RFC guidelines say that you should first send an informational GOAWAY that does not prevent opening new streams when gracefully closing a connection?

They point out in the article that it's a better practice to immediately limit stream creation when you detect abuse - not wait for a round trip to complete first. I'm sure there's a good reason for the original guidelines; I'm just trying to get it and haven't found anything clarifying through Google. Was it specified before the rise of modern attacks?

How do you act on a GOAWAY you haven't received and allowing the server to unilaterally stop supporting things can lead to weird edge cases.

After all you could say any client ignoring a GOAWAY is either bugged or malicious but certainly not until you get confirmation they go it.

Of course. Depending on the machine and on the network, a single modern machine can do even up to a few millions RPS. This is routinely used in benchmarking tools.

Here with the "attack", it's simply exploiting the ability of HTTP/2 to compress requests and reduce them to just a few bytes, meaning that within a few kilobytes of data you can easily have hundreds of requests. Again this is not new and was already being discussed in 2012 about SPDY's use of zlib to compress requests.

The extra stuff that seems to have made this attack "new" for such service providers is that attackers took care of closing their requests so as not to have to wait for a response and be able to fill the wire with a flow of request. Again this has been known from the inception of HTTP/2 and routinely met by those dealing with proxies which timeout and send headers followed by rst_stream.

Here it makes noise because new records were broken, and likely because the stacks in place were not properly designed so they omitted to check for the real number of streams and only focused on the protocol validity...

If this attack takes only 20,000 machines to orchestrate, how is it the "largest DDoS attack to date"? It was to my understanding that some botnets and organizations have placed far more than 20,000 machines under their control before or currently. Could you explain a bit better?

I think they're measuring "largest" by the number of requests per second.

But that's part of my question. If other botnets have previously been created with many more than 20,000 controlled machines, why has nobody else before orchestrated an attack with so many requests if it only requires 20,000 machines or so to pull off?

This is exploiting a new technique. This technique wasn't known previously, or wasn't viable when HTTP/2 wasn't widespread. This technique is a ~100x multiplier on the impact any size botnet can have. A previous botnet might have needed 20,000,000 machines to achieve the same impact.

Thanks for explaining in such a straightforward way, appreciated!