[tor-dev] Proposal: Merging Hidden Service Directories and Introduction Points

[John Brooks]

teor <teor2345 at gmail.com> wrote:

> 
>> On 13 Jul 2015, at 07:48 , John Brooks <john.brooks at dereferenced.net>
>> wrote:
> 
>> 4.2. Restriction on the number of intro points and impact on load
>> balancing
>> 
>>   One drawback of this proposal is that the number of introduction points
>>   of a
>>   hidden service is now a constant global parameter. Hence, a hidden
>>   service
>>   can no longer adjust how many introduction points it uses, or select
>>   the
>>   nodes that will serve as its introduction points.
> 
> If we decide we want to allow popular hidden services to have more than 6
> introduction points, we could use some of the 4 extra bits in the address
> to encode an introduction point count multiplier.

Interesting approach. This value would be difficult to change on an existing
service, because it would have to hand out a new subtly-different URL to all
clients. We had also briefly discussed using the extra 4 bits as a checksum
on the address.

> I can see advantages in popular, high-availability, or politically
> unpopular hidden services having more introduction points. It would make
> it harder to overload all the introduction points, particularly once the
> server can't change introduction points when they go down.

I _think_ that 6 introduction points can handle a lot of traffic, and I
think it’s mostly sufficient for reliability and abuse-resistance.
Personally, I’d like to see statistics showing that introduction points are
a bottleneck before we design systems to increase the number of them. I
suspect that guards fall down long before introduction points do. There are
tradeoffs to using more, both in terms of network load and privacy (e.g.
exposing popularity to relays).

> Perhaps we only need two introduction point counts: 6 and 6n, where n is
> initially chosen based on the most popular hidden services, and is a
> consensus parameter, so can be updated if needed.

The introduction point count should be a consensus parameter; 224 was going
to do this for HSDirs already.

> 
> Tim
> 
> Tim Wilson-Brown (teor)

- John
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150713/b80664ca/attachment.sig>