Router handles: Nicknames vs IP:port

[Roger Dingledine]

On Thu, Sep 18, 2003 at 05:34:54PM -0400, Roger Dingledine wrote:
> I suggest that we give each router a permanent identity key. This key
> signs stuff it does, so you can be sure you're talking about the right
> guy. For example, rather than just self-signed certs for link encryption,
> the certs should also be signed by the identity key of that router. For
> our sanity, each router will also have a unique 'nickname' (eg moria or
> nrl) bound to that identity key. The nicknames will come in handy when
> we move to a restricted route topology, because the descriptor will need
> to list adjacent routers.

Ok, much of the stuff listed in this thread has been done
now. Routers generate a signed 'router descriptor' upon boot,
and publish it periodically to each dirserver. Dirservers aggregate
descriptors into signed directories, which routers and clients download
periodically. Directories include all known descriptors, and also a have
a 'running-routers' line which indicates which routers are currently up
(listing the down ones is useful so you know their link keys when they
come back up and try to connect to you, and so we can have a prayer of
making directory agreement work).

Routers now autogenerate identity/link/onion keys if they're not already
there, so the separate 'orkeygen' program is now obsolete. Routers write a
'fingerprint' file with nickname and fingerprint of identity key, so the
human can easily send it to the other humans. Each dirserver has a file
of approved fingerprints which it uses to decide if it wants to accept
new descriptors or OR connections.

In the process, we've removed all the stuff that tries to figure out
the local IP address; this should let us avoid eg the problems Bruce was
having earlier because of a misconfigured /etc/hosts file. We can remove
this stuff because we've got nicknames: rather than checking "is this
IP:port the one that we use?", we simply check "is this nickname mine?"

But I haven't decided how far we should go on referencing
routers by nickname vs by IP:port. Clearly the various internal
connection_get_by_addr_port and router_get_by_addr_port functions can
be switched over without any harm (and it will simplify the code). The
real question centers around onionskins: do we reference the next router
in the circuit by its nickname, or by IP:port?

In order to talk to the router n+1, Alice needs to know its current
onion key. We assume Alice got it from a recent router descriptor,
so we can assume Alice will know n+1's current IP:addr --  using the
nickname doesn't buy us anything in terms of flexibility. Indeed, I can
imagine letting people connect to us without regard to whether they're
in our "approved routers" file -- that file is simply a list of which
routers a dirserver will list in its directory (and thus indirectly,
which routers a user will learn about). But that doesn't mean a user
couldn't use an unapproved router if he knew he wanted to.

Is this crazytalk? Are we opening ourselves up to DoS and anonymity
issues by letting unapproved routers hook up to us? Can we actually
envision scenarios where we'd want our users using a router that most
users don't know about?

--Roger