Been exploring how each directory authority measures relays and noticed that, over the week of May 24–30, Moria1 consistently reports significantly fewer relays measured than its peers—about 6% missing versus ~3.5% for most other authorities (over 2 σ below the mean).
Right. More details at
Has anyone else spotted this pattern or have ideas why Moria1’s “number of relays voted about” is lower? Any insights or pointers would be greatly appreciated!
It is unfortunately because I can reach fewer of the relays than some
of the other directory authorities.
There are several categories of (to use OONI.org's terminology) "network
interference" here:
(A) MIT is intentionally filtering (censoring) these addresses long term,
i.e. the block expires in a matter of years. I believe it is because of
repeated exit abuse incoming to their networks, but the blocking is in
both directions so moria1 can't reach them either. I worked with them
(history on ticket 90) to greatly decrease the size of this list and I
think it is still shrinking as entries expire.
147.182.202.137
185.220.101.35
185.246.188.74
192.42.116.179
213.152.187.205
45.84.107.182
45.84.107.74
(B) MIT is intentionally filtering these addresses short term, i.e. the
block expires in a matter of days. I believe this is because of recent
exit abuse incoming to their networks.
185.220.100.253
192.42.116.210
192.42.116.216
(C) MIT is using some third party tools (I think it is
https://check.spamhaus.org/ plus some Team Cymru equivalent) to get a
list of scary addreses and auto filter them. This list is still huge,
and it isn't MIT specific -- I think many other universities and orgs
around the world also filter using it, for example the UCSD relay:
UCSD blocking Tor relay addresses on its border (#97) · Issues · The Tor Project / Network Health / Analysis · GitLab
102.211.56.12
102.211.56.13
141.98.11.131
141.98.11.62
164.215.103.126
166.88.225.109
166.88.225.48
166.88.225.94
176.65.138.62
176.65.142.171
176.65.142.173
176.65.149.100
176.65.149.105
176.65.149.207
176.65.149.209
176.65.149.57
176.65.149.65
176.65.149.84
176.65.149.87
176.65.149.88
176.65.149.96
176.65.149.97
185.56.83.83
193.142.146.239
193.142.146.43
193.32.162.104
193.32.162.96
204.76.203.3
45.148.10.111
45.148.121.112
45.153.34.197
45.9.168.103
45.9.168.18
45.9.168.192
80.94.92.106
80.94.92.92
86.54.42.232
87.121.79.112
87.121.79.89
93.123.109.116
and after working on the scanning tools a bit more today, I realize
that the above list is maybe an undercount, because I haven't looked to
see if each relay's IPv6 address is on the spamhaus list, and I found
at least one relay where moria1 was voting not Running where the IPv4
address worked fine but the IPv6 address was filtered at MIT's gateway:
https://check.spamhaus.org/results/?query=2a0f:df00:0:255::196
Similarly, my current scripts don't distinguish port-specific blocking,
where it looks likely that MIT blocks outbound port 445 connections,
causing me to mark one of the relays at each of these addresses as
not Running:
193.189.100.194
193.189.100.195
193.189.100.196
193.189.100.197
193.189.100.198
193.189.100.199
193.189.100.200
193.189.100.201
193.189.100.202
193.189.100.203
193.189.100.204
193.189.100.205
193.189.100.206
(D) And then there is the fourth category, of relays that seem to be
censored on *their* side from reaching moria1's IP address. Verizon for
example has filtered all traffic to/from my specific IP address for the
past years, which means people in Verizon can't bootstrap from moria1,
and moria1 can't reach relays running at Verizon. But it's a lot more
than just Verizon:
102.208.216.153
103.70.13.227
113.20.28.216
113.20.28.243
113.20.31.38
130.61.30.37
132.248.241.5
14.169.229.78
146.59.19.112
148.56.77.121
148.75.213.197
175.33.91.103
178.254.37.2
185.12.95.150
185.231.102.51
190.22.45.81
192.18.144.19
192.18.154.45
192.18.159.101
200.28.69.3
208.109.189.114
208.109.214.243
208.109.215.188
24.191.62.109
51.15.59.15
67.81.164.219
68.196.118.127
72.167.47.69
73.200.211.73
77.166.188.222
83.168.88.144
87.251.66.159
89.248.165.40
91.250.81.52
92.205.129.7
92.205.17.93
92.246.84.133
94.23.172.32
95.89.13.221
Part of the issue for this category is that moria1's IP address has been
in use longer than many of the other dir auths, so it has had time to
accumulate in various other firewall rules.
I could move moria1 to a nearby IP address and probably get around a lot
of this category of blocking (most of these places seem to filter based
on the IP address and not the whole netblock), but hopping around doesn't
seem like a sustainable solution. I could also abandon MIT as a dir auth
location, using phrases like 'incremental authoritarian tendencies'
(the MIT network sure wasn't like this when I started running the dir
auth there), and maybe I will end up doing that, but I don't think it has
come to that quite yet. We have broader issues with connectivity between
relays, and moving the whole Tor network to Iceland isn't where we want
to end up: we need to instead figure out ways to reduce the impact on the
Tor network of these censorship "best practices" that are increasingly
being deployed all around the internet.
Sharing on tor-relay list as the ticket that caught my attention doesn't allow me to comment as I'm not part of the "project": MIT had been accumulating Tor IP addresses on its border blocklist (#90) · Issues · The Tor Project / Network Health / Analysis · GitLab
I think if you have a gitlab account, you should be able to comment
on this ticket. Are you logged in?
--Roger
···
On Fri, May 30, 2025 at 06:12:26AM +0000, Tor at 1AEO via tor-relays wrote:
_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org