Re: [tor-dev] Does a design document for the DoS subsystem exist?

[Lennart Oldenburg <lennart.oldenburg@xxxxxxxxxxxxxxxx>]

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
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev