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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev