-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512

George Kadianakis wrote:

David Goulet dgoulet@ev0ke.net writes:

...

On 09 Apr (21:58:49), George Kadianakis wrote:

...

Hello,

I inline a proposal for Direct Onion Services. It's heavily based on the "encrypted services" proposal of Roger, but I refined it, made it more proposaley and enabled a few more optimizations. You can find the original piece here: https://gitweb.torproject.org/torspec.git/tree/proposals/ideas/

xxx-encrypted-services.txt

...

...

Feedback would be greatly appreciated.

...

First thanks for that! Really useful stuff.

...

Here are some specific points that I would like help with:

• Should we require a specially compiled version of Tor to

enable this feature? Like we do for tor2web mode? In this proposal, I didn't require any special compilation flags. I don't have strong opinions here.

IMO, I'm not sure this is useful. This feature requires prior knowledge of the HS operator to know what's a "Direct Onion Service" and decide that she wants that for her service. Thus, a torrc option seems enough. I don't see any reasons for this option that will limit deployment.

Yes, I also feel the same.

My main fear is sample torrc's that are being posted around the net and people just copy-paste them into their box: someone might not notice the DirectOnionServiceEnable option.

Perhaps this could be mitigated by alerting the user the first time Tor is started with this option enabled. This is obviously harder to do if Tor is started as a service, but it should be possible for manually-started Tor or TBB.

...

[snip]

...

3.2. One-hop circuits [ONEHOP]

When in this mode, the onion service establishes 1-hop circuits to introduction and rendezvous points. The onion service SHOULD also ignore cannibalizable 3-hop circuits when creating such circuits.

This looks like this for the rendezvous point case:

|direct onion service| -> RP <- client middle <- client guard <- |client|

This change allows greater speeds when establishing a hidden service circuit and reduces round-trip times. As a side-effect, busy onion services with this feature cause less damage to the rest of the network, since their traffic gets passed around less.

Would it be possible to drop the rendezvous part where the client could simply connect to the IP and then the circuit back to the HS would be used? (Though that would require that the client knows the HS it's trying to reach is a Direct Onion Service, could be mention in the descriptor?...)

I think that's indeed possible, but would require multiplexing multiple client connections on a single IP circuit, which Tor cannot do at the moment AFAIK. It is my understanding that it's not an easy change, but I'm pretty sure that I2P and other projects are doing it, so we could in theory take a look at how those guys do it.

I2P does have the ability to run "zero-hop" tunnels, yes - the router simply provides its own details for the tunnel entry point. But this probably isn't directly helpful for Tor because I2P is a packet-switched network, and it doesn't use separate rendezvous points for individual connections between Destinations.

For high-traffic services that don't require anonymity, we generally recommend using one-hop tunnels instead of zero-hop. This is primarily to avoid connection limits being exceeded on the hosting router. The speed hit of having an additional hop in the path is generally outweighed by the benefit of only having e.g. 8 incoming connections for a particular service, instead of several thousand. It therefore also helps to mitigate DDoS attacks (although the biggest of services e.g. Facebook would likely have their own systems that would better handle this).

str4d

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