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

[nusenu]

> 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

-- 
https://nusenu.github.io