Tor 0.3.x clients won't use Guard-flagged relays as Guards if they don't have V2Dir, throwing off consensus position weights

Starting in Tor 0.3.0, clients have additional constraints on what counts as a usable guard. Specifically, node_is_possible_guard() now demands node_is_dir(node) before it will consider node as a guard.

But the path position weights in the consensus are based on the Guard flag.

This inconsistency will lead to Guards that don't have the V2Dir flag being way underused, and Guards that do have the V2Dir flag being overused.

changed milestone to %Tor: 0.3.3.x-final in legacy/trac

added 031-backport-maybe in Legacy / Trac 032-backport-maybe in Legacy / Trac 032-unreached in Legacy / Trac 033-removed-20180320 in Legacy / Trac 033-roadmap-proposed in Legacy / Trac 033-triage-20180320 in Legacy / Trac component::core tor/tor in Legacy / Trac fast-fix in Legacy / Trac milestone::Tor: 0.3.3.x-final in Legacy / Trac owner::arma in Legacy / Trac points::0.1 in Legacy / Trac priority::medium in Legacy / Trac resolution::implemented in Legacy / Trac severity::normal in Legacy / Trac status::closed in Legacy / Trac type::defect in Legacy / Trac version::tor 0.3.0.1-alpha in Legacy / Trac labels

One fix we should consider is simply not assigning the Guard flag if we aren't going to assign the V2Dir flag. Consider:

$ grep "^s " cached-consensus |grep Guard|wc -l
2509
$ grep "^s " cached-consensus |grep Guard|grep -v "V2Dir"|wc -l
244

I haven't added up the capacity/speed/bandwidth/whatever of these relays for comparison though.

But since they essentially already aren't guards for Tor 0.3 and later clients, maybe that makes the choice easier?

If we go this route, we might want to move the milestone up to e.g. Tor 0.3.1, so authorities will do the new behavior sooner, since Tor 0.3.0 clients are already doing their part of the problem.

Here's the simple patch:

diff --git a/src/or/dirserv.c b/src/or/dirserv.c
index 2b10a09..c79bdfd 100644
--- a/src/or/dirserv.c
+++ b/src/or/dirserv.c
@@ -2190,6 +2190,7 @@ set_routerstatus_from_routerinfo(routerstatus_t *rs,
   rs->is_valid = node->is_valid;
 
   if (node->is_fast && node->is_stable &&
+      ri->supports_tunnelled_dir_requests &&
       ((options->AuthDirGuardBWGuarantee &&
         routerbw_kb >= options->AuthDirGuardBWGuarantee/1000) ||
        routerbw_kb >= MIN(guard_bandwidth_including_exits_kb,

I expect that updating the specs and documentation and so on will be a bit more involved.

Also, in a later Tor, we'll want to refactor so we calculate rs->is_v2_dir higher up, and then just use that value in the 'if'. Surely that refactoring won't break anything, but the above diff is still an easier sell.

Also also, once the authorities are doing this new behavior, we should consider teaching clients to assume that all Guards are automatically able to be directory mirrors, so we're not stuck dragging around a consensus flag albatross that doesn't even refer to the current version of the directory protocol. :)

(But, one step at a time.)

Mark a large number of tickets that I do not think we will do for 0.3.2.

Trac:
Milestone: Tor: 0.3.2.x-final to Tor: unspecified
Keywords: N/A deleted, 032-unreached added

I think we should push this fix so the dir auths will have it. I've been running it on moria1 since I made this ticket, but I'm not enough by myself.

Thinking is not enough. You must tag.

Trac:
Points: N/A to 0.1
Version: N/A to Tor: 0.3.0.1-alpha
Keywords: N/A deleted, 032-backport-maybe, 031-backport-maybe added
Milestone: Tor: unspecified to Tor: 0.3.3.x-final

Marking all tickets reached by current round of 033 triage.

Trac:
Keywords: N/A deleted, 033-triage-20180320 added

Mark all not-already-included tickets as pending review for removal from 0.3.3 milestone.

Trac:
Keywords: N/A deleted, 033-removed-20180320 added

These tickets were marked as removed, and nobody has said that they can fix them. Let's remember to look at 033-removed-20180320 as we re-evaluate our triage process, to see whether we're triaging out unnecessarily, and to evaluate whether we're deferring anything unnecessarily. But for now, we can't do these: we need to fix the 033-must stuff now.

Trac:
Milestone: Tor: 0.3.3.x-final to Tor: unspecified

Replying to arma:

Here's the simple patch:

Ok, my bug22310 branch implements this one-liner.

I expect that updating the specs and documentation and so on will be a bit more involved.

I have pushed a bug22310 branch to my torspec too, which adds this constraint to the definition of the Guard flag.

Trac:
Owner: N/A to arma
Status: new to assigned

Scheduling this ticket to get attention / discussion in the 033 timeframe.

Trac:
Status: assigned to needs_review
Keywords: N/A deleted, 033-roadmap-proposed, fast-fix added

Trac:
Milestone: Tor: unspecified to Tor: 0.3.3.x-final

lgtm; merging to 0.3.3 and forward.

Trac:
Resolution: N/A to implemented
Status: needs_review to closed

Ok, I merged my torspec branch too, on the theory that otherwise we'd leave it behind and forgotten.

closed

changed time estimate to 48m

moved from legacy/trac#22310 (moved)

added Bug label and removed 1 deleted label

removed 1 deleted label