[tor-bugs] #9206 [Tor]: 'Guard' flags only assigned to first nodes started in a private Tor network

[Tor Bug Tracker & Wiki]

#9206: 'Guard' flags only assigned to first nodes started in a private Tor network
---------------------+------------------------------------------------------
 Reporter:  karsten  |          Owner:     
     Type:  defect   |         Status:  new
 Priority:  normal   |      Milestone:     
Component:  Tor      |        Version:     
 Keywords:           |         Parent:     
   Points:           |   Actualpoints:     
---------------------+------------------------------------------------------
 Rob identified a problem with 'Guard' flags only assigned to the first
 nodes that are started in a private Tor network.  This was originally
 opened as a [https://github.com/shadow/shadow/issues/146 Shadow issue],
 but we decided to move it to Tor's Trac, because it seems like a general
 issue.  Pasting from the Shadow issue here with some minor cleaning up, so
 that it's easier to follow the discussion:

 robgjansen opened this issue a day ago

 In our example scallion topologies, only exit nodes seem to be getting the
 'Guard' flag. Does this have something to do with the order in which we
 boot nodes? Or is there a change that Tor should make when
 TestingTorNetwork is enabled?

 Here is the code in Tor 0.2.3.25 from src/or/dirserv.c that computes
 whether or not a node gets the guard flag.

 {{{
   if (node->is_fast &&
       ((options->AuthDirGuardBWGuarantee &&
         routerbw >= options->AuthDirGuardBWGuarantee) ||
        routerbw >= MIN(guard_bandwidth_including_exits,
                        guard_bandwidth_excluding_exits)) &&
       is_router_version_good_for_possible_guard(ri->platform)) {
     long tk = rep_hist_get_weighted_time_known(
                                       node->identity, now);
     double wfu = rep_hist_get_weighted_fractional_uptime(
                                       node->identity, now);
     rs->is_possible_guard = (wfu >= guard_wfu && tk >= guard_tk) ? 1 : 0;
   } else {
     rs->is_possible_guard = 0;
   }
 }}}

 robgjansen commented a day ago

 Its due to the fact that the weighted fractional uptime and weighted time
 known is used to determine guard status, since its weighted relative to
 the population. This means whichever nodes were started first will get the
 guard flag for the most part.

 I just ran an experiment to verify this: after swapping the start times of
 some exits and nonexits, the nonexits were in fact getting the guard flag
 and the exits were not.

 robgjansen commented a day ago

 @kloesing can we get a config option that allows us to adjust this, and
 only when in TestingTorNetwork mode?

 I think config options for each of these would be helpful:

  *  we assume all nodes were brought up at the same time for purposes of
 this calculation
  *  tighter control over who gets the guard flag - the ability to specify,
 for each node, if that node should get the flag or not

 robgjansen commented a day ago

 A hackish workaround is to start the relays that we want to have the guard
 flag before the rest of the relays, and hope they get assigned properly.

 kloesing commented 19 hours ago

 Nice find! But do you mind if we move this issue to Tor's Trac? This issue
 likely affects Chutney as well, and I bet Nick has an opinion on this.

 robgjansen commented 19 hours ago

 That sounds great. I'm going to leave this ticket open to remind myself
 that I'll need to incorporate whatever solution we decide on Tor's trac
 into our scallion examples.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9206>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online