On 10 April 2015 at 07:58, George Kadianakis desnacked@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@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