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.
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.
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.
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).
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
-------------- 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/20131008/1acbbc52/attachment.sig>