[tor-relays] Questions about 4 Relays per IP and the ddos mitigation scripts

Wed Feb 8 06:57:50 UTC 2023

> DDoS rate limit filters do not require an all or nothing approach,
> different source IPs can be handled differently
> see toralf's use of onionoo to feed ipsets as an example.
> I would recommend to use tor's controlport as a source of information instead though
> because onionoo is not meant to be used for such real time needs.
We do the same. You can take a look at the rules. There's no all or
nothing approach. Regardless, this doesn't change the fact that in
either approach there's always a time when someone, somewhere will not
be able to connect due to their behaviour.

The ipsets are pulled from [my
repository](https://github.com/Enkidu-6/tor-relay-lists) to avoid
putting undue pressure on oniooo server and my lists are updated every
half an hour. This means one query as opposed to very many for each user.

We do have a ban list and cron jobs to remove relays from the list
periodically -even though I'm not a fan of it- to avoid an all out ban.
However the number of allowed connections remain the same regardless
whether you're in the ban list or not.

ipsets are set to allow authorities and snowflake servers to have as
many connections as they need. Dual-or relays are in another ipset and
they can have more connections per IP. That will still stay limited. How
many would be necessary, is the main reason I started this discussion.

> I don't think relays should silently drop
> other relays packets without first trying:
> - to confirm that accepting that IP would render the relay (mostly) unusable (by first running in a mode that accepts relay IPs)
> - to understand the actual root cause
> - to contact the relay operator at the other
> - to report relays they consider malicious

Firewalls and iptables don't work that way. They make those decisions in
fractions of milliseconds and do what they're told. Now, if you're
suggesting that I should do all of that before writing a rule to protect
my server, I do what I can with the time I have and to a reasonable level.

No new versions of rules are released unless I run them for 2 weeks on
my own servers and check for all possible side effects. I spend time to
investigate the relays that are misbehaving to the best of my knowledge
and ability and spend as much time as I'm willing to spend on it. Again
it's all about that compromise I was talking about. I'm not looking to
achieve an ideal solution for an ideal world. That's not achievable and
would be a waste of time trying. My purpose for this discussion is to
find the best way to keep the balance of that compromise in our favour
and not do damage to the overall health of the Tor network.

Now to clarify a few things, I'll explain my process. The rules are
tested on two relays with 20 MiB Max Advertised bandwidth each and each
one has full use of 12 CPUs and about 5-7 GB of RAM and NumCPUs of 30.
By the way this is far better than the systems majority of relays are
run on. Majority of operators run their relays on VPS systems with 1-4
CPUs and 1-4 GB of RAM.

The idea is that if a ruleset causes my relay to go to the overloaded
status, it will certainly do more damage to weaker relays. I can tell
you with absolute certainty that with the current state of the DDoS
we're experiencing if we allow more than 2 connections per IP (1 would
be better) the average relay will have overloaded status at least 2-3
times a week if not more. Again we're talking about average relays not
beasts.

Now to get back to my original question, I'll try to make it a bit more
clear. It may help you answer my question better. Here are the current
statistics:

Since the start of the new rule of 4 relays per IP, 14 operators have
decided to take advantage of it. Together combined, they are operating
214 relays, out which about more or less 100 something relays are
actually new relays added to the network. Some added two, some added
only one. Among them I've seen fake email addresses, those who haven't
even added the new relays to their family, etc.. By the way those
numbers haven't increased in the past 2 or3 days and remained pretty
much the same.

All of these relays with 3-4 Tor instances are running on a total of 54
IP addresses, 39 of which running purely Exit relays on all instances of
Tor on the IP with 0% guard probability and 0% middle probability. Their
status might change after a couple of weeks to a month when they join
the network with full capacity and I'll be monitoring that.

So I ask my question again, with the current state, right at this
moment, If I allow those limited IP addresses only 2 established
connections at a time instead of 4, will that break anything or cause
any harm to the health of the Tor network as a whole? My own answer is
absolutely not, but I eagerly await everyone's opinion.

Cheers.

On 2/7/2023 6:07 PM, nusenu wrote:
>> Even if that happens, why would a client connect
>> directly to an Exit and get the
>> Exit to connect to another relay or Guard using the Exit's IP address?
>
> You mentioned the exit flag, but you didn't specify whether that relay
> also had
> the guard flag.
>
> Generally speaking it is correct, that if you fire up a fresh tor
> client with default
> settings for the first time it will most likely pick a relay with the
> guard flag and no exit flag
> as their guard relay, but...:
>
> Tor clients keep local state over a considerable amount of time.
> Most notably they pick their guard relays rarely.
>
> It is possible that a relay that has the guard+exit flags today,
> only had the guard flag yesterday and the operator decided to enable
> exiting by changing the exit policy just this morning.
> So if that relay was picked as guard yesterday, their guard probability
> of today might not matter so much.
> I recall a gitlab.tpo issue that discussed the details of whether
> tor clients should change guards when their picked guard lost/gained
> flags.
> Maybe someone else could paste a link to it.
>
> related content for the interested reader:
> https://lists.torproject.org/pipermail/tor-relays/2020-October/019002.html
>
> https://gitlab.torproject.org/tpo/core/tor/-/issues/40230
>
>> Wouldn't the same protection you mentioned kick in and
>> stop a client?
>
> The protection I mentioned (reenter the tor network via exits
> blocking) does not interfere
> with a tor client directly connecting to a guard.
>
>> In the old days of vidalia you could actually see that in real time.
>
> for anyone missing that experience, onioncircuits can help you there :)
> but it has less features than vidalia used to have.
> https://gitlab.tails.boum.org/tails/onioncircuits
>
>> Each time you try to browse a page, Tor doesn't
>> say, oh let's find a relay. It picks
>> a circuit from a pool of already Established ones. If Tor tries to build
>> a circuit with a relay and it's unable to,
>> it will try another one that works and keeps it in the pool for when
>> it's needed. Again, I may be wrong.
>> Feel free to tell me if I am.
>
> Yes tor clients preemptively create circuits before creating actual
> streams to reduce
> latency.
>
>> There's no such thing
>> as DDoS mitigation without rate limiting.
>
> DDoS rate limit filters do not require an all or nothing approach,
> different source IPs can be handled differently
> see toralf's use of onionoo to feed ipsets as an example.
> I would recommend to use tor's controlport as a source of information
> instead though
> because onionoo is not meant to be used for such real time needs.
>
> I don't think relays should silently drop
> other relays packets without first trying:
> - to confirm that accepting that IP would render the relay (mostly)
> unusable (by first running in a mode that accepts relay IPs)
> - to understand the actual root cause
> - to contact the relay operator at the other
> - to report relays they consider malicious
>
> Not investigating such cases is a missed opportunity
> to find potential bugs or a new detection mechanism for malicious relays.
> It is also a missed opportunity to help protect the tor network at a
> higher
> level, because it is unlikely that everyone is using (the same) filters.
>
> Filters that result in blocks for a large fraction of the tor network
> are more likely a sign of an unsuitable filters than an indicator that
> most of the
> tor network is engaging in attack against other relays,
> especially when they include well known and long term trusted operators.
>
> This a good topic to be added to the Expectations for Relay Operators
> document.
> https://gitlab.torproject.org/tpo/community/team/-/wikis/Expectations-for-Relay-Operators
>
>
> At the very least relays blocking/dropping some packets of other
> relays should be very transparent about it.
>
> kind regards,
> nusenu
>