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

[George Kadianakis]

"Jacob H. Haven" <jacob at jhaven.me> writes:

> Optimizations like these are really what help make onion services
> performant. With the right architecture I think they can be much faster and
> more secure than regular non-onion (i.e. exit-node routed) sites.
> A couple questions/comments:
>
>    - What is the exact need for introduction points here at all? The onion
>    service can just act as it's own introduction point(s), advertising its IPs
>    to the HSDirs. They're possibly useful for load-balancing, but that can be
>    achieved easier without these additional, third-party relays.
>    - 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...)
>

i think both of these ideas are technically possible, and they would
indeed improve performance for this use case. Both of them would
require some non-trivial engineering work to alter the HS code to be
able to do all this stuff, but it might be worth it.

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.

Thanks for the feedback!