On Fri, May 30, 2025 at 06:12:26AM +0000, Tor at 1AEO via tor-relays wrote:

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 https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/90 https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/98

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: https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/97 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 https://metrics.torproject.org/rs.html#search/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": https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/90

I think if you have a gitlab account, you should be able to comment on this ticket. Are you logged in? --Roger