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

On 24 Mar 2016, at 22:55, George Kadianakis <desnacked@xxxxxxxxxx> 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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail