[tor-dev] Onion Services and NAT Punching

[David Stainton]

Hi All, Hi Tim!

> Do you know a use case which needs Single Onion Services and NAT punching?

chyaa! NAT has ruined the Internet, violates the end to end principal
and make it more difficult to develop decentralized systems.
*deep sigh*...
Obviously, centralized systems design contributes to human rights
violations... so I feel compelled to point out that if the Single
Onion service does not provide NAT punching then this will discourage
developers from building decentralized systems.

pro-human-rights == decentralized NAT punching transport

> We’re wondering if there are mobile or desktop applications / services that
> would use a single onion service for the performance benefits, but still
> need NAT punching. (And don’t need the anonymity of a hidden service.)

I am currently working on Tor integration for Tahoe-LAFS and (yes,
both of them) IPFS. I think many users would be interested in using a
NAT-punching single onion service for this. This would allow slightly
better performance for users hosting an IPFS or Tahoe-LAFS storage
node at their home behind a NAT device.

These tradeoffs you specified for single versus double onion services
listed here in my NAT penetration tradeoffs chart here:

https://github.com/telekommunisten/nat-penetration-tradeoffs


I think developers of decentralized systems will get lots of benefit
from using onion services as their NAT penetration method... instead
of ICE,  NAT-PMP, U-PnP... because it's reliability doesn't depend on
the quality of the NAT device and it will work on any network
topology. It's true that TURN would work on all network topologies...
but this is a central proxy server and therefore not freely available
and brittle (it's a single point of failure).

Feel free to make changes or corrections to this NAT penetration
tradeoffs document, by sending a pull request. Soon I'll add to the
reference links on the bottom prop224 and related onion service
document links.


cheers!

David

> Single Onion Services:
> * can’t do NAT punching, (they need an ORPort on a publicly accessible IP
> address),
> * locations are easier to discover, and
> * have lower latency.
>
> Hidden Services:
> * can do NAT punching,
> * locations are hard to discover, and
> * have higher latency.
>
> Are there any use cases that:
> * need NAT punching,
> * don’t need service location anonymity, and
> * would benefit from lower latency?
>
> Thanks
>
> Tim
>
>
> Tim Wilson-Brown (teor)
>
> teor2345 at gmail dot com
> PGP 968F094B
>
> teor at blah dot im
> OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
>
>
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>