Opened 6 years ago

Last modified 19 months ago

#7798 needs_information defect

Use directory guards even when consensus isn't live

Reported by: nickm Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-client needs-design guards anti-enumeration fallback intro
Cc: teor Actual Points:
Parent ID: Points: 5
Reviewer: Sponsor:

Description

Our initial directory guard implementation only works when we have a live consensus to find out the directory guards' IP addresses. So it's an improvement, but it's hardly a perfect solution.

We should instead remember our guards' IP addresses in our state file, and try to use our directory guards even when we don't have a consensus. This will require consideration about handling our guards being down and handling the network being down.

Child Tickets

TicketStatusOwnerSummaryComponent
#18084newUse the same fallback directory mirror to bootstrapCore Tor/Tor

Change History (3)

comment:1 Changed 3 years ago by arma

Cc: teor added
Severity: Normal

Agreed!

I wonder how this should relate to the fallbackdir design now that there is one.

Can we add the directory guards from our state file to the fallbackdir list, with higher priority than the other ones on the list?

comment:2 in reply to:  1 Changed 3 years ago by teor

Status: newneeds_information

Replying to arma:

Agreed!

I wonder how this should relate to the fallbackdir design now that there is one.

Can we add the directory guards from our state file to the fallbackdir list, with higher priority than the other ones on the list?

There is no priority in the fallback directory design, there is only weight.
But I think this is a nice way of resolving the privacy issues mentioned in #18084.

What we could do is add to the state file one or more FallbackDir lines describing our directory guards. The format is address:port orport=port id=fingerprint [ipv6=ipv6address:ipv6orport] [weight=num]. The fallbacks will have to have a DirPort, even though clients never use it (see #19129). (We're only doing this for clients, right?)

The current total fallback weight is 1009 (10*100 + 1*9), but it could go as high as ~3000 if we ever include 300 fallbacks, as in the original "20% of guards" design.

We might have 3 directory guards, or in future, we might only have 1.
So let's weight each directory guard at 10,000. Then we will only choose a fallback 10% of the time. (Or 3% of the time with 3 directory guards.)

Then, when we load the state file, we use our standard fallback parsing function to add them to the list. And our standard bootstrapping sequence will use them like any other fallbacks.

Should we do this automatically, or should their be an option to turn it off?
The existing UseDefaultFallbackDirs doesn't really cover this, so we probably need UseDirGuardsAsFallbackDirs. (This should control both the writing to the state file, and the reading from it.) This way, someone can refuse the default fallbacks, but still use their directory guards as fallbacks.

When should these fallback directory guards expire?
(When do guards in our state file expire?)
If they're too old, we should ignore them and just try the fallbacks.

comment:3 Changed 19 months ago by nickm

Keywords: needs-design guards anti-enumeration fallback intro added
Points: 5
Note: See TracTickets for help on using tickets.