How to remove directory authorities

Fri Apr 20 21:26:59 UTC 2007

On Fri, Apr 20, 2007 at 04:48:53PM -0400, Roger Dingledine wrote:
> 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).

This is only a problem when these tor versions try to go straight to
the authorities for a copy of their directory information.  If they go
to a cache, the cache can give them an up-to-date directory.  So long
as the up-to-date directory is signed with an identity key they
recognize, they will accept it.  The only times these versions will
try to go straight to an authority are: if they are servers, or if
they are clients starting up again after being down for a long time.

As far as I can tell from my directory cache, there are no running
servers using a version of Tor earlier than 0.1.0.15.  That's probably
good; these versions are very obsolete for other reasons; I wouldn't
worry too much about them.

(There is one router, "mysosecretname", running 0.1.0.15.  All others
are 0.1.0.16 or later.)

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

Again, this only matters when trying to get info straight from the
authorities: caches running these versions will fumble around until
they eventually get a v1 directory from tor26.  Clients running these
versions will just go to a cache, which will serve them a v1 directory.

(My cache has no routers running these versions, so no caches should
be affected.)

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

Actually, I think they will be fine, assuming that moria1 and moria2
keep the same keys as before.

Clients will fetch networkstatus info _by identity key digest_ from
caches.  (They'll go to an authority if they don't know any caches,
and eventually they'll find tor26.)  Caches will go to an authority
and request "all network status documents" (eventually finding Tor26).
Assuming tor26 knows where to find moria1 and moria2, the network
doesn't fall oever This will degrade performance as the clients/caches
look for an authority/cache that has the info they need, but not too
badly.

>   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?

I'll suggest an alternative below; as noted above, it's probably
important to keep at least one of moria1 and moria2 running with the
same key, if not on the same IP.

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

I think the right thing to do is to use new signing keys when we
transition to directory voting, and continue using the old identity
keys for v1 and v2 directories.  This way, we don't gratuitously break
old software, but we get to move beyond the key management sins of the
past.  We can also change the _set_ of authorities when we transition
to dir-voting.

Remember, nothing in proposal 101 requires that the keys used to sign
votes and consensus directories have anything at all to do with the
keys used to sign v1 directories and v2 networkstatus objects.

That would also be a fine time to consider proposal 103 ("multilevel
keys"), so that we can have a rarely used identity key that is kept
encrypted and used only to certify a frequently used signing key.

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

See above: so long as the authorities know where moria1 and moria2
are, they can fetch their signed network-status documents and serve
them to old caches.  (Caches, remember, go to a randomly chosen
authority and say "give me all networkstatus documents.")  All caches
will happily serve their signed network-status documents to clients.

>
> Ok. What did I miss?

We should switch to DNS, or to fallback-to-DNS, for directory
authority addresses, so we don't need to do this ever again. :)

peace,
-- 
Nick Mathewson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 652 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20070420/4739be16/attachment.pgp>