Plan for proposal 104 (was: New system for modifying Tor protocol)

[Nick Mathewson]

On Fri, Mar 09, 2007 at 06:10:20PM -0500, Roger Dingledine wrote:
> On Tue, Mar 06, 2007 at 05:06:50PM -0500, Nick Mathewson wrote:
> > Future big changes to Tor will follow this process, unless Roger and I
> > screw up (which is, alas, always a possibility).  Discussion of
> > proposals should take place on this list.
> 
> Time for discussion on proposal 104, which will hopefully be an easy
> enough proposal to get us used to this 'discussing proposals' business. :)
> 
> For those of you who haven't already read it, go look at
> http://tor.eff.org/svn/trunk/doc/spec/proposals/104-short-descriptors.txt
> 
> Solution 4 seems like a nice plan: in many cases, the external services
> that use read-history and write-history are directory authorities
> themselves, so they just use their local opinion.

To elaborate: solution 4 is the one where we move bandwidth and
(later) other expensive, unused fields into a signed "extra info"
document that goes to the directory authorities and that is wholly
unlinked to the regular router descriptors.

> I think we should go with the long/short descriptor plan, along
> with solution 4. We don't want to just upload a bandwidth message,
> because that involves new data structures for every new piece of
> information we decide to upload. I suspect we'll realize once this
> is deployed that there is other info we want to put in the long
> descriptors.
> 
[...]
> However, we may still need some basic reconciling algorithms between
> authorities -- otherwise, if a router uploads to four authorities
> and fails to reach the fifth, then that fifth will never have the new
> descriptor. This will mean that the best strategy for external tools
> is to fetch full concatenated-style long-descriptor lists from every
> single authority, and merge them locally. So each authority should
> periodically fetch the list from the others and take the new ones.

If each authority fetches from the others and takes new ones, that
should be sufficient to ensure that tools only need to fetch from a
single authority.  Tools fetching from all authorities instead of one
would probably hurt bw worse than authorities keeping synchronized.

> Is that it? Are there other pitfalls I'm missing? Are there better
> options?

The remaining issue in my mind is: if later we decide that we need to
keep "extra info" documents verifiably reconciled among authorities,
will we then wish that we had done more now to make it possible to do
so in the future.  In particular, upgrading authorities is easy, but
upgrading all the servers on the network isn't.  What server-side work
would we need to do to make extra-info documents reconcilable, and how
much of it (if any) needs to happen now?

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/20070311/ba7376ae/attachment.pgp>