Opened 11 years ago

Closed 6 years ago

Last modified 3 years ago

#572 closed enhancement (implemented)

fallback-consensus file impractical to use

Reported by: arma Owned by:
Priority: High Milestone: Tor: 0.2.4.x-final
Component: Core Tor/Tor Version: 0.2.0.9-alpha
Severity: Keywords: performance, bootstrap, prop206, tor-client, tor-dos-dirauth
Cc: arma, nickm, ln5 Actual Points:
Parent ID: #2664 Points:
Reviewer: Sponsor:

Description (last modified by Sebastian)

We can put the fallback-consensus in the tarball that results from 'make dist',
but it breaks 'make dist-rpm'.

Right now (0.2.0.12-alpha) it's commented out of src/config/Makefile.am

We need whatever voodoo it takes to let make dist-rpm do its thing too, before
we can reenable it.

[Automatically added by flyspray2trac: Operating System: All]

Child Tickets

Change History (42)

comment:1 Changed 11 years ago by nickm

The right time to put fallback-consensus in is before make dist, not after.

I think that the effects of the desired "voodoo" should be to to have make dist include it if it's present
and nonempty, and to have dist-rpm do the same.

How to achieve this voodoo does not immediately leap out at me; more effort may help.

comment:2 Changed 11 years ago by nickm

The right next steps are to try this and see what breaks and report it exactly.

comment:3 Changed 11 years ago by arma

Ok, I changed src/config/Makefile.am back in r13221. Andrew, can you tell
us exactly how make dist-rpm fails now?

I'm guessing we need to change tor.spec so it knows about this new file
and what it should do with it?

comment:4 Changed 11 years ago by arma

Here's an excerpt from Andrew's make dist-rpm:

Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/tor-0.2.0.17.alpha.dev-tor.0.rh4_6.200801220042-root
error: Installed (but unpackaged) file(s) found:

/usr/share/fallback-consensus

Looks like we don't need autoconf voodoo. We need rpm spec file voodoo.

comment:5 Changed 11 years ago by nickm

This could be as simple as adding a %{_datadir}/fallback-consensus to the %files section of the spec.
But maybe it needs to be made conditional somehow so that the rpm build doesn't fail if the fallback-consensus
is absent. That part, I don't know how to do.

Also, maybe we should be installing this into /usr/share/tor rather than into /usr/share?

comment:6 Changed 11 years ago by nickm

(Fallback consensus logic gives broken results on 0.2.0.x when it's used; postponing till after 0.2.0.x, since it
can't actually be used well here.)

comment:7 Changed 9 years ago by Sebastian

Description: modified (diff)

Do we still want to do fallback consensus things at all?

comment:8 Changed 9 years ago by nickm

Well, the goal was for new clients to hit a long-lived directory cache rather than hitting an authority per se, and it's a good idea to do that through some means. The "FallbackConsensus" means doesn't seem like it's necessarily a great one, though. Perhaps we should remove it go for something else.

comment:9 Changed 9 years ago by arma

The main remaining goal is to give Tor clients a lot more than 8 IP addresses to bootstrap into the network.

We haven't moved forward on the fallback consensus design because we would use it in place of the 8 directory authorities when trying to bootstrap, and if half the relays in it are down, we spend a lot of time timing out before we find one that works.

I think a good compromise approach would be to only fall back to the fallback consensus when the 8 known bootstrap points have failed. It will mean it takes longer for your Tor to bootstrap in the case where before it wouldn't have worked at all, but it won't slow things down if they're going to work normally.

Another approach would just be to stick a pile of IP addresses in each release, and run some metrics function over the recent directory archives to spit out the 500 addresses that seem most promising. But formatting things as a consensus seems like it should save some coding, specifying, etc.

In the distant future we could add some sort of flag like IsLikelyToStillBeInThisLocationLater (I think there's a proposal for that), but if the only use for that flag is having clients read it from disk in their fallback consensus, it's kind of weird to tell it to all clients all the time.

Yet another approach would be having directory authorities able to vote on a special consensus that includes only relays they think will be around for a while. They would vote on it and write it to disk every day or so, and we could just package the most recent version of that file in each release.

Yet yet another approach would be to have the metrics script generate something that looks like a consensus but has no signatures, and then we'd ship that and the only Tor code changes would be having Tor not worry about signatures when handling that file.

comment:10 Changed 9 years ago by nickm

Milestone: post 0.2.1.xTor: unspecified

comment:11 Changed 8 years ago by arma

Summary: fallback-consensus needs autoconf voodoofallback-consensus file impractical to use

comment:12 Changed 8 years ago by arma

Milestone: Tor: unspecifiedTor: 0.2.3.x-final
Priority: minormajor

This is something I'd be excited to see designed and deployed in the 0.2.3 timeframe.

Most of the infrastructure is in place -- we just need to not use it unless the connections to the 'main' bootstrap mechanisms fail. See also #2878 for an interacting issue.

comment:13 Changed 8 years ago by arma

Keywords: performance bootstrap added

comment:14 Changed 7 years ago by nickm

Milestone: Tor: 0.2.3.x-finalTor: unspecified

comment:15 Changed 7 years ago by Sebastian

Is this a ticket for the rpm packaging component now?

comment:16 Changed 7 years ago by arma

No. This ticket is for "design and implement a Tor feature that will try bootstrapping from the directory authorities first but if they don't work then load the fallback consensus file that got shipped with Tor and try some of the relays in it."

comment:17 Changed 7 years ago by mikeperry

Parent ID: #2664

This would technically be great to have as a DoS resistance measure in case the dirauths need to rate limit or block external network traffic, or simply crash. See #2665 and #2664 for related sibling tickets.

This ticket's solution would also solve #4483 I think, which might be possible to mark as a dup of this?

comment:18 Changed 7 years ago by mikeperry

Keywords: dos-resistance added
Milestone: Tor: unspecifiedTor: 0.2.4.x-final

comment:19 Changed 7 years ago by nickm

I'd love to see a solution here. I think that we might want to step back and think about whether fallbackconsensus is such a great idea, though. To make it work right, I think we'd need to get proposal 146 done, so that clients that try to bootstrap from the fallback consensus do so with a plausible list of routers.

An alternative approach is just to ship clients with a list of directory sources (IP:ORPort:IDDigest) and generate such list manually and/or via some metrics-based process.

Currently, an authority's IP:Port is used for about 4 things:

  1. A place for clients to fetch initial directory info.
  2. A place for servers to upload their descriptors.
  3. A place for directory caches to fetch up-to-date directory info.
  4. A place for authorities to contact one another for voting.

It seems to me that the first usage about is probably generating the lion's share of the load on authorities, followed probably by the third. Decoupling the first usage is the main way to achieve this ticket's goals, in my eyes. I have no horse in the race of whether fallbackconsensus is the right way to do that; it may well not be.

comment:20 Changed 7 years ago by nickm

I've started work on a draft branch (which *will* be rebased). The idea is to remove the fallback consensus entirely, and instead have a FallbackDir option that lists other directory mirrors to fall back to.

comment:21 Changed 7 years ago by nickm

Oh. The draft branch is called fallback_dirsource

comment:22 Changed 7 years ago by mikeperry

Quick review of dbac20ffbd608d58d89fe644397bcf8fce2e00c0 for nickm/fallback_dirsource:

  1. Is the plan to hardcode these in add_default_fallback_dir_servers(), ship a default torrc, or add support for an additional data dir file? I assume the first one?
  2. I don't actually see the new "FallbackDir" command in config.c?
  3. How sensitive to downtime are these fallback servers? It appears that the bootstrap consensus/descriptor fetching code wasn't changed for them?

Related to 3: I have not yet investigated what about the code makes it so bad that individual dirauths are unreachable for a while (#4483). Might this change make it safer to either make the timeouts much lower or schedule multiple parallel requests? That way, we can safely add lots and lots of possibly unstable dir mirrors to our list, and also tolerate dirauth failure through this change. We risk DoSing the directory servers with too many requests through bugs this way, but that's what loglines are for. For the alpha series, we could add notice-level logs to router_pick_dirserver_generic() and/or the actual connection attempt code, and maybe even the server side, too.

comment:23 Changed 7 years ago by nickm

  1. hardcode, I think.
  2. Oops. Added in .
  3. I don't understand the question. We should pick ones that don't have a lot of downtime, and are going to keep the same IP for some while? Either way, that seems like another ticket entirely, right?

comment:24 Changed 7 years ago by nickm

  1. oops. Added in .

2'. oops. oops. added in bbc4c0222ae496799

comment:25 Changed 7 years ago by mikeperry

Replying to nickm:

  1. hardcode, I think.
  2. Oops. Added in .

Great, this sounds fine then.

  1. I don't understand the question. We should pick ones that don't have a lot of downtime, and are going to keep the same IP for some while? Either way, that seems like another ticket entirely, right?

Yeah. I guess I was convolutedly asking if we could close #4483 if we get this working. It sounds like "no" right now, but see #4483 for further questions.

comment:26 Changed 7 years ago by mikeperry

Also, I think it would serve us to design this so that we can put pretty much anyone in this fallback mirror set without consequence: even if 80% of them end up being down in a year. If this means we really should solve #4483 too, perhaps #4483 should be made into a child of this ticket, instead of #2664 directly?

comment:27 Changed 7 years ago by nickm

Status: newneeds_review

Now see fallback_dirsource_v2. I am liking this branch. If we can actually populate these with something reasonable, I think it could be a good idea.

comment:28 Changed 7 years ago by mikeperry

Ok, I reviewed this, but a couple more comments/questions:

  1. Making the dirauths also fallback dir mirrors might complicate with how we want to handle #4483. I think we want to be able to say "attempt to get the consensus from D dirauths and M fallback mirrors" somehow. See comment 5 there for details. It looks like we can still the inspect dir_server_t is_authority flag to get this done, but that might be a reason for keeping them in fully disjoint lists instead? Or maybe not, since it's not the common case...
  2. Can you add an example fallback dirserver line in the comments for add_default_fallback_dir_servers()? It looks like a subset of the dirauth line syntax is acceptable, but an example would be great.

Note: I don't know enough about directory activity to properly evaluate the correct use of the fallback dir servers vs dirauths in all cases, so perhaps my review doesn't count as exhaustive. But I can also test both this and #4483 with some firewall rules to block access to all of the dirauths once both are ready.

comment:29 Changed 7 years ago by mikeperry

Keywords: dirauth-dos-resistance added; dos-resistance removed

comment:30 in reply to:  28 Changed 7 years ago by nickm

Replying to mikeperry:

Ok, I reviewed this, but a couple more comments/questions:

  1. Making the dirauths also fallback dir mirrors might complicate with how we want to handle #4483. I think we want to be able to say "attempt to get the consensus from D dirauths and M fallback mirrors" somehow. See comment 5 there for details. It looks like we can still the inspect dir_server_t is_authority flag to get this done, but that might be a reason for keeping them in fully disjoint lists instead? Or maybe not, since it's not the common case...

I think it's pretty easy to tweak the rules for what frequency trusted authorities get picked when we're looking for fallback mirrors. I think that while the design for #4483 is still in progress (and IMO maybe in need of a proposal), it'd be fine to merge this with the idea that we might need to tweak it some later.

  1. Can you add an example fallback dirserver line in the comments for add_default_fallback_dir_servers()? It looks like a subset of the dirauth line syntax is acceptable, but an example would be great.

Good idea. I'll add one once we know that we want to have fallback dir servers. :) For now, the manpage should be pretty much what you want. (I hope I added a manpage entry or wow will that last sentence sound stupid.)

comment:31 Changed 7 years ago by nickm

Keywords: needs-proposal added

comment:32 Changed 7 years ago by nickm

Keywords: tor-client added

comment:33 Changed 7 years ago by nickm

Component: Tor ClientTor

comment:34 Changed 7 years ago by ln5

Cc: ln5 added

comment:35 Changed 7 years ago by nickm

Keywords: prop206 added; needs-proposal removed

comment:36 Changed 6 years ago by nickm

Okay, are there remaining reasons I shouldn't merge fallback_dirsource_v2 ?

comment:37 Changed 6 years ago by nickm

There's a now a rebased version in fallback_dirsource_v3 that works on master.

comment:38 Changed 6 years ago by andrea

Begin code review:

How will we pick the fallback servers/how long is the list expected to be? In 5c51b3f1f0d4c394392aa6fce89bbe0960117771, for example, you're introducing router_get_fallback_dirserver_by_digest() that searches a smartlist, which was fine for the short list of trusted authorities, but in comments further up on this ticket I'm seeing numbers like 500 servers being bandied about, which makes me a bit nervous about linear-time searches. Is this going to be so infrequent an operation it isn't worth worrying about, though?

comment:39 Changed 6 years ago by andrea

I don't think I have any big concerns about this other than that one thing, but I'd like a clearer idea of how we get the default list of fallback dirservers and how long it's expected to be before signing off on this.

comment:40 Changed 6 years ago by nickm

I think about 30-50 dirservers is more reasonable than 500. I think the right way to pick them is to look at long-lived high-uptime caches whose operators we know and which have had a persistent IP for a very long time.

For the linear search, I'm happy to move it to a loopup by digestmap if need be, but I don't see anywhere that we call it in the critical path. If that's so, I'd prefer to wait until we see a profile: I'll bet you an imaginary cookie that it doesn't show up in a profile.

comment:41 Changed 6 years ago by nickm

Resolution: Noneimplemented
Status: needs_reviewclosed

Merging with Andrea's okay.

comment:42 Changed 3 years ago by mikeperry

Keywords: tor-dos-dirauth added; dirauth-dos-resistance removed

Canonicalize dirauth-dos to tor-dos-dirauth

Note: See TracTickets for help on using tickets.