On 01 Feb (04:01:10), grarpamp wrote:
Applications that use a lot of resources will have to rate-limit themselves. Otherwise, relays will rate-limit them.
It's possible if relays figure that stuff by #2 might not be an attack per se, but could be user activities... that relays might push back on that one by...
- Seeking significantly higher default values committed
- Seeking default action committed as off
- Setting similar on their own relays if commits don't
work. And by not being default off, it should be prominently documented if #2 affects users activities [1].
That I agree. We've set up default values for now and they will probably be adapted over time so for now this is experimental to see how much we make people unhappy (well except for the people doing the DoS ;).
But I do agree that we should document some "real life" use cases that could trigger defenses at the relay in some very public way (blog post or wiki) before this goes wide in the network. Large amount of tor clienst behind NAT is one I have in mind, IPv6 as well...
Indexers will distribute around it, yielding zero sum gain for the network and nodes. Multiparty onion p2p protocols could suffer though if #2 is expected to affect such things.
I just want to clarify the #2 defense which is the circuit creation mitigation. The circuit rate is something we can adjust over time and we'll see how that plays out like I said above.
However, to be identified as malicious, the IP address needs to be above 3 concurrent TCP connections (also a parameter we can adjust if too low). Normal usage of "tor" client should never make more than 1 single TCP connection to the Guard, everything is multiplexed in that connection.
So lets assume some person wants to "scan the onion space" and fires up 100 tor clients behind one single IP address which results in massive amount of HS connections on all .onion it can find. These tor clients in general won't pick the same Guard but let say 3 of them do which will trigger the concurrent connection threshold for circuit creation.
Doing 3 circuits a second continously up to a burst of 90 is still a _large_ number that relay needs to mitigate in some ways so it can operates properly to be fair to the rest of the clients doing way less in normal circumstances.
IMO, because someone can buy big servers and big uplinks doesn't mean they should be allowed to saturate links on the network. Unfortunately, the network has limitations and this latest DoS is showing us that relay have to rate limit stuff in a fair way if possible.
I bet there will be collateral damage from people currently using the network in insane ways or unique ways. But overall, I don't expect that it will hurt most of the use cases because 1) we made it that it is rare cases of tor client usage that can trigger this (or unknown usage) and 2) we can adjust any single parameters through the consensus if needed.
We'll break some eggs in the beginning and we should act accordingly but one thing is certain, the current situation is not sustainable for any user on the network.
From now on, we can only improve this DoS mitigation subsystem! :)
Cheers! David
Was it ever discovered / confirmed what tool / usage was actually behind this recent ongoing 'DoS' phase? Whether then manifesting itself at the IP or tor protocol level.
Sorry if I missed this in all these threads.
[1] There could even be a clear section with simple named list of all options for further operator reading that could affect users activities / protocols. _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays