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

[George Kadianakis]

Tim Wilson-Brown - teor <teor2345 at gmail.com> writes:

> [ text/plain ]
>
>> On 24 Mar 2016, at 22:55, George Kadianakis <desnacked at riseup.net> wrote:
>> 
>> - How exactly should directory guards work? Should the guard lists be
>>  initialized only with directory guards? Or should we just initialize our
>>  guard lists from the set of all guards, and just skip non-V2Dir guards
>>  whenever we need to make a directory circuit? FWIW, there are currently 2076
>>  guards, out of which 1659 support V2Dir (i.e. they are directory guards).
>
> The number of directory guards will increase when 0.2.8-stable is released and relays and clients upgrade.
> In 0.2.8, relays accept tunnelled directory connections even if they do not have an open DirPort.
>

Indeed, soon enough all guards will be directory guards.

>> - How should the algorithm work wrt ReachableAddresses? I wonder how the
>>  current algorithm work wrt ReachableAddresses and if it's behavior is good.
>
> In 0.2.7 and earlier, tor checks directory guards against ReachableAddresses and remove those that aren't reachable, but it doesn't check non-directory guards in choose_good_entry_server.
>
> In 0.2.8 this issue is fixed, and tor checks both directory and non-directory guards against ReachableAddresses. For both types of guards, tor also checks if the guard's address is preferred by ClientPreferIPv6{OR,Dir}Port, and choose guards with preferred IP address versions before choosing guards without preferred address versions. Since all relays have IPv4 addresses, when IPv6 addresses are preferred, tor will choose guards with IPv6 OR and Dir addresses.
>
> I am worried that the UTOPIC / DYSTOPIC distinction is too simplistic to capture the existing guard selection behaviour in 0.2.7 with ReachableAddresses. This becomes even more complex once IPv6 preferences are taken into account during guard selection in 0.2.8.
>

Hm. I'm not sure how to do this properly right now. I feel that the current Tor
behavior is very very complex, and it's hard to incorporate all that logic in a
proposal that tries to be standalone and easy to analyze.

We need to document the current behavior of guards wrt ReachableAddresses and
IPv6, and see which parts we want to keep as is and which ones we want to change.

> General proposal feedback:
>
> The proposal would be much clearer if DYSTOPIC_GUARDS was defined precisely.
> Are they guards that have a DirPort 80 and ORPort 443?
> Or can these ports be swapped? (DirPort 443 and ORPort 80?)
>

Indeed, pinning down the concept of DYSTOPIC_GUARDS in the proposal seems like
a good idea.

I think the current idea is that they are guards that have their ORPort on
ports 80 or 443.  We don't care about the DirPort I think, since directory
requests happen over the ORPort with BEGIN_DIR. Is that right?

I think Reinaldo et al. were also thinking of incorporating the
ReachableAddresses logic in there, so that DYSTOPIC_GUARDS changes based on the
reachability settings of the client. I'm not sure exactly how that would work,
especially when the user can change ReachableAddresses at any moment. I think
we should go for the simplest thing possible here, and improve our heuristics
in the future based on testing.

> What about ReachableAddresses?
> What about IPv6 ORPorts and DirPorts?
>
> Automatically determining if a client has IPv6 connectivity may be beyond the scope of this proposal, and might require a separate proposal. But we should be careful not to bake in a design that we'll want to change in a release or two when we auto-configure IPv6.
>
> Also, whatever we code will need to preserve the existing behaviour of the options ReachableAddresses, ClientUseIPv4, CientUseIPv6, ClientPreferIPv6ORPort, and ClientPreferIPv6DirPort.
>

Indeed. We need to document how these settings interact with guard selection
currently, and see what needs to be done.

> Feedback on specific sections:
>
>>  Under dystopic conditions (when a firewall is in place that blocks
>>  all ports except for potentially port 80 and 443), this algorithm
>>  will try to connect to 2% of all guards before switching modes to try
>>  dystopic guards. Currently, that means trying to connect to circa 40
>>  guards before getting a successful connection. If we assume a
>>  connection try will take maximum 10 seconds, that means it will take
>>  up to 6 minutes to get a working connection.
>
> This seems far too long for most users. Usability studies have demonstrated that users give up after approximately 30 seconds.
>
> Can we design an algorithm that will automatically choose a dystopic guard and bootstrap within 30 seconds?
> What are the security tradeoffs if we do?

OK, let's assume that a connection failed timeout might take up to 10 seconds.

If Alice is behind a FascistFirewall and we want her to bootstrap within 30
seconds, this means that she always needs to have an 80/443 guard in her top
three choices. This means, that we would heavily prioritize 80/443 guards over
the rest, and an adversary who sets up 80/443 guards will attract more clients.

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.

Currently, I'm hoping that we will understand the value of this heuristic
better when we implement it, and test it on real networks...

Any suggestions?