Hello David, hello all! > Sorry for the late reply, as you may have seen, things got a bit > intense in Tor in the last 2 weeks.
We heard, very sorry about the ramifications that this pandemic caused for the Tor project! Thanks for the detailed response, it clarifies a lot of the questions we had about the Guard DoS subsystem. Kind regards Lennart On 29/04/2020 14.02, David Goulet wrote: > 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: >> >> 1) 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. > >> 2) 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 _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
