[tor-dev] Draft of proposal "Direct Onion Services: Fast-but-not-hidden services"

[Tom Ritter]

On 10 April 2015 at 07:58, George Kadianakis <desnacked at riseup.net> wrote:
> One negative aspect of the above suggestions, is that if hidden
> services only listen for connections, then they lose their
> NAT-punching abilities. But I bet that this is not a problem for some
> use cases that would appreciate the corresponding performance boost.
> Theoretically, the above optimizations could also be optional.
>
> We should think more.

I wobble back and forth on NAT-Punching for DOS (Direct Onion Services ;) ).

On one hand it's awesome to not have to worry about NAT. On the other,
if you're doing to run a DOS, presumably you are capable enough to
either traverse it or not have to worry about it?

Ultimately, I think I fall onto the side of wanting to keep the
NAT-punching present. As we support more use cases for OSes (Onion
Services ;) ) we will probably want to support people behind NATs but
willing to compromise anonymity for performance. For example, I could
easily envision someone being the DOS in an audio or video chat and
being behind a NAT. The DOS end helps boost the performance, the
client gets anonymity, everyone gets end-to-end protection.

The difference between a DOS connecting to an IP and a DOS _being_ the
IP seems small, as it's only used for connection setup.  Obviously
being the IP would be faster... perhaps the DOS could choose IPs that
(it believes) it has a low latency connection to? (If that would be
feasible with the information the daemon has available to it?)

On 9 April 2015 at 22:33, Jacob H. Haven <jacob at jhaven.me> wrote:
> Removing rendezvous nodes is a bigger change to the protocol, but would be
> very useful. Why not enable the client to just directly establish circuit(s)
> directly to the onion service? As David pointed out, this would probably be
> implemented most cleanly with a tag in the HSDir descriptor (this would
> conveniently identify the service as non-hidden, whether that's a good or
> bad thing...)

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

If the RP is removed and the client makes a "direct connection" to the
DOS, the client is using a two-hop circuit, not a three-hop, right?
If it's a three-hop circuit, it's no different (performance-wise) than
using a RP, right?



Another thought. If the DOS makes a direct connection to the HSDir for
descriptor publishing the HSDir will be able to (passively) enumerate
which HSes are DOSes, right?  This seems like it would be something we
would want to prevent. (Well, at least require the HSDir to go perform
an active fingerprint to learn this information.) The use of three-hop
circuits to publish this information is not strenuous either.

-tom