Directory spec revision

[Nick Mathewson]

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
-------------- 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/20051222/c8a6296f/attachment.pgp>