On Thu, Sep 18, 2003 at 05:34:54PM -0400, Roger Dingledine wrote: [snip] > 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. You didn't mention, but I assume that there will be a central CA which signs these permanent keys? It also allows you to prevent two routers from choosing the same nickname (you won't sign a key if the nickname is already taken). > In order to handle automated descriptor updating, I've generalized > our little built-in webserver to handle 'post' requests, so routers can > upload signed descriptors. > > Keeping the get/post functionality conceptually separate from the OR > functionality of the dirserver may be useful down the road. Another > alternative way to do it would be to have routers send their descriptors > over cell-based (OR) connections. This is a bit trickier, since the > dirserver won't know the link encryption key for the router; but in > theory the cert would be signed by its identity key and it could work > out. Thoughts? Seems like you've got a viable solution in the webserver thingy. I don't see any advantage to running it over OR. > In any case, now the dirserver routers.or file just needs to have > the nickname and identity key of "approved" routers. (Approved means > I've looked at them, to reduce Sybil attacks.) I see no reason why this can't be automated just prior to signing as I suggested above. Depending on how fancy you want to get, do some challenge-response thing which requires human interaction. There are a variety of webbased solutions for this: anti-OCR characters which require the human to type in would be my first suggestion, probably along with requiring a valid email address and limits on the number of OR routers allowed to be registered by a given IP or IP block. > Each router has the responsibility of getting his descriptor to every > dirserver. I can think of a number of different approaches: > * Dirserver caches unexpired descriptors on disk, so it will have them > if it restarts. The router uploads its descriptor on startup and > whenever it changes. > * The router uploads its descriptor whenever a connection to a dirserver > is established (or when the descriptor changes); so the post > automatically happens when the dirserver comes back up. Then the > dirserver never needs to use its disk except at startup. > * The router periodically downloads a directory from the dirserver > (as he does now, to learn about new routers), and if the dirserver > has an old or missing descriptor for that router, he uploads a new > one. Again, no need to use disk except at startup. > How bad is it to deal with partial writes and other descriptor corruption > issues if we keep things on disk? (eg where the dirserver has a broken > copy, but the router figures he already sent it so why send it again). Maybe someting like dynamic dns? DDNS works just like regular DNS, except that DHCP clients tell the DNS server "hey I'm aarons-laptop and I just changed my IP to x.x.x.x" The idea here being is that each OR needs only to tell one dirserver which then syncs with other dirservers on a regular basis. The advantage of this that the dirservers are self healing when corruption occurs. Dirservers delete corrupted records and re-learn them from other dirservers or when a router notices he's not listed and re-teaches the dirserver. > Which brings us to the question of directory synchronization. A single > directory is a clear security and robustness bottleneck, yet there > are security and robustness problems if clients get different network > views from different dirservers (attacks where the adversary can guess > the initiator based on what directories have been given out; and simple > robustness issues where a given router doesn't know that another router > is up). For simplicity, we assume that all the participants will agree > on who the dirservers are. I guess that means for now that we force an > upgrade when the set of dirservers changes; later we can investigate > allowing partially different dirserver sets. Seems to me you could just list the valid dirservers in the dirserver itself. Basically, as long as you know one valid dirserver, you can learn about them all. > It would seem that dirservers should periodically collect directories from > other dirservers, and merge (and log) discrepancies. Since everything is > signed, there could be a paper trail so humans can track down misbehaving > parties. > > Down the road, it would be nice for dirservers to collect signatures from > other dirservers and add them to the directory. (The stopgap alternative > would be to get users to download all the directories periodically.) To > get the directories identical requires (the easy part) a consistent > ordering of entries within a directory, and (the hard part) some way > of getting the dirservers to converge reasonably quickly on a single > directory. Sounds like you need an event based rsync. Using timeouts is not a good way to get things to occur in a quick fasion. Again, DNS does this sort thing. Actually, have you considered using DNS w/ DNS-Sec and TXT records? Yes BIND is complicated and big, but it basically does everything you need. Dirservers are nothing but NS records, OR's are A records, and the OR record would map onto a TXT record. Getting a complete list of all the OR's is a zone transfer. DNS already does everything you need (event based propagation, expiration, retries, redundancy, authentication, etc). -- Aaron Turner <aturner at pobox.com|synfin.net> http://synfin.net/ They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin All emails are PGP signed; a lack of a signature indicates a forgery.
Attachment:
pgp00000.pgp
Description: PGP signature