I spent some time looking for the cause of high rates of anomalies in
OONI's torsf test:
https://explorer.ooni.org/chart/circumvention?since=2022-04-06&until=2022-0…
I looked at the recently available (https://github.com/ooni/backend/issues/573)
stunreachability measurements, to test whether the Snowflake connections
were failing at the STUN phase.
In summary, 3 of the pool of 12 STUN servers are inaccessible in Russia.
One of them is blocked by censorship in Russia, and the other two look
like geoblocking of Russian clients by the STUN service. I don't think
the loss of 3 STUN servers is likely to be a cause of many connection
failures; therefore I think the explanation lies elsewhere.
Here are the charts:
https://explorer.ooni.org/chart/mat?probe_cc=RU&test_name=stunreachability&…stun.voip.blackberry.com and the IP address 178.239.90.248 are on the
unified register of blocked sites, the entry dated 2017-04-28:
https://reestr.rublacklist.net/record/530002/
Here's a measurement showing the test timing out:
https://explorer.ooni.org/measurement/20220224T192519Z_stunreachability_RU_…stun.stunprotocol.org is not on the unified register as far as I can
tell, nor are its IP addresses 18.191.223.12 and 2600:1f16:8c5:101::108.
This domain resolves to 127.0.0.1 or ::1 for requesters located in
Russia. Here's a sample measurement:
https://explorer.ooni.org/measurement/20220224T111232Z_stunreachability_RU_…
Using ooni-sync, we can see that the domain resolves incorrectly only in
Russia and Ukraine:
$ ./ooni-sync -directory stunreachability test_name=stunreachability since=2022-05-18 until=2022-05-19
$ jq -r 'select(.test_keys.endpoint=="stun.stunprotocol.org:3478")|[.probe_cc,(.test_keys.queries[].answers[]?|(.ipv4? // .ipv6?)),.probe_network_name,.test_keys.failure]|@tsv' stunreachability/* | sort
...
IT 18.191.223.12 2600:1f16:8c5:101::108 Vodafone Italia S.p.A.
IT 18.191.223.12 2600:1f16:8c5:101::108 Vodafone Italia S.p.A.
KZ 18.191.223.12 Kar-Tel LLC
LK 18.191.223.12 2600:1f16:8c5:101::108 Mobitel Pvt Ltd
LT 18.191.223.12 2600:1f16:8c5:101::108 Telia Lietuva, AB
MX 18.191.223.12 2600:1f16:8c5:101::108 Mega Cable, S.A. de C.V.
MX 18.191.223.12 Mega Cable, S.A. de C.V.
NL 18.191.223.12 2600:1f16:8c5:101::108 T-Mobile Thuis BV
RU 127.0.0.1 ::1 Cloudflare, Inc. generic_timeout_error
RU 127.0.0.1 ::1 Iskratelecom CJSC generic_timeout_error
RU 127.0.0.1 ::1 JSC "ER-Telecom Holding" generic_timeout_error
RU 127.0.0.1 ::1 JSC "ER-Telecom Holding" generic_timeout_error
RU 127.0.0.1 ::1 JSC "ER-Telecom Holding" generic_timeout_error
RU 127.0.0.1 ::1 Novotelecom Ltd generic_timeout_error
RU 18.191.223.12 PJSC "Bashinformsvyaz"
SE 18.191.223.12 2600:1f16:8c5:101::108 Telia Company AB
SE 18.191.223.12 Vetenskapsradet / SUNET
SG 18.191.223.12 2600:1f16:8c5:101::108 Leaseweb Asia Pacific pte. ltd.
TW 18.191.223.12 2600:1f16:8c5:101::108 <unknown>
TW 18.191.223.12 2600:1f16:8c5:101::108 <unknown>
UA 127.0.0.1 ::1 Virtual Systems LLC generic_timeout_error
US 18.191.223.12 2600:1f16:8c5:101::108 AT&T Services, Inc.
US 18.191.223.12 2600:1f16:8c5:101::108 AT&T Services, Inc.
US 18.191.223.12 2600:1f16:8c5:101::108 CABLE ONE, INC.
...
stun.altar.com.pl is not on the unified register, nor is its IP address
176.119.42.11. Its failures only start on 2022-03-09. Its domain usually
resolves correctly, but in Russia the actual STUN phase usually results
in a timeout:
$ jq -r 'select(.test_keys.endpoint=="stun.altar.com.pl:3478")|[.probe_cc,(.test_keys.queries[].answers[]?|(.ipv4? // .ipv6?)),.probe_network_name,.test_keys.failure]|@tsv' stunreachability/* | sort | grep RU
RU 176.119.42.11 Cloudflare, Inc.
RU 176.119.42.11 Iskratelecom CJSC generic_timeout_error
RU 176.119.42.11 JSC "ER-Telecom Holding" generic_timeout_error
RU 176.119.42.11 JSC "ER-Telecom Holding" generic_timeout_error
RU 176.119.42.11 JSC "ER-Telecom Holding" generic_timeout_error
RU 176.119.42.11 Novotelecom Ltd generic_timeout_error
RU 176.119.42.11 PJSC "Bashinformsvyaz" generic_timeout_error
But there are also errors for networks in Spain, Hong Kong, Indonesia,
and the United States:
$ jq -r 'select(.test_keys.endpoint=="stun.altar.com.pl:3478")|[.probe_cc,(.test_keys.queries[].answers[]?|(.ipv4? // .ipv6?)),.probe_network_name,.test_keys.failure]|@tsv' stunreachability/* | sort | grep error
ES 176.119.42.11 Orange Espagne SA generic_timeout_error
HK Hong Kong University of Science and Technology generic_timeout_error
ID Telekomunikasi Indonesia (PT) generic_timeout_error
RU 176.119.42.11 Iskratelecom CJSC generic_timeout_error
RU 176.119.42.11 JSC "ER-Telecom Holding" generic_timeout_error
RU 176.119.42.11 JSC "ER-Telecom Holding" generic_timeout_error
RU 176.119.42.11 JSC "ER-Telecom Holding" generic_timeout_error
RU 176.119.42.11 Novotelecom Ltd generic_timeout_error
RU 176.119.42.11 PJSC "Bashinformsvyaz" generic_timeout_error
US 176.119.42.11 2607:7700:0:18::b077:2a0b T-Mobile USA, Inc. generic_timeout_error
US 176.119.42.11 2607:7700:0:1f:0:1:b077:2a0b T-Mobile USA, Inc. generic_timeout_error
US 176.119.42.11 2607:7700:0:7::b077:2a0b T-Mobile USA, Inc. generic_timeout_error
US 176.119.42.11 T-Mobile USA, Inc. generic_timeout_error
US 176.119.42.11 T-Mobile USA, Inc. generic_timeout_error
To me this looks like selective denial of service to certain client
networks.
Last weeks discussion on this topic:
http://meetbot.debian.net/tor-meeting/2022/tor-meeting.2022-05-12-15.58.log…