[tor-dev] On picking Introduction Points in Next Generation Hidden Services

[George Kadianakis]

Matthew Finkel <matthew.finkel at gmail.com> writes:

> On Tue, Aug 12, 2014 at 02:05:49PM +0300, George Kadianakis wrote:
>> One missing piece of rend-spec-ng.txt [0] is a section on how HSes
>> should pick their Introduction Points (IPs). There are three main
>> questions here:
>> - How many IPs should an HS have?
>> - Which relays can be IPs?
>> - What's the lifetime of an IP?
>> 
>
> --Snip-- 
>
>> ==How many IPs should an HS have?==
>> 
>>   Now let's investigate how many IPs an HS should have.
>>   
>>   The current situation is that HSes attempt to estimate their own
>>   popularity [2], and then they launch a number of IPs between 3 and 10
>>   depending on how popular they think they are. FWIW, we don't really
>>   understand whether the formula works properly [3].
>>   
>>   There are a few options for the future here:
>>   
>>   a) Fix the formula and keep number of IPs dynamic based on the
>>      popularity of the HS.
>>   
>>      This is not a bad idea. However, we should make sure that from the
>>      number of IPs you can't easily derive the number of clients of the
>>      HS. Also we should make sure that the formula works properly.
>>   
>>   b) Have a static amount of IPs per HS. For example '5' of them.
>> 
>>      I'm not sure what kind of calculations we need to do to find the
>>      right constant here (same for the (a) option).
>>   
>>   c) Have a static amount of IPs per HS, but also allow this to be
>>      configurable by the HS operator.
>>   
>>      The idea here is that popular HSes can pump up the number of IPs
>>      to make the service more reachable. It's worth noting that HSes
>>      who do so will stand out as manually configured; not sure if any
>>      other partition attacks can happen here. Also, there is also the
>>      danger of all HS operators thinking they are special and pumping
>>      the number of IPs to 42.
>
> There's also the choice "ac) allow the HS operator to set a fixed
> number or allow them to set an upper limit of IPs and let Tor
> dynamically allocate them depending on popularity".
> Many choices :)
>
> Something else we can consider is publishing multiple versions of the
> HS descriptor, each containing a subset of IPs. An adversary will need
> to collect them all to see the full picture and know how popular the
> HS thinks it is. On the other hand, it is likely better for a HS
> operator to simply add more HS addresses when their popularity
> increases. This decreases the usability of the HS, though, and relies
> on users understanding why they should uniformly distribute their
> connections over the various connections.
>
>>   
>>   Generally, we want to have a healthy amount of IPs (so that they
>>   don't get DoSed, and that requests get load balanced nicely), but
>>   also not too many because every HS having many IP circuits will put
>>   a load to the network (especially with services like Torchat where
>>   each client is an HS), and also because we want to avoid too many
>>   nodes becoming our IPs over time (more on this below).
>> 
>
> We should consider profiling the affect of an IP circuit on the network.
> Granted, we shouldn't waste any unnecessary bandwidth on useless
> connections, but I wonder how much load is really added.
>

Right.

FWIW, the only rationale for
`#define NUM_INTRO_POINTS_MAX 10`
that I know about, is Robert's post:
https://trac.torproject.org/projects/tor/ticket/4862#comment:13 .

Maybe we need to estimate the number of HSes we want the Tor network
to be able to support, and then calculate how many circuits the Tor
network can handle, and then...