Relays (and bridges) don't use microdescriptors

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.

changed milestone to %Tor: 0.3.0.x-final

added component::core tor/tor milestone::Tor: 0.3.0.x-final priority::medium resolution::implemented reviewer::nickm severity::normal status::closed tor-relay type::defect labels

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.

Trac:
Keywords: N/A deleted, tor-relay added

Trac:
Component: Tor Relay to Tor

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

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.

Let's try this early in 0.2.5.

Trac:
Milestone: Tor: 0.2.4.x-final to Tor: 0.2.5.x-final

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

My branch bug6769 fixes this issue.

It's built on #20269 (moved), 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.)

Trac:
Reviewer: N/A to N/A
Severity: N/A to Normal
Sponsor: N/A to N/A
Status: new to needs_review

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

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

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

Trac:
Milestone: Tor: 0.2.9.x-final to Tor: 0.3.0.x-final
Status: needs_review to merge_ready
Reviewer: N/A to nickm

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

Merged into master

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

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 (moved).

We're tracking the underlying bug in #20667 (moved).

And the trifecta:

#20839 (moved) 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.

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 (moved), although it is possible that other relays have stale full consensuses.

closed

mentioned in issue #20269 (moved)