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.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev