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

[Tim Wilson-Brown - teor]

> 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.

> - 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.

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?)

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.

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?

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160324/3d72ab93/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160324/3d72ab93/attachment.sig>