Re: [tor-bugs] #21969 [Core Tor/Tor]: We're missing descriptors for some of our primary entry guards

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#21969: We're missing descriptors for some of our primary entry guards
-----------------------------------+------------------------------------
 Reporter:  asn                    |          Owner:  asn
     Type:  defect                 |         Status:  assigned
 Priority:  High                   |      Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor           |        Version:
 Severity:  Normal                 |     Resolution:
 Keywords:  tor-guard, tor-bridge  |  Actual Points:
Parent ID:                         |         Points:  1.5
 Reviewer:                         |        Sponsor:  SponsorU
-----------------------------------+------------------------------------

Comment (by asn):

 Replying to [comment:23 s7r]:
 > Replying to [comment:22 teor]:
 > > Operators can explicitly disable DirCache, and can also disable it by
 setting various other options (like AccountingMax), or by having low RAM
 or bandwidth. Also, DirCache was only introduced in 0.2.8, and we support
 relays back to 0.2.4.
 > >
 > > So while it is true that most guards are DirCaches, not all guards
 will be, even in the future.
 > >
 > > Also, this might enable an attack/issue where a guard posts one
 descriptor to the directory authorities, and another to its clients. (This
 is avoided by using microdescriptors, because their hashes are in the
 consensus.)
 >
 > Thanks for the feedback teor. In this case we need to think about a
 logic where first of all a client will fetch the descriptors of the
 sampled guards (primary first, and move down the list to all the guards we
 ever connected to, until we have their descriptors). After that we
 download / refresh the rest of few thousands descriptors.

 Personally, I'm not so concerned about the case where we fetch the primary
 guard descriptor in random order, and some times it might take 1-3 seconds
 more to get the descriptor (as in your logs
 attachment:21969_primary_guards_descriptors_initial_bootstrap.txt).

 I'm more concerned about pathological cases that significantly delay
 bootstrapping. That can happen in the bridge case if primary bridges are
 down, or in the non-bridge case if primary guards are down.

 Here is a suggested hotfix for the above pathological case
 of`guard_selection_have_enough_dir_info_to_build_circuits()`:

 {{{
 If we are inspecting a non-bridge primary guard that is missing
 from the current consensus, don't count it as missing a descriptor
 for the purposes of that function.

 If we are inspecting a primary bridge that's missing a descriptor
 for more than N=7 seconds, don't count it as missing a descriptor
 for the purposes of that function.
 }}}

 The idea here is that if a primary guard is missing from the consensus, we
 might never get its descriptor. Also if that primary guard is a bridge, if
 the bridge is offline we will never get its descriptor either, so don't
 bother blocking on it.

 FWIW, IMO the time-sensitive logic on the second rule is kinda flaky and
 might delay bootstrapping. Here is a more sane alternative, but I think it
 will be a bigger hassle to implement:
 {{{
 If we are inspecting a primary bridge that's missing a descriptor
 and we have failed to connect to that bridge, don't count it as
 missing a descriptor for the purposes of that function.
 }}}

 Also, we should strongly consider engraving these rules (and the general
 bootstrapping blocking logic) into torspec.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21969#comment:24>
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