[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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

#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):

 Some more links:

 http://www.w3.org/TR/webrtc/#peer-to-peer-data-example

 https://bitbucket.org/webrtc/codelab#markdown-header-step-5-set-up-a
 -signaling-server-and-exchange-messages

 [http://tools.ietf.org/html/rfc5245#section-2 Overview] of ICE operation:

 1. each side, L/R finds out its own "candidate addresses" - addresses it
 might be contacted on, LAN or WAN or internet. then it sides this
 information to the other side via the signalling channel.
 2. each side forms candidate-pairs out of these address, and sorts them in
 priority order
 3. each side performs connectivity checks using each of these candidate-
 pairs.
 4. the controlling agent (either L/R) nominates a candidate-pair to use
 for the data channel

 In the option where we are using the facilitator rendezvous as a simplex
 signalling channel, we have some differences from plain ICE which assumes
 a duplex signalling channel:

 a. The client, L, is unable to directly receive the list of candidate
 addresses from R. However, if R's connectivity checks reach L, then L
 implicitly knows R's candidate address (or, now the actual address that
 works) this way. (This requires that L can authenticate R, the next
 point.)
 b. ICE assumes L and R [http://tools.ietf.org/html/rfc5245#section-2.5
 know each other's keys], but L cannot receive from R. Instead, the
 facilitator can give R a token that it can present to L as authentication.

 In both those situations, at present I don't know if we can fit those
 tweaks into the standard ICE flow that the WebRTC code implements. In (a)
 we essentially require (1) and (2) to occur concurrently, and in (b) we
 need some non-standard form of authentication that would probably involve
 the facilitator certifying R. (Also at the moment the facilitator only has
 an encryption key, not a certification key; we ought not to mix key uses
 unless we can prove it's secure to do so.)

 I'll continue to investigate.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5578#comment:23>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs