Opened 6 years ago

Closed 6 years ago

#9206 closed defect (implemented)

'Guard' flags only assigned to first nodes started in a private Tor network

Reported by: karsten Owned by:
Priority: Medium Milestone: Tor: 0.2.5.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-auth tor-relay simulation testing SponsorF20131031
Cc: robgjansen, nickm, ln5 Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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 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.

Child Tickets

Change History (20)

comment:1 Changed 6 years ago by nickm

Keywords: tor-auth tor-relay simulation testing added
Milestone: Tor: 0.2.5.x-final

Two approaches here that seem sensible:

  • Brute-force. Add a way to tell authorities that Node X should be a guard, and node Y should not, no matter what.
  • History generation. Start up the network with a little fabricated history, such that the nodes have a pre-existing distribution (or whatever we think is reasonable) of observed mtbf and wfu. This will probably make the results more accurate for simulations that can go on for a while, and actually allow the tests to test flag assignment.

comment:2 Changed 6 years ago by arma

The "history generation" approach looks appealing.

comment:3 Changed 6 years ago by robgjansen

Is there any reason we can't do both? The brute-force seems extremely easy to implement.

comment:4 Changed 6 years ago by nickm

What were you thinking for this easy implementation? Something else to go in the authorities' "approved-routers" files?

comment:5 Changed 6 years ago by nickm

(Also be aware that for many experiments, if you take the brute-force approach, you'll change the kind of network topology that the authorities construct, and thereby change your results.)

comment:6 in reply to:  4 ; Changed 6 years ago by robgjansen

Replying to nickm:

What were you thinking for this easy implementation? Something else to go in the authorities' "approved-routers" files?

I'm not familiar with the approved-routers files. If it means we would have something like a list of guards in a special file parsed by the authorities, the information in which they would use to assign guard flags, than that could work.

Alternatively, is there anything wrong (I'm probably missing something here) with passing in a list of fingerprints/addresses/hostnames as a torrc config, where any node in this list will be brute-force-assigned the guard flag? (Testing only networks of course. Its easiest to work with hostnames in Shdow at the moment.) I guess this is a variation on the approved-routers list? Note that I'm selfishly looking for ease of configuration here, and torrc options have been the best (read: quickest) way to enable custom functionality quickly (I only have to compile once, and can then run several experiments with various settings).

For the record, I'm not opposed to the history generation approach, but just thought the brute-force approach may be a quick fix for the time being.

comment:7 in reply to:  6 Changed 6 years ago by nickm

Replying to robgjansen:

Replying to nickm:

What were you thinking for this easy implementation? Something else to go in the authorities' "approved-routers" files?

I'm not familiar with the approved-routers files. If it means we would have something like a list of guards in a special file parsed by the authorities, the information in which they would use to assign guard flags, than that could work.

Yup. It's already where the authorities take lists of nodes for other purposes, so it might make sense here too. The relevant code to load it is in dirserv_load_fingerprint_file() in dirserv.c.

(I prefer this to the torrc approach, since it's already where we handle information of this kind)

comment:8 Changed 6 years ago by arma

If we follow the current pattern with badexit and friends, we'll let you specify relays-that-should-get-the-Guard-flag by fingerprint in the approved-routers file, and by address / netmask in the torrc file.

comment:9 Changed 6 years ago by robgjansen

OK.

FYI: in Shadow, nodes and therefore fingerprints are generated on the fly after the simulation begins, so that won't work too well. Currently, addresses are also assigned randomly to nodes at runtime, although I guess this will give us an incentive to support configurable node addresses. (Hostnames in shadow are guaranteed to resolve correctly at runtime.)

comment:10 Changed 6 years ago by ln5

Cc: ln5 added

The brute-force method seems less useful for Shadow, if I read this ticket correctly. I see little reason for implementing it given that we do implement the 'history generation' thing.

For generating history, I will try generating 'router-stability' files for the dir auths (see rep_hist_record_mtbf_data() for the file format).

comment:11 Changed 6 years ago by ln5

Status: newneeds_review

Based on looking at how the directory authorities vote Guard in a
Chutney network (without bandwidth authority data), generating 'state'
files for relays for which we want to influence Guard seems best.

Writing something high, like 10*1024*1024, for the following values in
the 'state file for a relay will give it Fast and Guard.

BWHistoryReadValues 10485760
BWHistoryReadMaxima 10485760
BWHistoryWriteValues 10485760
BWHistoryWriteMaxima 10485760

Making sure that a relay does _not_ get Guard is less straight forward
-- simply setting something low will make fast_bandwidth_kb become so
low that they will still be fast. Also, when relays advertize zero
bandwidth, things become weird.

See bug9206 in my Chutney repo for a quick'n'dirty change to
tools/bootstrap-network.sh which does this for relays (not dirauths
and client).

If we think that this would be useful to Chutney users we could make Node.init() take a "flag_hints" parameter saying things like FH_Guard and generate a fake history accordingly instead of having the bootstrap script doing it. Let me know.

comment:12 in reply to:  11 ; Changed 6 years ago by ln5

Replying to ln5:

Based on looking at how the directory authorities vote Guard in a
Chutney network (without bandwidth authority data), generating 'state'
files for relays for which we want to influence Guard seems best.

That might be true for Chutney networks but looking at Shadow, it seems like it might be using bandwidth files. At least that's hinted in scalliontor_init_v3bw() [src/plugins/scallion/shd-scallion.c].

Rob, are you using this? The example networks don't seem to use it, I don't see V3BandwidthsFile in any of their torrc's.

comment:13 in reply to:  12 ; Changed 6 years ago by robgjansen

Replying to ln5:

Replying to ln5:

Based on looking at how the directory authorities vote Guard in a
Chutney network (without bandwidth authority data), generating 'state'
files for relays for which we want to influence Guard seems best.

That might be true for Chutney networks but looking at Shadow, it seems like it might be using bandwidth files. At least that's hinted in scalliontor_init_v3bw() [src/plugins/scallion/shd-scallion.c].

Rob, are you using this? The example networks don't seem to use it, I don't see V3BandwidthsFile in any of their torrc's.

We were at one point but it must have gotten removed. Should we be using these? Would this allow us to specify guard flags?

comment:14 in reply to:  13 ; Changed 6 years ago by ln5

Replying to robgjansen:

We were at one point but it must have gotten removed. Should we be using these? Would this allow us to specify guard flags?

No. I'm asking because since getting guard depends not only on (weighted) uptime, but also on whether you're Fast or not, which is influenced by either bandwidth files or, if those are not present, what the relays say themselves.

My suggested solution, based on a Chutney use case, was to make relays brag about high speed which in a network where dir auths don't have bandwidth files will make them all Guards.

The reason that I dropped the "brute force solution" (forcing flags on relays by configuring dir auths to just set the bloody flag, goddamit) is that in Shadow, there seems to be no way of refer to a relay before the network is started. I wasn't pondering the idea of adding a dir auth configuration option making _all_ relays Guards, Stable or whatever. Would that be useful to you, Rob?

comment:15 in reply to:  14 Changed 6 years ago by robgjansen

Replying to ln5:

Replying to robgjansen:

We were at one point but it must have gotten removed. Should we be using these? Would this allow us to specify guard flags?

No. I'm asking because since getting guard depends not only on (weighted) uptime, but also on whether you're Fast or not, which is influenced by either bandwidth files or, if those are not present, what the relays say themselves.

My suggested solution, based on a Chutney use case, was to make relays brag about high speed which in a network where dir auths don't have bandwidth files will make them all Guards.

Doesn't this come with the unintended consequence of messing up path selection in other ways?

The reason that I dropped the "brute force solution" (forcing flags on relays by configuring dir auths to just set the bloody flag, goddamit) is that in Shadow, there seems to be no way of refer to a relay before the network is started.

We can refer to them by domain name or nickname (the 'id' attribute of the 'node' element in the hosts.xml files), but you're correct that we cannot refer to them by fingerprint because its dynamically generated.

I wasn't pondering the idea of adding a dir auth configuration option making _all_ relays Guards, Stable or whatever. Would that be useful to you, Rob?

In my experience, the "start the relays that we want to get the guard flag first" approach *usually* results in the correct relays getting the guard flags. ATM, I don't see a clear benefit in other approaches that don't *guarantee* correct assignment.

In testing mode, perhaps each relay could tell the dirauths which flags it wanted, and the dirauth could just blindly agree. Though, the code complexity is probably high, and I understand that this sort of feature could be considered unclean and a nightmare to maintain. So, maybe the 'start the guards first' approach is good enough?

comment:16 Changed 6 years ago by nickm

For the end-of-month goals here, just adding an option to force nodes to be guard/non-guard from the approved-routers file, or with whatever other temporary kludge works around issues (list by nickname or fingerprint?), is fine. Or whatever else works well enough.

For longer term, it seems like we'd like to have something that allows the authorities to transition into believing real measurements once the network has been running for a bit. Perhaps after the network has been running for long enough to collect data, it's time to turn off the "force nodes to be guard/non-guard" flags and start collecting real measurements?

comment:17 Changed 6 years ago by ln5

Please see branch bug9206 in my public repo.
It's been tested in a Chutney network.
I'm about to start testing this in a Shadow network.

Rob, this solution requires us to list relay fingerprints in the torrc's of the directory authorities. I will figure out how that can be done. You've already pointed me at some information in a Shadow ticket IIRC.

comment:18 Changed 6 years ago by ln5

The solution proposed in branch 9206 is not useful for Shadow/Scallion.

Please instead see branch bug9206_option which adds TestingDirAuthVoteGuard that takes a list of relays like ExcludeNodes.

This has been tested in a Chutney network and a 'minimal' Shadow network.

comment:19 Changed 6 years ago by ln5

Keywords: SponsorF20131031 added

comment:20 Changed 6 years ago by nickm

Resolution: implemented
Status: needs_reviewclosed

Yes, this looks fine to me. Merged to master.

Note: See TracTickets for help on using tickets.