[tor-dev] [Draft Proposal] Scalable Hidden Services

[Christopher Baines]

On 28/10/13 13:19, Matthew Finkel wrote:
> This is a proposal I wrote to implement scalable hidden services. It's
> by no means finished (there are some slight inconsistencies which I will
> be correcting later today or tomorrow) but I want to make it public in
> the meantime. I'm also working on some additional security measures that
> can be used, but those haven't been written yet.

Great, I will try to link this in to the earlier thread for some continuity.

It seems to me that this is a description of "Alternative 3" in Nick's
email. Multiple instances, with multiple sets of introduction points,
somehow combined in to one service descriptor? I haven't managed to
fully comprehend your proposal yet, but I though I would try and
continue the earlier discussion.

So, going back to the goals, this "alternative" can have master nodes,
but, can have you can also just have this "captain" role dynamically
self assigned. Why did you include an alternative here, do you see these
being used differently? It seems like the initial mode does not fulfil
goal 2 or 3?

One of the differences between the alternatives that keeps coming up, is
who (if anyone) can determine the number of nodes. Alternative 3 can
keep this secret to the service operator by publishing a combined
descriptor. I also discussed in the earlier thread how you could do this
in the "Alternative 4: Single hidden service descriptor, multiple
service instances per intro point." design, by having the instances
connect to each introduction point 1, or more times, and possibly only
connecting to a subset of the introduction points (possibly didn't
consider this in the earlier thread).

Another recurring point for comparison, is can anyone determine if a
particular service instance is down. Alternative 4 can get around this
by hiding the instances behind the introduction points, and to keep the
information from the introduction points, each instance (as described
above) can keep multiple connections open, occasionally dropping some to
keep the introduction point guessing. I think this would work, providing
that the introduction point cannot work out what connections correspond
with what instances. If each instance has a disjoint set of introduction
points, of which some subset (possibly total) is listed in the
descriptor, it would be possible to work out both if a instance goes
down, and what introduction points correspond to that instance, just by
repeatedly trying to connect through all the introduction points? If you
start failing to connect for a particular subset of the introduction
points, this could suggest a instance failure. Correlating this with
power or network outages could give away the location of that instance?

Also, compared to the setup of other alternatives, this seems more
complex for the hidden service operator. Both in terms of understanding
what they are doing, and debugging failures? I think it would be good to
partition the goals (as there are quite a lot (not inherently bad)). In
particular, one subset of goals would be as follows:

Operator (the person, or people controlling the service) Usability
 - Simple Initial Setup
 - Simple Addition of new Instances
 - Simple Removal of Instances
 - Graceful behaviour regarding instance failure (with respect to the
operator)
 - Well defined failure modes
   - If something doesn’t work, it should be possible for the operator
to work out what, and how to resolve it.

Now, obviously, these are minor compared to the more technical goals,
but I think they are worth considering, as we have a few technically
workable proposals on the table.

As for what I am doing on this currently, I have been reading lots of
the related, and not so related papers. I hope to begin doing some more
Hidden Service related Chutney stuff this or next week, such that I have
something to test with when I start implementing something (note: what I
implement, might not be adopted/adoptable by the project, but I am doing
it anyway as part of my degree). I am available on #tor-dev as cbaines
for any and all discussion.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 966 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20131028/750a20d4/attachment.sig>