Does a design document for the DoS subsystem exist?
Hi all, We are investigating how Tor protects itself against Denial-of-Service (DoS) attacks. So far, it has been difficult to find a comprehensive top-level design document for the DoS subsystem (e.g., a torspec or proposal) that reflects the decisions that lead to the subsystem in its current form. Specifically, we are looking at the DoS mitigation subsystem code for entry guards at src/core/or/dos.{h,c} [1]. We are trying to understand the chosen countermeasures and how the default and current consensus values came to be, e.g., the decision to limit to 3 circuits per second after the initial burst. 1) Could you kindly point us in the right direction if any such document exists? 2) If it does not exist, would you mind briefly explaining how the DoS threshold values (such as DoSCircuitCreationMinConnections, DoSCircuitCreationRate, DoSCircuitCreationBurst, and DoSConnectionMaxConcurrentCount) were chosen? Thank you very much in advance. Kind regards Lennart Oldenburg KU Leuven [1] https://gitweb.torproject.org/tor.git/tree/src/core/or/dos.c
Lennart Oldenburg <lennart.oldenburg@esat.kuleuven.be> writes:
Hi all,
We are investigating how Tor protects itself against Denial-of-Service (DoS) attacks. So far, it has been difficult to find a comprehensive top-level design document for the DoS subsystem (e.g., a torspec or proposal) that reflects the decisions that lead to the subsystem in its current form.
Specifically, we are looking at the DoS mitigation subsystem code for entry guards at src/core/or/dos.{h,c} [1]. We are trying to understand the chosen countermeasures and how the default and current consensus values came to be, e.g., the decision to limit to 3 circuits per second after the initial burst.
1) Could you kindly point us in the right direction if any such document exists?
2) If it does not exist, would you mind briefly explaining how the DoS threshold values (such as DoSCircuitCreationMinConnections, DoSCircuitCreationRate, DoSCircuitCreationBurst, and DoSConnectionMaxConcurrentCount) were chosen?
Hello there, first of all let me say that the DoS subsystem of Tor is under active development, so things are subject to change and mutate towards various directions (e.g. https://lists.torproject.org/pipermail/tor-dev/2020-April/014215.html). However, since you are asking for resources on the currently existing DoS subsystem here is some things you can look at: - Resources on general Tor rate limiting: https://trac.torproject.org/projects/tor/ticket/24902 https://lists.torproject.org/pipermail/tor-relays/2018-January/014357.html - The proposal for the HS DoS subsystem: https://github.com/torproject/torspec/blob/master/proposals/305-establish-in... - More information on HS DoS subsystem: https://lists.torproject.org/pipermail/tor-dev/2019-April/013790.html https://lists.torproject.org/pipermail/tor-dev/2019-May/013837.html https://lists.torproject.org/pipermail/tor-dev/2019-July/013923.html Good luck with your research and please let us know if you reach the point where you can break or fix things! :) Cheers!
Hello George, hello all, 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? 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? Thank you. Kind regards Lennart Oldenburg [1] https://trac.torproject.org/projects/tor/ticket/24902 On 13/04/2020 23.50, George Kadianakis wrote:
Lennart Oldenburg <lennart.oldenburg@esat.kuleuven.be> writes:
Hi all,
We are investigating how Tor protects itself against Denial-of-Service (DoS) attacks. So far, it has been difficult to find a comprehensive top-level design document for the DoS subsystem (e.g., a torspec or proposal) that reflects the decisions that lead to the subsystem in its current form.
Specifically, we are looking at the DoS mitigation subsystem code for entry guards at src/core/or/dos.{h,c} [1]. We are trying to understand the chosen countermeasures and how the default and current consensus values came to be, e.g., the decision to limit to 3 circuits per second after the initial burst.
1) Could you kindly point us in the right direction if any such document exists?
2) If it does not exist, would you mind briefly explaining how the DoS threshold values (such as DoSCircuitCreationMinConnections, DoSCircuitCreationRate, DoSCircuitCreationBurst, and DoSConnectionMaxConcurrentCount) were chosen?
Hello there,
first of all let me say that the DoS subsystem of Tor is under active development, so things are subject to change and mutate towards various directions (e.g. https://lists.torproject.org/pipermail/tor-dev/2020-April/014215.html).
However, since you are asking for resources on the currently existing DoS subsystem here is some things you can look at:
- Resources on general Tor rate limiting: https://trac.torproject.org/projects/tor/ticket/24902 https://lists.torproject.org/pipermail/tor-relays/2018-January/014357.html
- The proposal for the HS DoS subsystem: https://github.com/torproject/torspec/blob/master/proposals/305-establish-in...
- More information on HS DoS subsystem: https://lists.torproject.org/pipermail/tor-dev/2019-April/013790.html https://lists.torproject.org/pipermail/tor-dev/2019-May/013837.html https://lists.torproject.org/pipermail/tor-dev/2019-July/013923.html
Good luck with your research and please let us know if you reach the point where you can break or fix things! :)
Cheers!
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=
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
participants (3)
-
David Goulet -
George Kadianakis -
Lennart Oldenburg