Re: [tor-dev] Hidden Service Scaling

[Matthew Finkel <matthew.finkel@xxxxxxxxx>]

On Wed, Oct 09, 2013 at 09:58:07AM +0100, Christopher Baines wrote:
> On 09/10/13 01:16, Matthew Finkel wrote:

> >> 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.
> 
> The only interactions I currently believe can be affected are the Hidden
> Service instance <-> Introduction point(s) and Hidden Service instance
> <-> directory server. I need to go and read more about the latter, as I
> don't have all the information yet.
 
Also, to be fair, one of the devs has already started working on
upgrading various components of hidden services [3][4]. You may also
want to read through these so you have an idea of what are some future
plans.

Also, keep in mind that that the current design may not work well for
this (scaling) use case. Perhaps also thinking about modifications to the
current design that are backwards compatible will help.

> >> 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?
> 
> So, care needs to be taken around the interaction between the hidden
> service instances, and the introduction points. If each instance just
> makes one circuit, then this reveals the number of instances.

Does it?

> There is also uncertainty around the replacement of failing introduction
> points. New ones have to be chosen, but as the service instances do not
> directly communicate, there could be some interesting behaviour unless
> this is done carefully.

Is there a reason they shouldn't communicate with each other?

> I am also unsure how the lack of direct communication between the hidden
> service instances could affect the usability of this. I think what would
> be good to do is take some large, open source, distributed web
> applications and look at how/how not to set them up using various
> possible implementations of distributed hidden services.
>
> >> 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 assume the characteristics of this are: 1 or more hidden service
> instances, connected to by very large numbers of clients, sending and
> reviving small amounts of information?

Perhaps, but just think about the load an intro point can handle and
sustain. If Introduction Points are where load balacing takes place,
then does this affect the difficulty of attacking a hidden service? (for
some undefined definition of 'attack'.)

[3]
https://lists.torproject.org/pipermail/tor-dev/2013-October/005534.html
[4]
https://lists.torproject.org/pipermail/tor-dev/2013-October/005536.html
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev