Can NAT traversal be Tor's killer feature?

I&#x27;ve run an IRC bouncer and SSH reverse tunnels over Tor for years. Not for the privacy but just for the ease of use. Also it reduces concerns with maintaining up to date linux hosting. While the risk of my .onion being discovered through the cat-and-mouse game that is de-anonymizing .onion&#x27;s may permit some 3 letter agency to discover and root my host I at least reduce the attack service drastically by completely removing internet script kiddies from the threat model. So their is a security benefit in addition to the NAT transversal. The NAT transversal really makes a different and very easy reverse workflow possible. With some simple haggling with scripts and SSH you can reverse almost anything that is low bandwidth. I totally agree there is something to the ease of use provided that services have not fully explored yet.<p>And since most single-peer to home services never require an exit node bandwidth is never an issue. File transfer, remote mail, even a reverse tunnel to use a home IP as your exit node, all work with little to no bandwidth constraints. I really believe there are services to be built on this ease of use. Things that utilise these features without requiring one understand SSH reverse tunnels and the likes.<p>Finally, somehow I think the more services built on such a model the better we will understand how to fix some of the major flaws of the internet as a whole. Namely discrimination based on GeoIP comes to mind. If the internet were built in this manner instead of addressing a service I could have it address me through my own .onion reverse I think location discrimination would become a much more complex task. GeoIP is becoming much more fundamental. as the xkeyscorerules100.txt shows GeoIP is no longer just something used by media companies to prevent someone watching TV out of country and is today used to determine citizenship and basic civil liberties.

<p><pre><code> As good as Ricochet and OnionShare are, they still had to go through the trouble of integrating hidden services themselves. </code></pre> This is definitely part of the problem. I looked into tightly integrating Tor &#x2F; Hidden Service connectivity into some apps, but was disappointed there aren&#x27;t widespread libraries, and that you have to fall back to asking the user to install Tor separately. At least there is a bit of a control-plane API to configure Tor from your App over sockets.<p>One library I was able to find for Tor called Orchid: <a href="http://www.subgraph.com/orchid.html" rel="nofollow">http:&#x2F;&#x2F;www.subgraph.com&#x2F;orchid.html</a> if you browser through the code it will give you a real appreciation for the complexity of the protocol. So after seeing that, I didn&#x27;t feel so bad about the lack of Hidden Service libraries. But the current process of setting up a Hidden Service is definitely not for the average user.

Have you looked into WebRTC much? It supports arbitrary (text or binary) data transfer between browsers, in both TCP-like and UDP-like modes, with inbuilt NAT-busting (both STUN and TURN). It does NAT-busting rather than VPN, so it&#x27;s faster than either Tor or a VPN.<p>So if the reason you wanted NAT traversal was &quot;my (browser|game|filesystem) wants to share data with someone else&#x27;s&quot;, WebRTC is a far easier answer, and is now available to most browsers[1] without extra software installs. It does involve a privacy loss of your connection details to the STUN&#x2F;TURN server, but the signaling server cannot decrypt your (DTLS) communication.<p>If the reason you want a global LAN isn&#x27;t those things, what is it?<p>[1]: Available outside browsers, too: see e.g. my Node WebRTC chat client -- <a href="https://github.com/cjb/serverless-webrtc" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;cjb&#x2F;serverless-webrtc</a> -- or the native C++ API.

Here&#x27;s a related way to maybe add a ton of new relays to the Tor network without having to go all &quot;transparent through virtual network interface&quot; right from the start:<p>1. Make a torrent tracker that serves out peer onion addresses (OAs?) instead of IPs;<p>2. Fork Popcorn Time, make it create a hidden service for itself and connect to the OA tracker;<p>3. Make the Popcorn Time fork also a relay by default. You&#x27;ll add a lot of load to the network, so you have to give back.<p>Probably wouldn&#x27;t be able to _stream_ anything, but otherwise should work.

NAT traversal isn&#x27;t a problem these days. The issue is bootstrapping the traversal. Use the hidden services to exchange real IPs and set up the VPN link to route around the slowness of Tor.

I think this is kind of related to Geoffrey Goodell&#x27;s argument from 2006 in<p><a href="http://www.sobco.com/papers/tr-06-06.pdf" rel="nofollow">http:&#x2F;&#x2F;www.sobco.com&#x2F;papers&#x2F;tr-06-06.pdf</a><p>I was trying to remember who at Harvard had written about this and I think that&#x27;s probably the report I was thinking of. Maybe I should also suggest his thesis<p>ftp:&#x2F;&#x2F;ftp.deas.harvard.edu&#x2F;techreports&#x2F;tr-12-06.pdf

Relevant: <a href="https://github.com/ipop-project/ipop-tincan" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;ipop-project&#x2F;ipop-tincan</a><p>Libjingle is the underlying library of Google Talk and WebRTC implementations.