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-Re...
At the very least relays blocking/dropping some packets of other relays should be very transparent about it.
kind regards, nusenu