[tor-talk] Can NAT traversal be Tor's killer feature?

[str4d]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 07/11/2014 12:12 AM, Helder Ribeiro wrote:
> tl;dr: how about a virtual global flat LAN that maps static IPs to 
> onion addresses?
> 
> We all know the story. Random feature gets unintentionally picked
> up as the main reason for buying/using a certain product, despite
> the creator's intention being different or more general. (PC: 
> spreadsheets; Internet: porn; smartphones: messaging.)
> 
> Exhibit 1: Ricochet IM (https://ricochet.im) uses onion addresses 
> (each client runs a hidden service) as a sort of *static anonymous
> IP address* and, because it's static, it's the user's identity too,
> in a p2p/serverless chat app. It's dead simple, works like a charm
> behind the firewall at work, and protects metadata, which no other
> chat app/protocol I know does.
> 
> Exhibit 2: OnionShare (https://onionshare.org/) does the same for
> file sharing, and it's actually a much *easier* user experience to
> send large files this way than any other. Why? "Static anomyous IP"
> (onion address) and NAT traversal because all hidden services work
> by making *outgoing* connections to Tor relays and don't need any
> open ports.
> 
> Those are two great apps that, unlike Tor Browser (which I love
> very much, but hear me out), *improve* the user experience, through
> Tor, in comparison with the mainstream (OnionShare even more so).
> The user might not even care about security or anonymity, it's just
> a better experience, period.
> 
> In this case, you don't have to convince people to make sacrifices
> in the name of privacy, you just have to show them something they
> want.
> 
> That's when natural demands kicks in and suddenly you're not
> pushing water uphill anymore, you've changed the landscape and it
> flows in the direction you want. Like when Tesla made electric cars
> that people buy *despite* being electric, not because of it.
> 
> As good as Ricochet and OnionShare are, they still had to go
> through the trouble of integrating hidden services themselves.
> 
> If there is a virtual network interface that transparently maps
> static IPs to onion addresses, all sorts of things could benefit
> from the backward compatibility (old games, IP-based voip,
> screensharing, real-time collaborative writing, etc.) and new ones
> could be built a *lot* more easily.

OnionCat [0] provides this functionality via a layer 3 VPN. It works
with Tor Hidden Services (ocat) and I2P tunnels (gcat [1]), by
calculating a unique IPv6 address from the hidden service ID or I2P
Destination. This has the advantage that you can give an IPv6 address
to an application and it will resolve correctly anywhere.

OnionCat is not as user-friendly as I think you would like, primarily
because it requires that the Tor HS or I2P tunnel is already set up.
But further integration could be done (certainly with I2P, because all
tunnels automatically have a Destination).

One downside to this method is that there is a possibility of address
collisions. I am not familiar with the particular algorithm OnionCat
uses to map IPv6 addresses to .onions, but in the I2P case at least,
the IPv6 address space is not large enough to hold all possible I2P
B32 addresses (which are 52 characters long). The Tor proposal for
next-gen HSs outlines a format for new .onions that is nearly
identical to I2P B32s, and will have the same problem.

The solution that I2P is considering for this is to remove the
requirement for a global IPv6 <-> .b32.i2p mapping, and instead use a
local ephemeral mapping on a virtual interface combined with a local
DNS resolver. This would enable backwards compatibility for
applications that support hostnames.

As an aside, most of the applications that you mention generally use
UDP packets, which Tor does not yet support (AFAIK). I2P does support
datagrams.

str4d

[0] https://www.onioncat.org/
[1]
https://www.cypherpunk.at/onioncat_trac/browser/trunk/i2p/Garlicat-HOWTO

> 
> [ZeroTierOne
> (http://redecentralize.org/interviews/2013/07/30/02-adam-zerotierone.html)
>
> 
does this, but doesn't worry about privacy.]
> 
> Of course massive use would probably crush the current network,
> but uptake would be gradual, and I imagine demand has a greater
> power to drive capacity than the other way around.
> 
> The only thing better than serving the privacy-conscious is
> serving privacy to those who don't even know they want it.
> 
> I'm nowhere near an expert and I could be just talking out of my
> ass, so please let me know if this is completely stupid and would
> never work. Thanks!
> 
> Cheers, Helder
> 
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJTv0BwAAoJEIA97kkaNHPnUmEP/1XreMW+mivJDpOmpex++7CM
XtodR25/fY7aDp4LLU808HokK5pNo88Lmh6KiT6S41A2CNV5KIfpp8+d5yU2Ux4+
Lx7mfWaWSxxEbK/GbnrJVEbRb0JK/csniBAoMB3rRXgBrN7nypEzUBvwcB3gHYxy
cce3RndWwp2+6P8xQHtonvtSUQCVIdDrjt84h0//9URrypw+BVW1zP94c0eaHQF/
49uzseP/KnJyOxrpw66RaEqhMhQYK6ZgwVVR1xYLvIsAHTTnNFNef4uf9FtDGYj7
2/incGTnaiV0paxH2UEYC6gkSqb/Kdek/4fo7ve5SeowbjmC+Bxe6Za8sIr0c6N6
5EWjNtZXeMwyNvsz4TNps9lnQVly+4QGbT7kZwtDB6UkFxYnRaJ8E8qAJmOKYcyO
Y2mV25HbOw1g1F+tfUdzMA+fbXLq2ww1bt5qJifRG7cgVng0kPSIS8dMdnzAUbZ/
oGRiMWHX15Opt1wlCpVQ5ZUC4htLxnYr+IJomXGa8Qk5aI3qwZXFeUhCLvxJvtgk
TvCIEilFURA/3vNP6QMFeto8zuLZflwexSvLUFlSMjZhg11xSuV/iob3RqzBwpzV
BBrPd2QkQ7tIbiAfq3/ZZM/cICdivw5slgSUJw114S4iig+Ub4RXPQWbnwWvWUnB
W250BYiuyljFtX6N9exI
=YXw1
-----END PGP SIGNATURE-----