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
--
vazCt9Q/hhTh3g3JP3KjhmzS1a5JTbDcO4zVCXlh9fc=
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev