Re: Simplifying directory authority administration

[Roger Dingledine <arma@xxxxxxx>]

On Sat, Apr 21, 2007 at 01:48:58PM -0400, nickm@xxxxxxxx wrote:
> Added: tor/trunk/doc/spec/proposals/113-fast-authority-interface.txt
> ===================================================================
> --- tor/trunk/doc/spec/proposals/113-fast-authority-interface.txt	2007-04-21 17:48:45 UTC (rev 9999)
> +++ tor/trunk/doc/spec/proposals/113-fast-authority-interface.txt	2007-04-21 17:48:50 UTC (rev 10000)
> @@ -0,0 +1,80 @@
> +Filename: 113-fast-authority-interface.txt
> +Title: Simplifying directory authority administration
> +Version: $Revision: 12412 $
> +Last-Modified: $Date: 2007-04-16T19:11:29.511998Z $
> +Author: Nick Mathewson
> +Created:
> +Status: Open
> +
> +Overview
> +
> +The problem:
> +
> +  Administering a directory authority is a pain: you need to go through
> +  emails and manually add new nodes as "named".  When bad things come up,
> +  you need to mark nodes (or whole regions) as invalid, badexit, etc.
> +
> +  This means that mostly, authority admins don't: only 2/4 current authority
> +  admins actually bind names or list bad exits, and those two have often
> +  complained about how annoying it is to do so.
> +
> +  Worse, name binding is a common path, but it's a pain in the neck: nobody
> +  has done it for a couple of months.

A related problem is that people register nicknames and then vanish,
and a year or two later somebody picks the same nickname and is locked
out of the network -- in a way that isn't really intuitive to the poor
server operator.

A deeper problem is really that naming isn't very useful anymore. Once
upon a time we imagined that people would refer to servers by nickname,
and an unamed server was not recommended for use. Requiring an email was
in large part a Sybil deterrent. Then we scaled past the point where
that was practical -- so we started letting unnamed servers be used in
ordinary situations, and even let multiple servers with the same nickname
join the network. We migrated to referring to servers by identity key,
because that's the unique identifier now.

So part of the reason that name binding isn't actively done anymore is
that it doesn't (seem to) matter enough.

Indeed, the main reason for answering name registration mail is not to
get the name on record -- it's to make the server operator feel welcome,
and to help catch misconfigurations and confusions early.

While we're listing problems with the Named flag, its utility is also
limited because we're missing an Unnamed flag: if only one directory
authority has a binding for a given nickname, and the named server hasn't
published a descriptor recently, then some other server can arrive in
the meantime with the same nickname and it will be listed by the other
n-1 dir authorities. (But the naive implementation of this lets a single
dir authority cut out any server(s) it chooses from the network; looks
like more research remains here.)

We could also imagine a client-side Naming strategy, where clients bind
keys to nicknames the first time they reference them, and then store
the binding locally.

But in the interest of not expanding this proposal to include all the
issues with name binding, I'm going to try to focus on the easiest and
simplest to deploy that will solve a few of the immediate problems.

> +Digression: who knows what?
> +
> +  It's trivial for Tor to automatically keep track of all of the
> +  following information about a server:
> +    name, fingerprint, IP, last-seen time, first-seen time, declared
> +    contact.
> +
> +  All we need to have the administrator set is:
> +    - Is this name/fingerprint pair bound?
> +    - Is this fingerprint/IP a bad exit?
> +    - Is this fingerprint/IP an invalid node?
> +    - Is this fingerprint/IP to be rejected?
> +
> +  The workflow for authority admins has two parts:
> +    - Periodically, go through tor-ops and add new names.  This doesn't
> +      need to be done urgently.
> +    - Less often, mark badly behaved serves as badly behaved.  This is more
> +      urgent.
> +
> +Possible solution #1: Web-interface for name binding.
> +
> +  Deprecate use of the tor-ops mailing list; instead, have operators go to a
> +  webform and enter their server info.  This would put the information in a
> +  standardized format, thus allowing quick, nearly-automated approval and
> +  reply.

We could do this. But if the goal of the tor-ops mail is to give them a
human contact, it's not effective. And if the goal is to write down the
details, we already pointed out that all of this data can be automatedly
gathered.

So is there some "now I want to be registered" step that it's useful
for a human to go through, and actually has much impact on the network?

The only reason I can see for implementing solution 1 is as a stopgap
solution -- if the other solutions aren't worth the trouble to implement
them.

> +Possible solution #2: Self-binding names.
> +
> +  Peter Palfrader has proposed that names be assigned automatically to nodes
> +  that have been up and running and valid for a while.

This seems to be the closest approximation of what we (used to) do when
naming: when we find a fingerprint in our mail, make sure that the server
is actually running, and then blindly add it to the approved-routers file.

We could also imagine an auto expiry, where a server that hasn't been
seen in a few months loses its Named status.

(Which leads to the original question of what Named is actually for.)

> +Possible solution #3: Self-maintaining approved-routers file
> +
> +  Mixminion alpha has a neat feature where whenever a new server is seen,
> +  a stub line gets added to a configuration file.  For Tor, it could look
> +  something like this:
> +
> +    ## First seen with this key on 2007-04-21 13:13:14
> +    ## Stayed up for at least 12 hours on IP 192.168.10.10
> +    #RouterName AAAABBBBCCCCDDDDEFEF
> +
> +  (Note that the implementation needs to parse commented lines to make sure
> +  that it doesn't add duplicates, but that's not so hard.)
> +
> +  To add a router as named, administrators would only need to uncomment the
> +  entry.  This automatically maintained file could be kept separately from a
> +  manually maintained one.
> +
> +  This could be combined with solution #2, such that Tor would do the hard
> +  work of uncommenting entries for routers that should get Named, but
> +  operators could override its decisions.

Actually, I think this is what weasel had in mind in suggestion #2.

While we're at it, I note that keeping the two files separate lets us
expire the Namedness on the servers that got automatically named without
expiring the ones that got manually named.

> +Possible solution #4: A separate mailing list for authority operators.
> +
> +  Right now, the tor-ops list is very high volume.  There should be another
> +  list that's only for dealing with problems that need prompt action, like
> +  marking a router as !badexit.

I think this covers a separate issue. We could do this, but in practice
we've done fine finding each other on IRC or sending mail directly in
the few cases that fails.

--Roger