Opened 6 months ago

Last modified 6 months ago

#30164 new defect

Inconsistent Guard flag assignment

Reported by: Jaym Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: unspecified
Severity: Normal Keywords:
Cc: amj703 Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

TL;DR: we observed that the result of the consensus computation, taking in account all the votes, may lead to assign a flag Guard to a relay that does not verify all constraints from the specifications.

The Tor specifications gives the following constraints for a possible guard:

   "Guard" -- A router is a possible Guard if all of the following apply:
       - It is Fast,
       - It is Stable,
       - Its Weighted Fractional Uptime is at least the median for "familiar"
         active routers,
       - It is "familiar",
       - Its bandwidth is at least AuthDirGuardBWGuarantee (if set, 2 MB by
         default), OR its bandwidth is among the 25% fastest relays,
       - It qualifies for the V2Dir flag as described below (this
         constraint was added in 0.3.3.x, because in 0.3.0.x clients
         started avoiding guards that didn't also have the V2Dir flag).

        To calculate weighted fractional uptime, compute the fraction
        of time that the router is up in any given day, weighting so that
        downtime and uptime in the past counts less.

        A node is 'familiar' if 1/8 of all active nodes have appeared more
        recently than it, OR it has been around for a few weeks.

Currently, regarding bandwidth, the lower bar for the Guard flag is 2000 (AuthDirGuardBWGuarantee). However, we may found sometimes in recent consensus Guard relays with less than 2000 consensus weight. Here is an example, and some vote info to understand the problem:

r nibbana AltmzrwHD8sFGdIGzwz0llwgyW4zSkWB4u/6jLGBDzfsWCuKv5KWrg 2019-04-04 10:21:46 185.100.85.61         443 80
s Exit Fast Guard HSDir Running Stable V2Dir Valid
v Tor 0.3.4.8
pr Cons=1-2 Desc=1-2 !DirCache=1-2 HSDir=1-2 HSIntro=3-4 HSRend=1-2 Link=1-5 !LinkAuth=1,3 Microdesc=1-2 Relay=1-2
w Bandwidth=1860

Here are all the bandwidth lines and flags lines of nibbana from the 8 votes:

s Exit Fast Guard HSDir Running Stable V2Dir Valid
w Bandwidth=2621

s Exit Fast HSDir Running Stable V2Dir Valid
w Bandwidth=2621 Measured=1860

s Exit Fast Guard HSDir Running Stable V2Dir Valid
w Bandwidth=2621 Measured=5000

s Exit Fast Guard HSDir Running Stable V2Dir Valid
w Bandwidth=2621 Measured=2180

s Exit Fast Running Stable V2Dir Valid
w Bandwidth=2621 Measured=1670

s Exit Fast Guard HSDir Running Stable V2Dir Valid
w Bandwidth=2621

s Exit Fast HSDir Running Stable V2Dir Valid
w Bandwidth=2621 Measured=1760

s Exit Fast Guard HSDir Running Stable V2Dir Valid
w Bandwidth=2621

Given the votes, we can make the following observations:

  • All votes seem to verify the constraint (no Guard flag if Measured bandwidth < 2000)
  • We have 5 over 8 votes with the flag Guard, but only 2 over 5 if we consider only the votes with measured bandwidth
  • Among 5 Measured bandwidth lines, the median is 1860, which is inline with the value in the consensus.

So, giving those observation, the inconsistency seems that the Guard flag is decided over the total number of votes instead of the 5 votes with measured bandwidth. We can dig a bit more and confirm this by looking in src/feature/dirauth/dirvote.c, function networkstatus_compute_consensus. Starting at line 2081 (on master), we can see that it's going through all the votes to compute the guard flag, and the condition is that the number of Guard flags within the votes must be higher than half of the number of votes (here, we have 5/8 so it works).

Solution: We probably want to decide the guard flag upon the votes which have a Measured bandwidth line and ignore the other votes (only for the guard flag). This is just a few lines of codes :)

Child Tickets

Change History (6)

comment:1 Changed 6 months ago by amj703

Cc: amj703 added

comment:2 Changed 6 months ago by amj703

This seems like it could affect any other flag based on bandwidth, which includes at least the Fast flag.

Last edited 6 months ago by amj703 (previous) (diff)

comment:3 Changed 6 months ago by arma

I believe that we are currently doing things as intended. That is, I think when we built the thing that is happening now, we meant to build it that way.

But I agree with you that we should consider changes. See ticket #11327 for what I think is the same ticket as this one (and even mentions the same issue with the Fast flag too, as Aaron points out).

The problem stems from the fact that we deployed the bwauth measurement concept, but then only some authorities started measuring, which creates an imbalance where some authorities are more important (and more influential) than others.

For an even more thorough change, check out the idea in #10968: there, we point out that the Guard flag, if it's supposed to be based on availability of the relay in the past, should be entirely about whether the relay was in the consensus, not about whether this particular authority could reach it at various times in the past. (See also #11328 here.)

While we're talking about bugs that probably affect the Guard flag: I believe the time-known (and therefore possibly also the WFU) calculation is broken somehow. Many more details in #19162 (where I have been hoping to assign the HSDir flag only to relays in the top half of time-known, but where I'm having trouble following through with that idea because I can't figure out what's going on with the time-known calculations).

comment:4 Changed 6 months ago by nickm

Component: Core Tor/DirAuthCore Tor/Tor
Milestone: Tor: unspecified

(Changing component: we usually use "DirAuth" for something that the directory authorities need to take action on, and "Tor" for something about the Tor software.)

comment:5 Changed 6 months ago by amj703

Roger, I agree that this duplicates #11327, which is more general in that it includes the Fast flag.

comment:6 in reply to:  3 Changed 6 months ago by Jaym

Replying to arma:

I believe that we are currently doing things as intended. That is, I think when we built the thing that is happening now, we meant to build it that way.

But I agree with you that we should consider changes. See ticket #11327 for what I think is the same ticket as this one (and even mentions the same issue with the Fast flag too, as Aaron points out).

The problem stems from the fact that we deployed the bwauth measurement concept, but then only some authorities started measuring, which creates an imbalance where some authorities are more important (and more influential) than others.

Allow me to draw a parallel: I see the Tor ecosystem a bit like a representative but auditable democracy, where some trusted people vote upon inputs. This problem looks like if one of the elected individuals was casting vote over project/law that they did not even read. It sounds like the trusted person does not make an educated opinion about the question but comply with (potentially) malicious party to cast an uneducated vote. If such a thing was verifiable IRL, that would really be upsetting no?

That's why I wonder if we should not make uneducated opinions to back off for this kind of feature. And as you said, it creates imbalance. Yet, we could come up with some rules like if "half of the trustees have educated opinions on security features, let's trust them". That looks reasonable and fairly easy to implement.

Note: See TracTickets for help on using tickets.