[tor-bugs] #33666 [Circumvention/Snowflake]: Investigate Snowflake proxy failures

[Tor Bug Tracker & Wiki]

#33666: Investigate Snowflake proxy failures
-------------------------------------+------------------------------
 Reporter:  cohosh                   |          Owner:  (none)
     Type:  defect                   |         Status:  needs_review
 Priority:  High                     |      Milestone:
Component:  Circumvention/Snowflake  |        Version:
 Severity:  Normal                   |     Resolution:
 Keywords:                           |  Actual Points:
Parent ID:  #19001                   |         Points:
 Reviewer:                           |        Sponsor:
-------------------------------------+------------------------------

Comment (by cohosh):

 Okay here's a summary of what I've found:

 Tl;DR: I think you have a symmetric NAT setup at home, and anyone who does
 is going to have a lot of difficulty communicating with peers that have
 more restrictive NATs.

 === Analyzing the test SDPs ===

 - I ran your tests on my own home setup and found a success rate of 78%,
 which matches the success rate I got from my VPS set up today.

 - There's nothing different from the candidates as far as I can tell,
 although I think there still may be some unrelated bugs in the pion-webrtc
 ICE gathering in addition to the one in comment:13.

 === Background on NAT topology ===

 There are several different kinds of NATs and each kind has some variance
 possible due to different implementations:

 - Full Cone NAT (port forwarding): an internal IP:port is mapped to a
 fixed external IP:port and any outside party can send a packet to the
 internal IP:port by knowing the external address
 - Restricted Cone NAT: same as above, but an outgoing packet from the
 internal address to the outside party's address must be sent first
 - Port Restricted Cone NAT: same as above, but an outgoing packet from the
 internal address to the outside party's IP:port must be sent first
 - Symmetric NAT: the external IP:port of an outgoing packet depends not
 only on the internal IP:port but also the destination address.

 All but the symmetric NAT '''should''' work with STUN. That's because each
 party will send STUN connection request to the other party's candidates
 while also waiting to be contacted by the peer. This should satisfy the
 restricted cone NAT's requirement of outgoing packets to allow the peer's
 connection requests to punch through.

 I came across two different implementations of symmetric NATs:
 - Random mapping: each internal IP:port and destination address tuple are
 randomly assigned an external IP:port mapping
 - Progressive mapping: each IP:port and destination address tuple are
 assigned an external IP:port mapping that increments for each new tuple.

 === Something interesting about STUN ===

 I was going through some .pcap files from connection requests and noticed
 something interesting:

 1. The initial STUN binding request to the STUN server will return a
 success response with `XOR-MAPPED-ADDRESS [myaddr]:54576 and send an offer
 sdp with candidate
 `[myaddr] 54576 typ srflx raddr 0.0.0.0 rport 54576 generation 0`

 2. I receive the remote peer candidates
  `a=candidate:foundation 2 udp 2130706431 [peeraddr] 60459 typ host
 generation 0
   a=candidate:foundation 1 udp 1694498815 [peeraddr] 32932 typ srflx raddr
 0.0.0.0 rport 32932 generation 0`
 3. My client sends STUN binding requests to:

  `[peeraddr]:60459` and `[peeraddr]:32932`

 4. I get a binding request from the remote peer at `[peeraddr]:60459`
 5. I get a several binding success response from the remote peer with the
 follow `XOR-MAPPED-ADDRESS`'s:
  - `[myaddr]:56373`
  - `[myaddr]:54576`
  - `[myaddr]:47605`

 Only `[myaddr] 54576` appeared in my offer sdp.

 === Hypotheses and next steps ===

 I'm guess the above STUN behaviour of successful binding responses with a
 new `XOR-MAPPED-ADDRESS` provides a way for symmetric NATs to work some of
 the time. Specifically, my guess is that if the peer isn't behind a NAT or
 is behind a full cone or restricted cone NAT, it will accept incoming
 connections from the symmetric NAT and send the success response with the
 proper new `XOR-MAPPED-ADDRESS` and use that port instead of the signalled
 candidate port.

 If the peer is behind a port restricted cone NAT or a symmetric NAT, the
 binding requests from the symmetric NAT client can't get through. We might
 want to move on #25595 to verify this.

 The easiest way to solve this issues is to configure a TURN server (ticket
 #25596). I have doubts about how effective this will be from a censorship
 resistance standpoint, since it produces yet another more centralized set
 of IP addresses the censor can block.

 Another thing we can do is try to restrict our proxies to ones behind less
 restrictive NATs. Option (2) above can be changed to try to diagnose the
 NAT topology and this information can be given to the broker. We could
 also perhaps have clients become aware of their NAT topology and request
 more or less permissive peers depending on what they need.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/33666#comment:14>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online