How to remove directory authorities
arma at mit.edu
Fri Apr 20 20:48:53 UTC 2007
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.
Here is the impact as I understand it of having moria1 and moria2
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.
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.
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?
More information about the tor-dev