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

On Wed, Sep 30, 2015 at 05:12:53PM +0200, Tim Wilson-Brown - teor wrote:

Hi All,

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

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.)

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.

Note that we considered making the single-onion services proposal (Tor Proposal 252) include a NAT punching option. We didn't for a few reasons.

1. Get the proposal out there. We can always add other protocols either as part of the proposal or in a new one.

2. Double-onion services already provide NAT punching. The performance delta of a sesqui-onion service (onion circuit on one side, roughly half an onion circuit on the other) is not as significant as for plain single-onion services and so yet another protocol to design, maintain, keep compatible, be a counter to new design innovations might not be worth it.

3. Most importantly, Tor generally follows the onion routing philosophy of making trade-offs that make more users more secure with an eye to making the most vulnerable or sensitive the norm.

On the one hand this means things like building for interactive circuits w/ relatively low latency. This is in theory less secure than, e.g., mix based remailers against global external observing and partial relay compromising adversaries. But in practice this leads to much larger networks (making it harder to be global) and leads to millions vs. hundreds of users with greater diversity of use motivation and behavior (making the fact of usage less interesting of itself to adversaries). Cf. my "Why I'm Not An Entropist".

On the other hand, we made the circuits use three relays. Most users would most of the time likely be fine with a one-relay circuit. By this I mean that an adversary that actually intends to do something that is harmful to them intentionally or collaterally is likely countered by a one-relay circuit, which would have a significant performance impact. But this would mean that the users who do need and use three-relay circuits would be much more rare and interesting, easy to separate out, etc. Also the relays themselves become more valuable to compromise (or set up your own, or bridge by owning the ISP) to an adversary, which increases threat to the network itself. For these and other reasons the default for tor circuits has three relays.

Now let's apply this worldview to the sesqui-onion NAT punching case. In a world with single-onion services and double-onion services, this is splitting off the double-onion anonymity set rather than the single-onion set, regardless of what Tor Proposal the protocol is in. So, the users that do require the server location protection that double-onion services provide becomes a much smaller fraction making them more likely interesting/worth pursuing/easier to identify/less plausibly able to claim they only wanted to have better circuit authentication/etc. than if the sesqui-onion services were not an equally easy option to set up.

Also, given at best ambiguously user-understood threat environments, and the well-documented tendency to choose in practice performance/ease against hyperbolic discounting of threats for using encryption and other security measures, we can assume that many will opt for the better performing choice of sesqui-onion services when perhaps they should not have. All the more so in the less-easily understood case of onion services vs. plain client-to-public-destination Tor use. Similar also to the one vs. three relay option, pwning relays by any of the means mentioned two paragraphs above makes it more effective to identify onion services in the sesqui-onion case. Thus putting additional threat pressure on the network itself. (I recognize similar things could be said of single vs. double onion services in general. I have some responses there, but I am already going on overly long as usual.)

These to me are counter-arguments to the advantages of a NAT punching sesqui-onion protocol. I don't question the many clear advantages of having such a protocol. But to me the above make it too great a trade-off to develop them for easy deployment. I don't think the answers concerning this trade-off are just obvious. So I encourage continued examples and discussions of their use. But I would like to be convinced that they outweigh the above (and possibly other examples of) trade-offs before I would support their development and promotion.

aloha, Paul