[tor-dev] Proposal: Load-balancing hidden services by splitting introduction from rendezvous

[Roger Dingledine]

On Wed, Sep 30, 2015 at 05:27:28PM +0200, Tom van der Woerdt wrote:
> I'd like your thoughts and comments on this proposal.
> 
> Tom

Hi Tom!

I am slowly turning back into a Tor developer. I like this proposal.

Here are some thoughts:

- The INTRODUCE event should happen independent of the value of
HiddenServiceAutomaticRendezvous. From reading the proposal I thought
you meant this, but then looking at your suggested patches it looks
like you only deliver the event if automaticrendezvous is disabled. The
controller should have the option to just observe if it wants. (In the
implementation, you might want to check if there are any controllers
that care about the event, before constructing the rendezvousblob.)

- We do indeed need a clearer name for INTRODUCE -- but my reason is
different from the others presented. I want it clearer because in
the future the *client* side could have an event when it sends its
introduction cell, and that one will start out being called INTRODUCE too.
So maybe HS_SERVER_INTRODUCE or something. We need to look into the
future when we have events for all the various rendezvous steps, and
pick a naming scheme now that won't be too terrible then.

- I also have a weak preference towards having the first Tor
do the decryption -- I think George's point about the replaycache is
a good one.

- I agree with Nick that we need a specification for what version "1"
of the rendezvousblob format will look like. A specification that says
it won't specify the core piece of the design is not cool. :)

>  If no controllers are present, the introduction cell
> should be dropped

So if the controller dies for some reason, the onion service will
now quietly ignore all introduction requests. That's a bit sad. But
I think it's still the best design -- and controllers that setconf
AutomaticRendezvous to 0 can use the TAKEOWNERSHIP command to make sure
Tor exits rather than remains silently useless.

> Let's take an example where a client (Alice) tries to contact Bob's
> hidden service. To do this, Bob follows the normal hidden service
> specification, except he sets up ten servers to do this. One of these
> publishes the descriptor, the others have this desabled.

Do we also want a way to tell an onion service to not bother
establishing or maintaining intro points? Maybe via letting
HiddenServiceNumIntroductionPoints be 0? (I recommend not letting this
idea block any of the rest of the implementation or deployment. :)

--Roger