Opened 5 years ago

Closed 10 months ago

Last modified 9 months ago

#6769 closed defect (implemented)

Relays (and bridges) don't use microdescriptors

Reported by: arma Owned by:
Priority: Medium Milestone: Tor: 0.3.0.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-relay
Cc: Actual Points:
Parent ID: Points:
Reviewer: nickm Sponsor:

Description

In we_use_microdescriptors_for_circuits() we return

  !server_mode(options) && !options->FetchUselessDescriptors;

So if you're a relay, even if you don't otherwise cache dir info, you end up fetching and using old-style descriptors rather than microdescriptors.

This decision has a minor effect on bootstrapping, where we won't build circuits until we have the full set of old-style consensus-and-descriptors, so e.g. time_to_try_getting_descriptors in main.c is dictated at that point by LAZY_DESCRIPTOR_RETRY_INTERVAL even if we don't have much of the microdesc info.

The decision has a larger effect on bridges, which fetch and use normal descriptors -- over time they will diverge even more from normal client behavior.

Child Tickets

Change History (16)

comment:1 Changed 5 years ago by nickm

I recall that I had some reason for this -- at least on the relay side -- but can't now remember what. I think there might also have been some bridge issue I was concerned about. Must research.

comment:2 Changed 5 years ago by nickm

Keywords: tor-relay added

comment:3 Changed 5 years ago by nickm

Component: Tor RelayTor

comment:4 Changed 5 years ago by arma

Seems like it would be wise to make at least bridges switch, on the 0.2.4 timeframe, since it's a partitioning concern.

comment:5 Changed 5 years ago by nickm

Simplest experimental method here would be to turn it on for a bridge or relay and see what breaks. Next simplest would be to look through what we can do by routerinfo but not by microdesc and see whether it matters for bridges/relays.

comment:6 Changed 5 years ago by nickm

Milestone: Tor: 0.2.4.x-finalTor: 0.2.5.x-final

Let's try this early in 0.2.5.

comment:7 Changed 3 years ago by nickm

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

comment:8 Changed 11 months ago by arma

Severity: Normal
Status: newneeds_review

My branch bug6769 fixes this issue.

It's built on #20269, so we should resolve that ticket first.

(I'm running it on moria5 and it seems fine. We might want to wait until 0.3.0 if we want to be extra conservative here. But I don't think we're going to find any issues.)

comment:9 Changed 11 months ago by nickm

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

We can review in 0.2.9, but my sense is that 0.3.0 is likelier to be the right point to merge.

comment:10 Changed 11 months ago by nickm

Milestone: Tor: 0.2.9.x-finalTor: 0.3.0.x-final
Reviewer: nickm
Status: needs_reviewmerge_ready

Calling this merge-ready, but for 0.3.0. I predict that there will be at least one impressively weird implication of removing the server_mode() check in we_use_microdescriptors_for_circuits().

comment:11 in reply to:  10 Changed 11 months ago by teor

Replying to nickm:

Calling this merge-ready, but for 0.3.0. I predict that there will be at least one impressively weird implication of removing the server_mode() check in we_use_microdescriptors_for_circuits().

++

I predict one weird but very minor impact:

  • some DirPort reachability checks will fail, because relays will occasionally choose a relay that exits to their DirPort for most of the world, but not their address
    • in the rare cases where this does happen, there might be a short delay to relay initial bootstrap while the relay retries another exit
    • this has less impact on bridges, as they don't need a DirPort
    • relays only do reachability checks once, just after they start, so this has no ongoing impact for running relays

comment:12 Changed 10 months ago by nickm

Resolution: implemented
Status: merge_readyclosed

Merged into master

comment:13 in reply to:  10 Changed 9 months ago by teor

Replying to nickm:

Calling this merge-ready, but for 0.3.0. I predict that there will be at least one impressively weird implication of removing the server_mode() check in we_use_microdescriptors_for_circuits().

Here's another weird impact:
FetchUselessDescriptors 1 used to imply UseMicrodescriptors 0, but it doesn't any more.
Therefore, bandwidth authorities (and other clients expecting a full consensus) have to explictly set UseMicrodescriptors 0. See #20621.

comment:14 Changed 9 months ago by teor

We're tracking the underlying bug in #20667.

comment:15 Changed 9 months ago by teor

And the trifecta:

#20839 is a subtle bug in full descriptor validation which was exposed by this change.
It mainly affects clients with FetchUselessDescriptors 1.
But it also could cause authorities and mirrors to consider all descriptors old or failed.
And it might also cause issues with caching them, working out when to discard them as old, and serving them over either the control port or DirPort.

comment:16 Changed 9 months ago by teor

Apparently, another issue that may be *resolved* by this change is that relays will try harder to update an out-of-date microdesc consensus, which is what we want. See #20909, although it is possible that other relays have stale full consensuses.

Note: See TracTickets for help on using tickets.