Re: [tor-bugs] #5462 [Tor]: Clients should alert the user if many guards are unreachable

["Tor Bug Tracker & Wiki" <torproject-admin@xxxxxxxxxxxxxx>]

#5462: Clients should alert the user if many guards are unreachable
------------------------+---------------------------------------------------
 Reporter:  mikeperry   |          Owner:                    
     Type:  defect      |         Status:  new               
 Priority:  major       |      Milestone:  Tor: 0.2.4.x-final
Component:  Tor         |        Version:                    
 Keywords:  tor-client  |         Parent:  #5456             
   Points:              |   Actualpoints:                    
------------------------+---------------------------------------------------

Comment(by mikeperry):

 Replying to [comment:3 nickm]:
 > We want to detect when we can get through to only a subset of possible
 guards that should be up.  We want to distinguish this from the case where
 our network has come up.  So, let's do it like this: let's keep track of
 the status of our last N connection attempts to servers listed as Running.
 If some sufficient fraction of those is "failed", and the most recent
 attempt is "succeeded" , we might be just coming up: we can reattempt the
 connections to guards that had failed.  If they start succeeding, we were
 only down; that's fine.  If they still fail but the successful connections
 are "working", then we should warn.

 Hrmm. I'm not sure I like the "last N connections" thing.. It seems like a
 statistical check, and seems slightly more complicated than it needs to
 be?

 What if we made this a periodic check of all entry guards whenever we
 detect network activity but the last check was some time ago? Ie: upon
 successful consensus download we could attempt to connect to every still-
 running guard in our guard list. That solves the "Is the network live?"
 question implicitly through valid consensus download, and allows us to
 check all of our guard nodes in a single pass, and alert the user if a
 large fraction of them are found to be unreachable. In this way, we can
 keep the code that does these checks mostly compartmentalized away from
 the rest of the guard usage code.

 To avoid active attacks based recognizing the obvious signature of
 directory activity, we could additionally/alternatively perform this check
 at other obvious signs of network liveness, limited to some semi-periodic
 interval.

 We could also inform the user of the top 2 or 3 most common ORport numbers
 for both the reachable and the unreachable sets of guards, and we can also
 state in this same logline if a large number of guards have been marked
 unreachable due to path bias.

 If we implement a layer of entry guards for bridge users, we can actually
 do this same accounting for that layer, too. It bothers me that bridge
 users are basically already forced on to a very restricted set of entry
 points...

 We should also ensure the following properties hold with guard list
 management:
 1. If we attempt to add a guard and it's unreachable but listed as up in
 the consensus, we should still keep it in our list of desirable guards.
 2. Any entry guard the consensus lists as running is not removed from our
 guard list, no matter how long we haven't been able to reach it. We want
 to keep a record of all the unreachable-but-running guards we've ever
 tried, I think.
 3. Anything else?

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5462#comment:8>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs