[tor-relays] Experimental DoS mitigation is in tor master

[David Goulet]

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

-- 
okhFQbMsSCX2RtIiPaat//YUDaCrKUWiOgBmw0blDzM=
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20180201/7f7b2db8/attachment.sig>