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

[George Kadianakis <desnacked@xxxxxxxxxx>]

Tim Wilson-Brown - teor <teor2345@xxxxxxxxx> writes:

> [ text/plain ]
>
>> On 27 Mar 2016, at 05:42, s7r <s7r@xxxxxxxxxx> wrote:
>> 
>> Hello,
>> 
>> teor, asn, see comments inline.
>> 
>> On 3/24/2016 5:00 PM, Tim Wilson-Brown - teor wrote:
>> [snip]
>> 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.

Hmm, seems like there are bits of reachability information all around the
bootstrapping process :) I wonder how we could actually use them...

Here are two brainstormy/sucky ideas for heuristics:

a) If during bootstrapping we only connected to 80/443 bridges, then enable the
   dystopic mode (e.g. only use 80/443 bridges or sth).

   A more conservative approach here, is to add points to the heuristic for
   each 80/443 bridge we connect to, and after enough points have been
   accumulated we assume that the network is dystopic and enable the dystopic
   mode.

b) When choosing guards we strictly prefer ports we managed to connect to
   during bootstrapping.

Both of those approaches are not bulletproof and can lead to false positives
(i.e. we go into dystopic mode, even when the network is fine) which kind of
suck because of security concerns (increased chances of using a dystopic guard)
and for load balancing concerns.

They can also take obviously wrong decisions when a person moves around with
their laptop a lot. Heuristic decisions from one network will carry over to the
next network if Tor has not restarted.

I think more research is needed to find out how to use this information well.

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

I wonder what would happen there if FascistFirewall gets toggled on and off.

If our guardlist was sampled when FascistFirewall was on, shouldn't we sample
from the beginning if FascistFirewall goes off? That's terrible though since we
lose all that guard state...

More thinking is required here as well.
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev