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
|