Implement the single guard node proposal (prop#236)

After the The move to a single guard node proposal gets revised, reviewed and merged we will need to start implementing it.

An early draft of the proposal can be found in: https://lists.torproject.org/pipermail/tor-dev/2014-March/006570.html

This is a ticket to discuss implementation matters etc.

changed milestone to %Tor: unspecified

added 026-triaged-1 027-triaged-1-in 028-triaged SponsorU-deferred component::core tor/tor milestone::Tor: unspecified points::medium priority::high prop236 resolution::implemented severity::normal status::closed tor-03-unspecified-201612 tor-client type::task version::tor 0.2.7 labels

Some notes:

To reduce the number of guard nodes I should look into decide_num_guards(). To increase the rotation period I should look into MIN_GUARD_LIFETIME et al. or play with the GuardLifetime consensus parameter on the authority side.

Also, what about directory guards?

Trac:
Milestone: N/A to Tor: 0.2.6.x-final

Some notes on an implementation plan:

Switch to one guard per client

• Look into decide_num_guards().
• See if setting NumEntryGuards=1 breaks any assumption of the rest of the code.
• Implementation depends on whether we pick alternative behavior of section 1.1.1 or not.

Increase guard rotation period

• Either play with MIN_GUARD_LIFETIME or use the GuardLifetime consensus option.
• Implementation depends on whether we pick alternative behavior of section 1.2.1 or not.

Raise bw thresholds for guard

• See set_routerstatus_from_routerinfo() and AuthDirGuardBWGuarantee etc.
• How to test: Make fake network and see which guards are eligible to become guards

Prioritize young guards for non-guard tasks

• Implementation plan: Download/parse/verify old consensuses in an external script, write file with results, have little-t-tor read the results.

• Bandwidth authorities: See dirserv_read_measured_bandwidths() and https://gitweb.torproject.org/torflow.git/blob/HEAD:/NetworkScanners/BwAuthority/README.spec.txt#l333

• How to test the external script: Make artificial data sets of consensuses and see if the external script parses them properly.

• How to test Tor: Create artificial guard age results file, give the test a fake network (some relays) and see if Tor generates the right weights for the relays.

Replying to asn:

== Prioritize young guards for non-guard tasks ==

• Implementation plan: Download/parse/verify old consensuses in an external script, write file with results, have little-t-tor read the results.

Two questions on this task (also see #10968 (moved)):

a) How are we going to get past consesuses? AFAIK, directories don't keep and serve old consesuses. Is metrics.tpo the only place where we can get them? Is it reasonalbe to make metrics.tpo a single point of failure for this feature?

b) We will need to verify the sigs of the past consesuses. Can arm verify signatures of Tor documents? Also, what can go wrong with verifying consesus sigs from many months ago? Have auths ever changed their identity keys? Also, what happens if we try to parse a badly-signed consesus? Should we just ignore it?

We also need to decide if we want to do the alternative behaviors suggested in sections 1.1.1 and 1.2.1 of https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/236-single-guard-node.txt

Replying to asn:

Replying to asn:

== Prioritize young guards for non-guard tasks ==

• Implementation plan: Download/parse/verify old consensuses in an external script, write file with results, have little-t-tor read the results.

Two questions on this task (also see #10968 (moved)):

a) How are we going to get past consesuses? AFAIK, directories don't keep and serve old consesuses. Is metrics.tpo the only place where we can get them? Is it reasonalbe to make metrics.tpo a single point of failure for this feature?

Would somebody want to run a fall-back instance of the part of metrics.tpo that archives consensuses? I run two instances, but I sure wouldn't mind knowing that there's another instance running that is not run by me.

b) We will need to verify the sigs of the past consesuses. Can arm verify signatures of Tor documents?

stem, not arm. That's a question for atagar.

Also, what can go wrong with verifying consesus sigs from many months ago? Have auths ever changed their identity keys?

metrics.tpo also serves past certificates that you could use here. You'll also want to extract a list of authority identities that little-t-tor clients considered valid. That list changes every now and then, but not very often.

Also, what happens if we try to parse a badly-signed consesus? Should we just ignore it?

Probably warn about the bad signature and ignore it. If the consensus still has enough good signatures for little-t-tor clients to accept it, you can probably accept it, too.

b) We will need to verify the sigs of the past consesuses. Can arm verify signatures of Tor documents?

stem, not arm. That's a question for atagar.

Stem can check the server descriptor digestests if you have PyCrypto available...

https://gitweb.torproject.org/stem.git/blob/HEAD:/stem/descriptor/server_descriptor.py#l717

... but it doesn't yet check the consensus signatures. Patches welcome. :)

Trac:
Keywords: tor-client deleted, tor-client prop236 added

Trac:
Parent: N/A to #11045 (closed)

Trac:
Priority: normal to major

Trac:
Parent: #11045 (closed) to N/A

Trac:
Keywords: tor-client prop236 deleted, tor-client prop236 026-triaged-1 added

This will be done when #12598 (moved) is done; moving to 0.2.7

Trac:
Milestone: Tor: 0.2.6.x-final to Tor: 0.2.7.x-final

Trac:
Status: new to assigned

Marking more tickets as triaged-in for 0.2.7

Trac:
Keywords: tor-client prop236 026-triaged-1 deleted, tor-client, 026-triaged-1, prop236, 027-triaged-1-in added

Trac:
Version: N/A to Tor: 0.2.7
Keywords: N/A deleted, SponsorU added
Points: N/A to medium

Much of this is done in 0.2.7; most of the rest must wait for 0.2.8, I expect.

Trac:
Milestone: Tor: 0.2.7.x-final to Tor: 0.2.8.x-final

Trac:
Keywords: N/A deleted, 028-triaged added

Bulk-replace SponsorU keyword with SponsorU field.

Trac:
Sponsor: N/A to SponsorU
Keywords: SponsorU deleted, N/A added

These seem like features, or like other stuff unlikely to be possible this month. Bumping them to 0.2.9

Trac:
Milestone: Tor: 0.2.8.x-final to Tor: 0.2.9.x-final

Trac:
Sponsor: SponsorU to SponsorU-can

Trac:
Summary: Implement the single guard node proposal to Implement the single guard node proposal (prop#236)
Severity: N/A to Normal
Reviewer: N/A to N/A

Trac:
Milestone: Tor: 0.2.9.x-final to Tor: 0.2.???

tickets market to be removed from milestone 029

Remove the SponsorU status from these items, which we already decided to defer from 0.2.9. add the SponsorU-deferred tag instead in case we ever want to remember which ones these were.

Trac:
Keywords: N/A deleted, SponsorU-deferred added
Sponsor: SponsorU-can to N/A

Milestone renamed

Trac:
Milestone: Tor: 0.2.??? to Tor: 0.3.???

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

Trac:
Keywords: N/A deleted, tor-03-unspecified-201612 added
Milestone: Tor: 0.3.??? to Tor: unspecified

This was partially done, and partially superseded by proposal 271.

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

closed

mentioned in issue #12207 (moved)

mentioned in issue #12219 (moved)

mentioned in issue #12598 (moved)

mentioned in issue #12688 (moved)

moved to tpo/core/tor#11480 (closed)

mentioned in issue tpo/core/tor#12207 (closed)