Known attacks

[martinthomson]

Christian Huitema notes a few potential attacks that we don't cover properly:

1. Stream smurfing attack. Client (or server) opens a large number of streams by sending stream data frames with new stream number and minimal content.

2. Stream choke attack. Client sends request on a stream, then use stream level flow control to choke the transmission by the server. Apply to many parallel streams for bonus effect.

3. Silly stream number attack. Client opens stream 2*N+1 for some outlandish version of N. Might play havoc with server management of incoming streams.

4. Stream drop by drop attack. Client sends data on a stream extremely slowly, maybe 1 byte at a time. Server spin its wheels waiting for data.

I don't think that these are controversial. Most are already well-known, we just need text for them.

[marten-seemann]

1. is not really an attack. We have the maximum concurrent stream limit (or maybe soon a maximum Stream ID). There's no way to allocate more state than a peer committed to by advertising a certain limit.

2. Streams must be opened in sequential order. If an implementation follows that rule, the maximum concurrent stream limit takes care of the rest.

3. I don't think this a new attack, and setting reasonable flow control windows mitigates it. In fact, filling the advertised flow control window with data, but leaving out a single byte at the beginning of the window is a more effective version of this attack.

[martinthomson]

I just copied these down, but yes, I agree that most of these reduce to slow loris. On number 3, I think that the attack here is against people who over-commit receive buffers. As you say, sending all but the first byte causes the memory to be committed in practice as opposed to in theory (a state that some implementations rely on).

[huitema]

I agree that this are all variations on the slow loris attacks. They can me mitigated by proper use of configuration parameters and receive logic, but this is not necessarily obvious to the implementer. For example, it is easy to NOT mitigate the attacks by setting the stream limit to a high value-- and then it is also easy to set the stream limit to a value that is too low and get performance effects. I will try to write a PR for an entry in the security section.

[huitema]

I just entered 2 PR for the "stream fragment reassembly" and the "stream id commitment" attacks -- two separate security sub sections. Still need one for the generic "slow loris" attack.

[martinthomson]

@huitema helpfully provided a few pull requests: #444, #445, #448. That covers the listed issues. We can use new issues to track other attacks that come up.