Re: [tor-dev] Onion Services and NAT Punching

[Alec Muffett]

> On Oct 26, 2015, at 11:34, Alec Muffett  wrote:
>> Of course. All the cases where you set up a hidden service
>> exactly because your host is behing a NAT.
>> Like the webcam raspi I'm just booting up.
> 
> We run our tor daemons in a enclave network which can only connect outbound 
> to the Internet, or backwards into infrastructure.

Also, it's probably wise to point out that NAT-punching (and/or SOCKS-punching 
outbound) reduces cost of HS adoption for organisations that don't want to 
rejig their network architecture to permit "yet another listener"; it's an 
attractive proposition to say "it only connects outbound and rendezvouses 
(sic?) in the middle of the tor cloud" #ohThatsOkayThenNoFirewallChanges



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Onion Services and NAT Punching

[Alec Muffett]

> On Oct 1, 2015, at 06:15, Andreas Krey  wrote:
> 
>> Are there any use cases that:
>> * need NAT punching,
>> * don't need service location anonymity, and
>> * would benefit from lower latency?
> 
> Of course. All the cases where you set up a hidden service
> exactly because your host is behing a NAT.
> Like the webcam raspi I'm just booting up.

And like us.  We run our tor daemons in a enclave network which can only 
connect outbound to the Internet, or backwards into infrastructure.

-a



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Onion Services and NAT Punching

[Paul Syverson]

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

Re: [tor-dev] Onion Services and NAT Punching

[Aaron Johnson]

NAT-punching in single-onion services seems to me to be a clear functionality 
improvement with an unclear effect on security.

The NAT-punching protocol that we settled on at the dev meeting was:
  1. The single-onion service (SOS) maintains a direct connection to an IP.
  2. A client does an HSDir lookup
  3. A client simultaneously creates circuits to the IP and an RP of its 
choosing.
  4.  The client sends a connection request to the SOS via the IP, indicating 
the desired RP.
  5. The SOS creates a direct connection to the RP, completing the connection.
This makes the connection indistinguishable from an HS connection to the 
client’s guards and middles, except for the end-to-end latency of the RP 
circuit. The IP and RP can identify the SOS, which they can already do with a 
non-NAT SOS. So all we’ve done is make SOS clients look like HS clients 
instead. In fact, I like this so much that I would even argue to make all SOSes 
at least mimic this rendezvous behavior (which is easy to do even if they don’t 
want to maintain an IP connection).

With this understanding, it is clear that your arguments only work to argue 
that SOSes in general are not a good idea. Which is a fine enough argument. I 
think it’s a reasonable hope that new services are attracted to Tor as SOSes 
instead of being “converted” from HSes. Also,I see SOSes as the next step 
towards replacing insecure Internet protocols. They should be seen as a 
replacement for exit traffic in general and not a competitor to hidden 
services. And given that SOSes share 3-hop client circuits with exit circuits, 
perhaps we should try and make those two cases indistinguishable. It doesn’t 
seem impossible, although it probably requires adding some dummy steps to exit 
connections.

Best,
Aaron
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Onion Services and NAT Punching

[Nathan Freitas]

On Thu, Oct 1, 2015, at 01:15 AM, Andreas Krey wrote:
> On Wed, 30 Sep 2015 17:12:53 +, Tim Wilson-Brown - teor wrote:
> ...
> > Are there any use cases that:
> > * need NAT punching,
> > * don???t need service location anonymity, and
> > * would benefit from lower latency?
> 
> Of course. All the cases where you set up a hidden service
> exactly because your host is behing a NAT.
> 
> Like the webcam raspi I'm just booting up.

I have been looking at the use of Tor and Onion Services for Internet of
(Onion'd) Things applications, but broadly I haven't thought how and
when single onions could add extra benefit. Mostly in IoOT (IoO?) the
goal is to remove the centralized corporate clouds that are currently
used, and to protect your endpoints (house, car, office, etc) from
becoming easily discovered and compromised.

Accessing a home webcam ("dropcam" or "baby monitor" in the common
parlance) is the best example I can think of where you want all the Tor
goodness, and lower latency is also needed. Most of the other apps I can
think of can deal with async messaging and high latency (i.e.
change/check your thermostat settings).

+n
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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