[tor-dev] Introducing Snowflake (webrtc pt)

[Serene]

On Mon, Jan 25, 2016 at 5:55 PM, Tim Wilson-Brown - teor
<teor2345 at gmail.com> wrote:
> I'm connected using dual-stack IPv4 and IPv6, but I'm not sure if that's the
> issue.
> -----
> [snip]
> 2016/01/26 12:23:21 Sending offer via meek channel...
> Target URL:  https://snowflake-reg.appspot.com/
> Front URL:   www.google.com
> 2016/01/26 12:23:25 MeekChannel Response:
> 200 OK
>
> 2016/01/26 12:23:25 Received Answer:
> [snip]

Since the offer & answer exchanged successfully, I'm fairly certain
this failed during ICE negotiation. In most cases, the public ip
candidates given by STUN servers are sufficient for peers to negotiate
a working p2p path. But sometimes, maybe 14% of the time [1], this
isn't enough -- usually due to symmetric NAT / lack of port
preservation, and a TURN relay is required as a last resort.

I haven't yet configured TURN in either the client or the proxy, so
this seems the most likely cause. I can update that to see if it works
for you. We should probably setup some sort of Snowflake test suite
for various NAT topologies...

Later on, this may mean more complications for that fraction of users
(TURN relays could get blocked in filtered zones). We do have some
plan to inform clients of temporary TURN servers through the domain
fronted signalling channel eventually, which may help. Also, once
snowflake proxies & clients are multiplexed, perhaps the likelihood
that TURN continuous to be absolutely required for every pair of peers
greatly decreases and we might be fine again. More thought is needed
here.

[1] old numbers from http://webrtcstats.com