[tor-talk] Can NAT traversal be Tor's killer feature?
helder at discor.de
Fri Jul 11 20:27:45 UTC 2014
On Thu, Jul 10, 2014 at 10:41 PM, str4d <str4d at i2pmail.org> wrote:
> On 07/11/2014 12:12 AM, Helder Ribeiro wrote:
>> 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  provides this functionality via a layer 3 VPN. It works
> with Tor Hidden Services (ocat) and I2P tunnels (gcat ), 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.
That's awesome! Didn't know about it, thanks to you and Lunar for
pointing it out. Will research further.
> 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).
This seems like an excellent Summer of Code job :) I'm not at all
familiar with any tor-related codebase and I'm a security noob, but
this is something I could try putting together.
> 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.
Good point. If complete transparency isn't possible for all cases, it
might be for a good enough subset.
Otherwise, having a dead-simple library that makes it easy for
developers to abstract out the IP parts and allow using hidden
services instead could be a close second.
> As an aside, most of the applications that you mention generally use
> UDP packets, which Tor does not yet support (AFAIK). I2P does support
>  https://www.onioncat.org/
> 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-----
> -----END PGP SIGNATURE-----
> tor-talk mailing list - tor-talk at lists.torproject.org
> To unsubscribe or change other settings go to
Apoie a transparência no voto eletrônico:
CED4 BB85 FBC5 661E 56B2 3D5C DCE5 C2D2 FC19 843C
Code is politics.
Se você usa a Wikipédia, doe mensalmente para mantê-la no ar:
More information about the tor-talk