"Jacob H. Haven" jacob@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!