[tor-bugs] #5578 [Flashproxy]: Investigate WebRTC for flash proxy NAT punching

[Tor Bug Tracker & Wiki]

#5578: Investigate WebRTC for flash proxy NAT punching
----------------------------+-----------------
     Reporter:  dcf         |      Owner:  dcf
         Type:  task        |     Status:  new
     Priority:  normal      |  Milestone:
    Component:  Flashproxy  |    Version:
   Resolution:              |   Keywords:
Actual Points:              |  Parent ID:
       Points:              |
----------------------------+-----------------

Comment (by infinity0):

 I just had a play about with cjb's serverless-webrtc demo. I tried to
 tweak the SDP answer that the session creator (i.e. client) expects to
 receive back from the joiner (i.e. proxy), hoping that we could hard-code
 a fake answer and still have everything work - i.e. the proxy would do NAT
 traversal but the client would just sit there with a useless fake answer,
 and wait for the proxy to connect to it.

 Unfortunately, WebRTC has some pretty strong checks on the answer, namely
 fingerprint, ice-ufrag, and ice-pwd, which cannot be predicted in advance
 (see [http://tools.ietf.org/html/rfc5245 RFC 5245]). So, we will either
 need one of the following:

 - a duplex registration methods (http/appspot could be modified to do
 this). However, if the facilitator doesn't have a proxy ready to serve the
 client, it will need to wait for one, so that it can respond to the client
 (with the proxy's SDP answer).

 - tweak the webrtc implementation on the client side to work ''without
 checking'' the aforementioned attributes of the SDP answer. This is would
 be quite intensive and involve digging into WebRTC C++ code, and would be
 harder to maintain in the long run. But it would let us use all the
 existing registration methods.

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