[tor-dev] Hidden Service Scaling

[Matthew Finkel]

Hi Christopher,

It's great that you started thinking about a design (and the potential
obstacles). I will try not to reiterate what Nick already said, though.

On Tue, Oct 08, 2013 at 06:52:39AM +0100, Christopher Baines wrote:
> I have been looking at doing some work on Tor as part of my degree, and
> more specifically, looking at Hidden Services. One of the issues where I
> believe I might be able to make some progress, is the Hidden Service
> Scaling issue as described here [1].
> 
> So, before I start trying to implement a prototype, I thought I would
> set out my ideas here to check they are reasonable (I have also been
> discussing this a bit on #tor-dev). The goal of this is two fold,  to
> reduce the probability of failure of a hidden service and to increase
> hidden service scalability.
> 

These are excellent goals. It would be even better if you made a
stronger statement about hidden service failure. Something closer to
"increase hidden service availablity", but I won't bikeshed on the
wording.

> I think what I am planning distils down to two main changes. Firstly,
> when a OP initialises a hidden service, currently if you start a hidden
> service using an existing keypair and address, the new OP's introduction
> points replace the existing introduction points [2]. This does provide
> some redundancy (if slow), but no load balancing.

So an interesting thing to note about this hack is that it does provide
*some* load balancing. Not much, but some. The reason for this is
because Tor clients cache hidden service descriptors so that they don't
need to refetch every time they want to connect to it.
 
> My current plan is to change this such that if the OP has an existing
> public/private keypair and address, it would attempt to lookup the
> existing introduction points (probably over a Tor circuit). If found, it
> then establishes introduction circuits to those Tor servers.
> 
> Then comes the second problem, following the above, the introduction
> point would then disconnect from any other connected OP using the same
> public key (unsure why as a reason is not given in the rend-spec). This
> would need to change such that an introduction point can talk to more
> than one instance of the hidden service.
> 

It's important to think about the current design based on the assumption
that a hidden service is a single node. Any modifications to this
assumption will change the behavior of the various components.

> These two changes combined should help with the two goals. Reliability
> is improved by having multiple OP's providing the service, and having
> all of these accessible from the introduction points. Scalability is
> also improved, as you are not limited to one OP (as described above,
> currently you can also have +1 but only one will receive most of the
> traffic, and fail over is slow).
 
Do you see any disadvantages to this design?

> I am aware that there are several undefined parts of the above
> description, e.g. how does a introduction point choose what circuit to
> use? but at the moment I am more interested in the wider picture. It
> would be good to get some feedback on this.
> 
> 1: https://blog.torproject.org/blog/hidden-services-need-some-love
> 2:
> http://tor.stackexchange.com/questions/13/can-a-hidden-service-be-hosted-by-multiple-instances-of-tor/24#24

This is a good start! Some important criteria you might also think
about include how much you trust each component/node and which nodes do
you want to be responsible for deciding where connections are routed.
Also seriously think about how something like a botnet that uses hidden
services might impact the reliability of your design (crazy idea, I
know).

I'll defer to Nick's email for other thought provoking ideas.

- Matt