STUN servers reachability

[NullHypothesis]

The WebRTC-based Snowflake circumvention system relies on STUN for bootstrapping connections. So far, we have used Google's STUN server stun.l.google.com:19302 hard-coded in Snowflake but it ended up getting blocked in China. It would be useful for OONI to monitor the reachability of STUN servers so we get an idea of what servers work where.

STUN is based on UDP, so testing a STUN server is not as simple as trying to establish a TCP connection. I suggest we send a "binding request" to a server and label it as reachable if it responds with a "binding response."

I found several STUN client implementations in Python so we won't have to reinvent the wheel. We should come up with a list of popular STUN servers that are worth probing.

[hellais]

Thanks for filing this issue @NullHypothesis !

I moved this issue into the ooni/spec repo as the first step is to write a specification for the test.

[bassosimone]

@hellais @NullHypothesis our code base is now increasingly in Go. Therefore, we can perform these measurements using Go, as we're starting to do with OBFS4 in #227. Is my understanding correct that integrating the client/lib of https://github.com/keroserene/snowflake we will be able to provide a measurement of whether we can use snowflake from a given vantage point?

(I guess, speaking of this issue proper, the question is whether we can feed STUN servers to snowflake and see whether they can be used to bootstrap correctly.)

[FedericoCeratto]

@bassosimone STUN is used by many application, sometimes with WebRTC, and often to make audio and video calls without bouncing through a server. It could make sense to have a test function can be reused by other tests.

[cohosh]

I think it makes more sense here to just test STUN servers. As @FedericoCeratto mentioned, these tests can be useful for applications other than Snowflake that rely on STUN servers for WebRTC. The Snowflake client library doesn't allow for an easy separation between different steps in a snowflake connection. The steps are:

1. Get candidates from a STUN server
2. Contact the broker to get a proxy
3. Make a WebRTC connection to a proxy

If a connection fails, it's difficult to tell through the API where exactly it failed. To do this, I had to implement a lua script that parses packet captures.

If we want to go the full Snowflake route, here are some things to keep in mind:

• The webrtc library will pull in '''a lot''' of dependencies
• The official repository for snowflake is https://gitweb.torproject.org/pluggable-transports/snowflake.git/

[bassosimone]

@NullHypothesis we're going to add the stun experiment to the tests we run in the circumvention group. Any other endpoint to check apart from stun.l.google.com:19302?

See ooni/probe#1185

[cohosh]

We're going to want to add more STUN endpoints later. How difficult will that be to do?

[bassosimone]

@cohosh we will probably need to add a call to our probe-services to fetch the list. Especially if the list is static and changes slowly, I think it's not a concern to do this now or when needed.

[cohosh]

Okay great. The google endpoint will work for now. And the list will indeed be mostly static and change slowly since we have to ship the defaults with Tor Browser :)

[bassosimone]

Great, thank you!

[bassosimone]

Removed effort, since this is done. Added to Sprint 15 so we ensure we close this.

[bassosimone]

Shift to a subsequent sprint. We are mostly done but probably we won't release this in this Sprint because we also need to have specific UI done in the mobile and desktop apps.

[bassosimone]

The experiment has been implementing. We're tracking how we're landing the experiment to the probes in the following epic issue: ooni/probe#1202.