> The exploit has more to do with their implementation than the protocol.
Is it? I imagine that implementations can do things like make creating/dropping a stream faster but how would an implementation flat out mitigate this?
There is a maximum bandwidth at which data can arrive. Simply make sure you can always process it faster than the next packet can arrive, or implement proper mitigation in cases where you cannot.
It's called programming under soft real-time constraints.
Well yeah, that's just how DoS kinda works with these sorts of vulns. "Be faster" is obviously a good strategy, but is it viable ? Is setting up and canceling a stream something that can be done at GB/s speeds? Maybe, idk.
If you push arbitrary amount of pressure through a pipe that can only handle 1000 psi, you need a valve to release the excess pressure, or it will blow up.
In the real world, pipes cannot put arbitrary pressure, so your constraint is more bounded than this. So if you receive 2000 psi but your pipes can only handle 1000, you just need a small component that can handle the 2000 to split the pressure in two, and you can handle it all without releasing any.
The same applies to digital logic; it's always possible to build something such that you can guarantee processing within a bounded amount of time by optimizing and sizing the resources correctly.
As the word "digital logic" suggests, these sorts of guarantees are more often applied when designing hardware than software, but they can apply to either.
> Simply make sure you can always process it faster than the next packet can arrive
This is pretty much impossible unless you make the client do a proof-of-work so they can't send requests very quickly. Okay, you could use a slow connection so that requests can't arrive very quickly, but then the DoS is upstream.
Is it? I imagine that implementations can do things like make creating/dropping a stream faster but how would an implementation flat out mitigate this?