[anti-censorship-team] OONI stunreachability measurements from Russia

David Fifield david at bamsoftware.com
Thu May 19 06:39:48 UTC 2022


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-05-18&probe_cc=CN%2CIR%2CRU%2CCA
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&since=2022-02-15&until=2022-05-20&axis_x=measurement_start_day&axis_y=domain

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_12389_n1_eX5qF6CEl2m85NAw?input=stun%3A%2F%2Fstun.voip.blackberry.com%3A3478

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_31213_n1_c2duCNBfy5dl4jr2?input=stun%3A%2F%2Fstun.stunprotocol.org%3A3478
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.html#l-42


More information about the anti-censorship-team mailing list