#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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs