Hello, all! If you're following CVS commits, you might have noticed that the Tor directory architecture is changing a lot these days. Here's the summary. THE OLD THING: ORs upload their descriptors to 3 directory authorities. Authorities check who is up and who isn't, and generate two documents: a "directory" that includes all of the descriptors, and a "running routers list" that describes who is up and who is down. Directory caches (any OR with its dirport set) download and cache these documents. Clients download both, periodically. They download the directory infrequently (because it's big) and the running routers list frequently (so they can know who is up). They believe the most recent directory and the most recent running routers list they have. WHY THE OLD THING MUST GO: 1. The bandwidth requirements are obnoxious. The directory is currently around half a MB, compressed, and clients download it about once every 40 minutes. 2. Each directory authority is an independent trust bottleneck. Since clients just believe the most recent directory info they have, any directory authority can lie, and 1/3 of the clients will believe it at any point of time. THE NEW THING: See http://tor.eff.org/cvs/tor/doc/dir-spec.txt Please read and analyze: this is important. I'm starting to implement it, so the best time to get it right is now. WHY THE NEW THING IS AN IMPROVEMENT: Clients only download descriptors when they have changed. This saves bandwidth. Clients only believe information attested to by a majority of directory authorities. This prevents a single authority from constituting a trust bottleneck. WHAT THE NEW THING DOES NOT SOLVE: 1. Our current architecture still requires every client to know about every server to avoid knowledge partitioning attacks. This isn't so bad now, but it will probably suck in the future as the number of servers grows large. 2. We ameliorate, but don't solve network partitioning attacks that can arise when the clients disagree about the authorities. 3. Client knowledge can diverge depending on when they downloaded what, if information changes fast enough. We could solve this by requiring all clients to download in lockstep, but this would hammer the caches pretty heavily. Somebody should analyze this. yrs, -- Nick Mathewson
Attachment:
pgpN9qMjLIHqJ.pgp
Description: PGP signature