bridge and bridge authority proposal

[Roger Dingledine]

On Thu, Nov 29, 2007 at 01:52:41PM +0100, Peter Palfrader wrote:
> > On more thought, I think we should fix this by adding a new config option
> > that all bridges should set: "BridgeRelay 1"
> > 
> > When this is set, Tor automatically acts like a dir cache, whether or
> > not DirPort is set, and it automatically answers BEGIN_DIR questions
> > whether or not DirPort is set.
> 
> Be careful about how we fetch the directory tho.  Else watching who
> fetches server descriptors at the authorities becomes a good way to find
> bridges.

Very good point.

This is an argument that Tors that have BridgeRelay enabled should use
dir caches for their updates (just like Tor clients do), and should use
the less aggressive dir update schedule (the one that Tor clients use,
not the one Tor relays use).

We could also take this opportunity to make Tors that have a DirPort
set but no ORPort set also use the caches and less aggressive schedule;
and to make Tors that have an ORPort and DirPort set but choose not to
advertise their DirPort (see decide_to_advertise_dirport() in router.c)
do that too. And Tors that haven't published their descriptor because
they haven't yet found themselves reachable. That would reduce load on
the directory authorities, especially as we grow.

But! There is a problem. See Section 1.4 of dir-spec.txt. There is a
set schedule for when authorities make the new consensus available,
when caches fetch it from the authorities, and when clients fetch it
from the caches. If bridge users are fetching from their bridges in the
same time slot that the bridges are fetching from the caches, then half
the time they'll do it in the wrong order.

So the follow-up question would be:
Can we further subdivide the interval when clients fetch the consensus,
so the "aggressive" clients fetch in the first half of that interval,
and the "subclients" fetch in the second half? Probably. As long as the
intervals are long enough.

We could also make it 3/4 and 1/4, for better fairness. But this still
raises the issue that over time we can distinguish a Tor client that
never asks in the last fraction of the interval. Does this mean that
*all* clients should fetch in only the first fraction of the interval,
to hide whether they're using this more aggressive schedule?

When we switch to directory guards, this will become less of an issue,
since the bridge will only be leaking to its directory guards whether
it's fetching the consensus on the aggressive schedule.

Should we instead have the bridge users lag behind by a whole interval?
That would imply having them use consensuses that are no longer valid.

As a last option, we could have bridges fetch a new consensus document
basically right as their current one is expiring. This would ensure that
the bridge has (with high probability, depending on clock skew) gotten
a new one, and it wouldn't cause much of a 'thundering herds' problem
so long as each bridge doesn't have that many simultaneous bridge users.

Finally, note that we're still not supporting any more levels of turtles
here besides the new one. That is, if we want to support people using
the bridge users as dir caches, we'd need to further subdivide that last
fraction of the interval, and so on for each new level of indirection.

--Roger