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

Re: [tor-dev] Flashproxy alpha bundles



Roger Dingledine:
> Whether these various "look, no hands" punching tools and tricks can be
> done using only websockets on the remote side is a great question for
> somebody to answer.

By the way, I found it in their design paper.

Quote:

The fact that clients must not be behind NAT is an impediment to usability.
A NAT traversal mechanism that works within our threat model would be a
great
benefit. Typical NAT traversal technologies, such as STUN (Session Traversal
Utilities for NAT) [21] and RTMFP (Real Time Media Flow Protocol) [22], rely
on a stable third-party server to facilitate the connection, which is
trivially de-
feated by the censor blocking the third party by IP address. (Also we
believe
it is better to avoid informing a third party of each flash proxy
connection if it
can be avoided.) Tricks involving low-level packet manipulation, for
example pw-
nat [23], are not available to browser sockets. Ideally, any NAT
traversal scheme
will not require both the client and the proxy to know each other’s IP
address,
so that facilitator registration can remain unidirectional. New
technologies like
WebRTC [24] may fill this need in the future, if they become
sufficiently popular
that flash proxies’ use of them does not stand out as unusual.
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev