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

Thu Mar 31 00:23:44 UTC 2016

> On 27 Mar 2016, at 05:42, s7r <s7r at sky-ip.org> wrote:
> 
> Hello,
> 
> teor, asn, see comments inline.
> 
> On 3/24/2016 5:00 PM, Tim Wilson-Brown - teor wrote:
> [snip]
>>>> 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.
>> 
>> Almost all guards will be directory guards. AccountingMax can disable
>> tunnelled directory fetches, as can DirCache 0.
> 
> I guess the guards that won't be accepting tunneled BEGIN_DIR
> connections because of AccountingMax or DirCache 0 will also advertise
> this in their descriptors, so these relays will not get a `V2Dir` flag.
> Can you confirm if this is actually true? I assume the code has to do
> this, otherwise how can a client know if he can initiate a tunneled
> BEGIN_DIR connection with a relay or not.

Yes, it adds a line to its descriptor saying it supports tunnelled connections.

>> [snip]
>> Client Bootstrap
>> 
>> The proposal ignores client bootstrap.
>> 
>> There are a limited number of hard-coded authorities and fallback
>> directories available during client bootstrap.
>> The client doesn't select guards until it has bootstrapped from one of
>> the 9 authorities or 20-200 fallback directories.
>> 
> 
> I think this step is before prop#259 does its magic, since prop#259
> first needs a consensus before it can work. Let's call this initial
> (genesis) bootstrap Step 0 - only after a client has bootstrapped
> (either from an authority or from a fallback directory) he will initiate
> prop#259 to pick a guard.

So do we throw away the information about reachable ports we gained during bootstrap?
It's simpler, but slower. Perhaps too slow for a good user experience.

>> Bootstrap / Launch Time
>> 
>> The proposal calculates bootstrap and launch time incorrectly.
>> 
>> The proposal assumes that Tor attempts to connect to each guard, waits
>> for failure before trying another. But this isn't how Tor actually works
>> - it sometimes tries multiple connections simultaneously. So summing the
>> times for individual connection attempts to each guard doesn't provide
>> an accurate picture of the actual connection time.
>> 
>> When bootstrapping in 0.2.7 and earlier, tor will try an authority, wait
>> up to 10 seconds for it to fail, then try another.
>> Then there's a 60 second wait before the third authority, but at that
>> point the user has likely lost interest.
>> 
>> In 0.2.8, tor connects to authorities and fallbacks concurrently. It
>> will try 3 fallbacks and 1 authority in the first 10 seconds, and
>> download from whichever one connects first So 0.2.8 is far more likely
>> to connect within a few seconds.
>> 
>> In all current versions, tor then downloads the consensus (~1.5MB, could
>> take 10 seconds or more), and chooses directory guards.
>> Then it simultaneously connects to 3 directory guards to download
>> certificates and descriptors.
>> The time it takes tor to work out if a connection to a directory guard
>> has succeeded happens simultaneously with other directory guard timeouts.
>> 
> 
> Hmm. This requires some thinking. So Tor connects to the directory
> guards immediately after it gets a consensus, to get the certificates
> and descriptors. Plausible. I assume it does this via HTTP fetch on the
> DirPort, since it has _no_ certificates and descriptors for routers.
> Doesn't Tor need these certificates and descriptors to initiate tunneled
> BEGIN_DIR requests with certain relays?

It has identity key fingerprints hard-coded.
I'd have to look into the tor code to see if client bootstrap connections are HTTP or HTTPS - or run a tcpdump session.

> How will this work once DirPort is deprecated entirely? Or removing
> DirPort from relays is not part of the plan?

Deprecating the DirPort is not part of any plan I'm aware of.
Relays still use DirPorts, as do some obscure client configurations.

>> 
>> Other Considerations
>> 
>> We're considering increasing the 10 second stream attach timeout to
>> support users on slow and unreliable network connections (#16844). We
>> should think about the impact of that on this proposal - I'd hate to
>> double the time it takes tor to exhaust its UTOPIC guardlist.
>> 
> This is correct.
> 
> Also, FascistFirewall torrc option: prop#259 sounds like it will take
> care of users behind FascistFirewalls by default, should we eliminate it
> entirely for simplicity? Or should we make it that FascistFirewall 1
> will tell prop#259 to populate SAMPLED_GUARDS list only with dystopic
> guards OR use only a SAMPLED_DYSTOPIC_GUARDS list if we choose to keep
> the two lists disjoint?

It depends how quickly we can auto-discover whether we're firewalled or not.
If it's going to take more than 30 seconds (typical user attention span), I'd use FascistFirewall as a hint to populate the UTOPIC lists.
This will happen automatically if we only populate the UTOPIC list with reachable addresses.
(Tor handles FascistFirewall, ReachableAddresses, and ClientUseIPv4/6 using the same set of functions.)

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/20160331/862395ee/attachment-0001.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/20160331/862395ee/attachment-0001.sig>