On Mittwoch, 8. Februar 2023 00:07:22 CET nusenu wrote:
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-R elay-Operators
At the very least relays blocking/dropping some packets of other relays should be very transparent about it.
On exits, i don't block|rate limit via nftables I block via exit policy. Alex from Artikel10 created a nice python script: https://github.com/artikel10/surgeprotector I'm running the script with 10000 TCP connections as the LIMIT.
Once issue ¹#40676 is resolved, the relays will no longer need to be restarted. A reload would close already established outbound connections.
¹https://gitlab.torproject.org/tpo/core/tor/-/issues/40676