On 15 Apr (00:25:11), Lennart Oldenburg wrote:
Hello George, hello all,
Hi Lennart,
Sorry for the late reply, as you may have seen, things got a bit intense in Tor in the last 2 weeks.
Thank you very much for the provided pointers. Great to hear progress is being made on the Onion Services DoS matter. Two follow-up questions:
- Will the DoS subsystem overhaul also affect guard-centric DoS
countermeasures? Or will it exclusively focus on DoS protection specific to Onion Services? If guard-centric countermeasures are also being updated, is there a document to see what is about to change?
The HS DoS defenses are independent from the relay DoS subsystem.
- The linked bug ticket [1] under your first bullet point does not
mention the origin of the concrete threshold values (DoSCircuitCreationRate, etc.). Could you share any insight on how these DoS threshold values are determined? Are they inferred from experiments?
Correct that we don't have a clear document explaining how we got there. But if we dig, there are emails on a mailing list and possibly a ticket with discussions about the choice of these parameters. But I do also unfortunately recall some of it was only discussed and decided on IRC...
As far as I can recall, we've decided these values based on the "common use case" and observation at Guard relays _not_ under attack versus one under attack at the time.
One of the main reason for the picked values was the "Coffee Shop Effect" or the "Airport Effect" that is in a regular normal use case, how many clients would connect to Tor from the same IP address? We thought that 100-150 people would be reasonable (from an airport or coffee shop) so we doubled that. Putting all this together, with these two parameters, you get your 300 value:
DoSCircuitCreationRate * DoSConnectionMaxConcurrentCount
So for a single client IP address, we allow 3 concurrent connections (DoSCircuitCreationMinConnections) until we activate defenses for that IP. And then, you are allowed 3 * 100 circuits per second until we start denying you circuit creation. And a burst of 90 (DoSCircuitCreationBurst) is allowed per second up to 300 maximum).
And why 3 concurrent connections until we activate defenses? At the time, we imagined that someone could have 1 Tor Browser and a standalone tor daemon for the rest (onion share, torsocks, etc...). Above that, it would not be the "usual" use case and thus we activate defenses. But then even if you are 10 on the same IP, 300 circuit/sec is massive for clients... so there was still a good margin from what the attack was doing.
And also, all these parameters can be controlled within the consensus so if any of them would have been too much or too lax, we could have reacted. It turned out in the end that they were very efficient at stopping the DDoS we had at the time. Who knows what the next big DDoS will bring and we might need to tweak those values as we monitor the attack.
All in all, I do agree with you that we should have a clear nice document in our spec repository at least to describe the what/how these values came about. Time is such a scarse resources these days :(.
Cheers! David