Re: [tor-dev] Proposal 259: New Guard Selection Behaviour

[George Kadianakis <desnacked@xxxxxxxxxx>]

s7r <s7r@xxxxxxxxxx> writes:

> [ text/plain ]
> Hello,
>
> teor, asn, see comments inline.
>
> On 3/24/2016 5:00 PM, Tim Wilson-Brown - teor wrote:
> [snip]
>>>>
>>>> [snip]
>> This isn't how Tor works - it tries multiple guards simultaneously.
>> (See below for details.)
>> Can we rework this calculation to take that into account?
>> 
>>> I think the current proposal tries to balance this, by enabling this
>>> heuristic
>>> only after Alice exhausts her utopic guardlist. Also, keep in mind
>>> that the
>>> utopic guardlist might contain 80/443 guards as well. So if Alice is
>>> lucky, she
>>> got an 80/443 guard in her utopic guard list, and she will still bootstrap
>>> before the dystopic heuristic triggers.
>>>
>>> There are various ways to make this heuristic more "intelligent", but
>>> I would
>>> like to maintain simplicity in our design (both simple to understand
>>> and to
>>> implement). For example, we could imagine that we always put some
>>> 80/443 guards
>>> as our primary guards, or in the utopic guardlist. Or, that we reduce
>>> the 2%
>>> requirement so that we go trigger the dystopic heuristic faster.
>> 
>
> I agree that the maximum total time at client side to get a working
> connection is probably too much. However, I am thinking asn's arguments
> about _ensuring_ we keep at least n dystopic guards in our
> PRIMARY_GUARDS list:
> a) overloading 80/443 (dystopic guards);
> b) creating incentives for attackers to run 80/443 (dystopic guards)
> that will give them unfair probabilities to be picked by clients;
>
> are very important and could be worth the effort to make this tradeoff
> and increase the maximum possible time to get a working connection at
> client side.
>
> As I understand, the utopic guard list _can_ also contain dystopic
> guards, so a client behind a FascistFirewall might be lucky and don't
> have to wait until utopic guard list is exhausted entirely. This is
> better, but I still think it would be simpler if instead of 2 guard lists:
> - SAMPLED_UTOPIC_GUARDS
> - SAMPLED_DYSTOPIC_GUARDS
>
> We create a single SAMPLED_GUARDS list, but we make the selection by
> taking into account the ratio of utopic and dystopic guards based on
> their weights from the last consensus. I have suggested a simple example
> for this few months ago in this post:
>
> https://lists.torproject.org/pipermail/tor-dev/2015-November/009871.html
>
> If we compute the guard list like this, load balancing shouldn't be
> affected in any way (we use the weights to build the list, not the
> number of relays). I saw the algorithm has been improved so much and
> covers so many aspects we didn't consider initially, but I still don't
> understand why we need two separate lists of utopic guards and dystopic
> guards when we can create a single list.
>
> This will also allow us to safely decrease a little bit the total number
> of guards we are willing to try, being sure that clients behind
> FascistFirewalls get a chance while also taking into account teor's
> concern not to make this list too big.
>

Hmm, this seems like something worth considering. 

IIUC you are basically suggesting using a single guardlist instead of having
two. And then also making sure that a representative amount of dystopic bridges
are present in that guardlist. So if the set of guards in the latest consensus
is 20% dystopic bridges (in bandwidth), we should choose 20% of our guardlist
to be dystopic guards.

I can see how this simplifies the guard selection logic, with the cost of
slightly complicating the guard sampling logic. It seems like a good trade in
this case.

However, this whole suggestion assumes that a good percentage of the total
guard bandwidth is actually dystopic (your mail assumes 28% which is a pretty
good number). What's the actual bandwidth % of dystopic bridges in the current
network? If it's 20% it's a good number for our purposes, but if it's like 1%
then that's bad since we are only going to end up adding 1 or 2 dystopic
bridges only making our heuristic much more flaky. Also, in the end the quality
of our heuristic will depend on this % which is suboptimal.

FWIW in my definition of dystopic bridge above I've been assuming it's bridges
with ORPort on 80 or 443.

We should look more into this. Reinaldo, Ola, any comments? Is this simulatable?

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev