Opened 5 years ago

Closed 3 years ago

#11480 closed task (implemented)

Implement the single guard node proposal (prop#236)

Reported by: asn Owned by:
Priority: High Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: 0.2.7
Severity: Normal Keywords: tor-client, prop236, 026-triaged-1, 027-triaged-1-in, 028-triaged, SponsorU-deferred, tor-03-unspecified-201612
Cc: Actual Points:
Parent ID: Points: medium
Reviewer: Sponsor:

Description

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.

Child Tickets

TicketStatusOwnerSummaryComponent
#9273closedBrainstorm tradeoffs from moving to 2 (or even 1) guardsCore Tor/Tor
#9321closedLoad balance right when we have higher guard rotation periodsCore Tor/Tor
#12206closedSwitch to one guard per clientCore Tor/Tor
#12219closedClean dead code from entrynodes.cCore Tor/Tor
#12598closedasnIncrease rotation period of guard nodesCore Tor/Tor
#12688closedMake NumEntryGuards configurable by the consensusCore Tor/Tor
#12690closednickmRaise the bandwidth threshold for being a guardCore Tor/Tor

Change History (28)

comment:1 Changed 5 years ago by asn

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?

comment:2 Changed 5 years ago by nickm

Milestone: Tor: 0.2.6.x-final

comment:3 Changed 5 years ago by asn

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

comment:4 in reply to:  3 ; Changed 5 years ago by 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):

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?

comment:5 Changed 5 years ago by asn

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

comment:6 in reply to:  4 Changed 5 years ago by karsten

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):

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.

comment:7 Changed 5 years ago by atagar

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

comment:8 Changed 5 years ago by nickm

Keywords: prop236 added

comment:9 Changed 5 years ago by atagar

Parent ID: #11045

comment:10 Changed 5 years ago by nickm

Priority: normalmajor

comment:11 Changed 5 years ago by nickm

Parent ID: #11045

comment:12 Changed 5 years ago by nickm

Keywords: 026-triaged-1 added

comment:13 Changed 5 years ago by nickm

Milestone: Tor: 0.2.6.x-finalTor: 0.2.7.x-final

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

comment:14 Changed 5 years ago by nickm

Status: newassigned

comment:15 Changed 4 years ago by nickm

Keywords: 027-triaged-1-in added

Marking more tickets as triaged-in for 0.2.7

comment:16 Changed 4 years ago by isabela

Keywords: SponsorU added
Points: medium
Version: Tor: 0.2.7

comment:17 Changed 4 years ago by nickm

Milestone: Tor: 0.2.7.x-finalTor: 0.2.8.x-final

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

comment:18 Changed 4 years ago by nickm

Keywords: 028-triaged added

comment:19 Changed 4 years ago by nickm

Keywords: SponsorU removed
Sponsor: SponsorU

Bulk-replace SponsorU keyword with SponsorU field.

comment:20 Changed 4 years ago by nickm

Milestone: Tor: 0.2.8.x-finalTor: 0.2.9.x-final

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

comment:21 Changed 3 years ago by nickm

Sponsor: SponsorUSponsorU-can

comment:22 Changed 3 years ago by nickm

Severity: Normal
Summary: Implement the single guard node proposalImplement the single guard node proposal (prop#236)

comment:23 Changed 3 years ago by asn

Milestone: Tor: 0.2.9.x-finalTor: 0.2.???

comment:24 Changed 3 years ago by isabela

tickets market to be removed from milestone 029

comment:25 Changed 3 years ago by nickm

Keywords: SponsorU-deferred added
Sponsor: SponsorU-can

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.

comment:26 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:27 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

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

comment:28 Changed 3 years ago by nickm

Resolution: implemented
Status: assignedclosed

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

Note: See TracTickets for help on using tickets.