4 ms·
It doesn't apply to HTTP/3 because the receiver has to extend the stream concurrency maximum before the sender can open a new stream. This attack works because
by stonogo 3y ago
It doesn't apply to HTTP/3 because the receiver has to extend the stream concurrency maximum before the sender can open a new stream. This attack works because the sender doesn't have to wait for that after sending a reset in HTTP/2.
- londons_explore 3y agoBut the max is still ~100 streams... And you can open 100 streams all with one UDP packet using zero-rtt connections. I can send ~1 Million UDP packets per second from one machine. So thats 100 million HTTP requests per second you have to deal with. And when I bring in my 20,000 friends, you need to deal with 2 trillion requests per second. I'd say that's still a problem.
- stonogo 3y agoOk, but it's not the same problem, which was the question asked.
- vlovich123 3y agoI’m still missing something. Can’t you close a Quic stream and open another one within the same UDP packet?
- jsnell 3y agoYou can do it a few times, but you can't do it 500 times. For HTTP/3, the highest permitted stream ID is an explicit state variable communicated by the server to the client, eventually forcing a round-trip. That's different from HTTP/2 where the client is entitled to assume that new "stream id window space" (for the lack of a better term) opens up immediately after a stream is closed. (I'm fudging things a bit. You can probably build attacks that look kind of similar, but we don't think you you could build anything that is actually scalable. But we could be wrong about that! Hence the recommendation to apply similar mitigations to HTTP/3 as well, even if it isn't immediately vulnerable.)
- vlovich123 3y agoThanks for the explanation. Makes sense.