On 03/05/14 11:21, George Kadianakis wrote: > Christopher Baines <cbaines8@xxxxxxxxx> 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".
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev