Opened 4 years ago

Closed 4 years ago

#12206 closed defect (implemented)

Switch to one guard per client

Reported by: asn Owned by:
Priority: Medium Milestone: Tor: 0.2.6.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-client, prop236, tor-guard, 026-triaged-1
Cc: Actual Points:
Parent ID: #11480 Points:
Reviewer: Sponsor:

Description

We should switch to one guard per client as per proposal 236.

Child Tickets

Change History (10)

comment:1 Changed 4 years ago by asn

We can use the configurable NumEntryGuards switch for this.

We should be careful of hardcoded parameters like preferred_min = 2; in choose_random_entry_impl().

comment:2 Changed 4 years ago by asn

I've been monitoring the entrynodes.c logs of my tor client for the past 3 days. I've been running my Tor with NumEntryGuards=1 for those 3 days, and everything seems to be working reasonably well.

However, yesterday I noticed that my Tor skipped my main guard, and started connecting to the second one in the list.

This happened like this:

  • My main guard is not a DirCache. So every now and then, Tor connects to the second guard in my guard list (my dirguard) to fetch directory documents. This means that both guards are usually marked as 'up'.
  • I had a very short network downtime (only a few seconds), so Tor could not connect to my main guard. Tor then tried to connect to the next 'up' guard node in my list, which is my dirguard. The network was up by that time, so Tor managed to connect to my dirguard, which became my main guard node for that session.

Since my dirguard was not a freshly added guard node, it didn't trigger the first_contact behavior of entry_guard_register_connect_status(), which would have fixed the guard skip (because all the previous guard nodes would have been retried).

comment:3 Changed 4 years ago by nickm

Keywords: 026 added

comment:4 Changed 4 years ago by nickm

Keywords: 026-triaged-1 added; 026 removed

comment:5 Changed 4 years ago by asn

To proceed with this we will need to decide what to do with regards to directory guards:
https://lists.torproject.org/pipermail/tor-dev/2014-June/006944.html

We probably need to switch NumEntryGuards to 1 and pump up NumDirectoryGuards to 3, to follow Nick's suggestion. At the same time we need to start thinking of the ideas from here:
https://lists.torproject.org/pipermail/tor-dev/2014-June/006944.html
in case we can eventually bring the number of directory guards to 1 too.

Also, maybe we should add more code to *strictly* prefer our circuit guard to fetch directory documents, and only resort to the directory guards if our circuit guard is not a DirCache or if it doesn't have the descriptor we asked for.

comment:6 Changed 4 years ago by asn

Also, Nick in https://lists.torproject.org/pipermail/tor-dev/2014-June/006945.html says:

We should also reconsider the way that compute_frac_paths_available
should work in a 1-guard world.  Do we want to keep the requirement as
"don't build circuits until you have the microdescriptors necessary to
build X% of the paths through the network?" Or should we change it to
require X% of all paths _through your guard_?  Or raise the X?

comment:7 Changed 4 years ago by asn

And #12688 is our plan for deployment.

comment:8 Changed 4 years ago by arma

asn: ok to close as done?

comment:9 in reply to:  8 Changed 4 years ago by asn

Replying to arma:

asn: ok to close as done?

I guess so. Seems like NumEntryGuards=1 has appeared in Tor consensuses :)

$ grep 'Guards=' cached-consensus 
NumDirectoryGuards=3 NumEntryGuards=1

We should think more if we want to do something wrt comment:6 but I think the current behavior is not too terrible.

comment:10 Changed 4 years ago by nickm

Resolution: implemented
Status: newclosed
Note: See TracTickets for help on using tickets.