[stygiansonic]

    After rigorous testing, we have been able to confirm that our implementation of the HTTP/2 protocol can handle the Rapid Reset Attack without increasing the resource usage or compromising the parallelism of the protocol.

But doesn’t this mean the servers behind the reverse proxy would still suffer from increased/wasted resources responding to the rapid reset requests?

[crote]

Not by definition. Looking at Cloudflare's summary of the attack[0], part of it seems to rely on sending a request and then cancelling it in the very same packet.

A trivial implementation might walk through the packet front-to-back, firing off requests and cancellations immediately as it encounters them. That would indeed still result in a lot of load on the servers behind the proxy.

However, a reasonable alternative would be to only collect a set of actions to execute while walking through the packet, firing them off all at once when you finish. For example, a "launch request" could create a new entry in the backend requests list with a state of "NEW". The "cancel request" part immediately afterwards could then look in the backend request list and set the state of the corresponding request to "CANCEL".

Now when the backend request list is being processed next, it'll only see a request marked "CANCEL" without a corresponding socket to a backend, shrug, and just delete the entry because there is nothing to do.

[0]: https://blog.cloudflare.com/technical-breakdown-http2-rapid-...

[dylan604]

I thought you were going to suggest it to be processed like one of those trick exams of reading all of the questions before answering any of the questions where the last question is something so obvious that like stand up sit down, then turn in the test with out writing anything on it. So in this case, read all of the instructions in the packet. If the last is CANCEL, do nothing.

[bombcar]

It's basically like that - the "fastest" servers will begin responding before processing the entire packet; but it's likely that's never really needed (and if it is, you'll know and can turn it on) but the smarter thing to do is process the whole packet at once.

[lillecarl]

If you're doing tcp load balancing sure, but http is terminated at the proxy and wouldn't be vulnerable. This is why you put $proxy or $webbserver in front of your application webserver.