[tor-dev] Hidden Service Scaling

[Christopher Baines]

On 03/05/14 11:21, George Kadianakis wrote:
> Christopher Baines <cbaines8 at gmail.com> writes:
> 
>> On 08/10/13 06:52, Christopher Baines wrote:
>> 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?

If the "service key"'s (randomly generated keys per introduction point)
are used, then this would complicate/cause problems with the multiple
instances connecting to one introduction point. Only one key would be
listed in the descriptor, which would only allow one instance to get the
traffic.

Using the same key is good. Using the services key, is not great. One
possible improvement might be to generate a key for an introduction
point based off the identity of the introduction point, plus some other
stuff to make it secure.

>>  - 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?]

The existing random selection algorithm was not suitable as each
instance would pick differently. If you used a pseudorandom number
generator, which produced a consistent output between instances, then
this would make the results similar, but the results could then still be
thrown off by each instance considering slightly different candidates
due to different knowledge about the network state.

The approach used for HSDir selection seemed a promising, as if each
node after the start point is considered (regardless of local
knowledge), then each instance should converge on the first suitable node.

So, not race conditions, but to account for local network state information.

> 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.

Yes, and no. It depends on its internal state.

There are two scenarios for a instance:
 - I have had no introduction points, and have not just removed some
 - I have 0 to n introduction points, and have recently removed some

In the first scenario, a descriptor lookup is used, falling back to
selecting introduction points if that fails.

In the second scenario, you pick using the HSDir like approach.

You could attempt to use the descriptor to coordinate the selection of
new introduction points, but you then have the problem of "whose job is
it to choose".

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