Re: [tor-dev] Hidden Service Scaling

[George Kadianakis <desnacked@xxxxxxxxxx>]

Christopher Baines <cbaines8@xxxxxxxxx> writes:

> On 08/10/13 06:52, 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.
>
> Previous threads on this subject:
>  https://lists.torproject.org/pipermail/tor-dev/2013-October/005556.html
>  https://lists.torproject.org/pipermail/tor-dev/2013-October/005674.html
>
> I have now implemented a prototype, for one possible design of how to
> allow distribution in hidden services. While developing this, I also
> made some modifications to chutney to allow for the tests I wanted to write.
>

Great! Here are a few small comments from quickly reading your post.

> In short, I modified tor such that:
>  - The services public key is used in the connection to introduction
> points (a return to the state as of the v0 descriptor)

Ah, this means that now IPs know which HSes they are serving (even if
they don't have the HS descriptor). Why was this change necessary?

>  - multiple connections for one service to an introduction point is
> allowed (previously, existing were closed)
>  - tor will check for a descriptor when it needs to establish all of its
> introduction points, and connect to the ones in the descriptor (if it is
> available)
>  - Use a approach similar to the selection of the HSDir's for the
> selection of new introduction points (instead of a random selection)

As you note below, this suffers from the same issue that HSDirs suffer
from. Why was this necessary? Is it to avoid race conditions?

Based on the previous point, I thought that the second node of an HS
would be able to get the list of IPs by reading the descriptor of the
first node.

>  - Attempt to reconnect to an introduction point, if the connection is lost
>
> With chutney, I added support for interacting with the nodes through
> Stem, I also moved the control over starting the nodes to the test, as
> this allows for more complex behaviour.
>
> Currently the one major issue is that using an approach similar to the
> HSDir selection means that introduction points suffer from the same
> issue as HSDir's currently [1]. I believe any satisfactory solution to
> the HSDir issue would resolve this problem also.
>
> One other thing of note, tor currently allows building circuits to
> introduction points, through existing introduction points, and selecting
> introduction points on circuits used to connect to other introduction
> points. These two issues mean that a failure in one introduction point,
> can currently cause tor to change two introduction points. (I am not
> saying this needs changing, but you could adjust the circuit creation,
> to prevent some extra work later if a failure occurs).
>
> Any comments regarding the above would be welcome.
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev