How to remove directory authorities

Roger Dingledine arma at mit.edu
Fri Apr 20 20:48:53 UTC 2007


Hi folks,

In a few weeks, the moria1 and moria2 directory authorities are likely
to change IP addresses. Such a thing has never happened to Tor before,
so we don't have a precise plan for dealing.

Part 1.

  Here is the impact as I understand it of having moria1 and moria2
  disappear.

  Tor versions prior to 0.1.0.12 and prior to 0.1.1.2-alpha will have
  zero running authorities (prior to those versions, tor26 listened on
  an old IP address and it no longer listens there).

  Tor versions 0.1.1.2-alpha to 0.1.1.7-alpha will still function but
  in a degraded fashion: they will try to fetch the v1 directory and
  running-routers from moria1,moria2,tor26, and eventually they will get
  one from tor26.

  Tor versions 0.1.1.8-alpha through 0.1.1.17-rc will not function,
  because they demand a majority of authorities before the
  client will believe it.

  Tor 0.1.1.18-rc up until present ship with 5 directory authorities,
  so a majority can still exist, assuming all three remaining authorities
  are running all the time.

  Tor 0.1.0.12 and 0.1.1.2-alpha and later will have one functional hidden
  service authority (i.e. tor26), and since we don't replicate hidden
  service descriptors or round robin very well, they will experience
  significantly degraded service when trying to fetch service descriptors.

Part 2.

  What if we remove moria1 and moria2 from the default DirServers list
  now, but leave them running for a few weeks?

  Old Tors will continue to work fine as they do now.

  Versions with the new DirServers lines will then have three authorities
  (tor26, lefkada, dizum), and believe anything that two or more of them
  claim. There will be a partitioning opportunity because while the old
  dir authorities are still publishing network statuses, as the new Tors
  will potentially make different decisions than the old Tors.

  New Tors will only try to fetch hidden service descriptors from tor26,
  so if it goes down or reboots, well, they are at its mercy. Worse,
  new Tors will only publish hidden service descriptors to tor26, so old
  Tors will have difficulty fetching the descriptors. (They'll have to
  click an expected three times in order to find the right authority.)

  One compromise to resolve the interim hidden service concern would
  be to leave moria1 and moria2 in the DirServers line but *only* as
  HS authorities. That way new Tors won't believe them as far as v1
  or v2 dirs go, but new Tors will still publish/fetch hidden service
  descriptors to/from them.

Other thoughts:

I will likely put one of the morias back up on the same day as the old
ones go away, though it will have a new location. Port forwarding from
the old location might be feasible for a while; I will investigate that.
(If we don't do port forwarding, we could take this opportunity to
rotate its identity key, which is probably a good move.)

We should eventually add a lot more dir authorities, so we don't run
up against the "not a majority" edge case as easily. We've been putting
that off until we get dir voting (proposal 101) in place in 0.2.0, and I
think that's a fine plan to continue. But we may want to add a few more
to replace the ones we've lost.

We're probably going to want to put out an update to 0.1.2.x stable with
an updated (reduced) set of dir authorities, but we have never tried
removing dir authorities before, and we may encounter new bugs. We need
to do some broad testing somewhere in here. :)

It occurs to me that we could "fake" the continued existence of both dir
authorities by publishing signed network status objects and getting them
cached throughout the rest of the network. That would be quite a hack,
but it may be worth thinking harder about.

Ok. What did I miss?

--Roger



More information about the tor-dev mailing list