[tor-dev] Proposal: All Relays are Directory Servers

Matthew Finkel matthew.finkel at gmail.com
Tue Aug 19 01:32:25 UTC 2014

On Mon, Aug 18, 2014 at 02:17:28PM -0400, Nick Mathewson wrote:
> On Wed, Aug 13, 2014 at 11:53 AM, Matthew Finkel
> <matthew.finkel at gmail.com> wrote:
> > Hi All,
> >
> > Below is the proposal for #12538 [0], with some changes after George's
> > review and some other revisions.
> >
> > Feedback welcome!
> >
> > Thanks,
> > Matt
> >
> >
> > [0] https://trac.torproject.org/projects/tor/ticket/12538
> >
> Thanks! This is now proposal 237. Any revisions should be sent in as
> patches against the one in the torspec repository.


> > Filename: xxx-directory-servers-for-all.txt
> > Title: All relays are directory servers
> > Author: Matthew Finkel
> > Created: 29-Jul-2014
> > Status:
> > Target: 0.2.6.x
> >
> > Overview:
> >
> >     This proposal aims at removing part of the distinction between the
> > relay and the directory server. Currently operators have the options
> > of being one of: a relay, a directory server, or both.  With the
> > acceptance of this proposal the options will be simplified to being
> > either only a directory server or a combined relay and directory
> > server. All relays will serve directory requests.
> FWIW, we don't support being only a directory server right now, do we?

Nope, you're right. Bad assumption.


>  [...]
> >     Clients choose a directory by using the current criteria with the
> > additional criterion that a server only needs the V2Dir status flag
> > instead of requiring an open DirPort. When the client chooses which
> > directory server it will query, it checks if the server has an open
> > directory port and uses begindir if it does not have one. Directory
> > servers should not be able to determine which version of Tor the client
> > is using (or a lower-bound on the version), if possible. Continuing to
> > prefer direct directory connections over begin may help mitigate a
> > potential partitioning attack.
> Well, the partitioning attack is going to be rendered possible here by
> the fact that an 0.2.5 client won't send a RELAY_BEGIN_DIR cell to a
> node with DirPort=0, V2Dir=1, but an 0.2.6 client might.
> I think this is not too bad, though: alpha users are typically visible
> as alpha users for other reasons as well, and when everybody upgrades
> to the next stable Tor version, they usually do so en masse.

Right. Assuming most users currently use directory guards, they will
continue to use their current set and their behavior will not
change (because their current guards already have an open
DirPort). As a consequence, mitigating this potential partitioning
attack only applies to the current set of directory servers, because,
as you said, any new clients that choose a directory server which
has DirPort=0, V2Dir=1 must be a client running at least 0.2.6.

> > Impact on local resources:
> >
> >     Should relays attempt to download documents from another mirror
> > before asking an authority? All relays will now prefer contacting the
> > authorities first, but this will not scale well and will partition users
> > from relays.
> Partitioning users from relays is inevitable.  If you're not sure
> whether somebody is a relay, just send them a CREATE_FAST cell and see
> what they do.

True. I was actually more worried about the additional load on the

> >     If all relays become directory servers, they will choose to
> > download all documents, regardless of whether they are useful, in case
> > another client does want them. This will have very little impact on the
> > "typical" relay, however on memory constrained relays (BeagleBone,
> > Raspberry Pi, and similar), every megabyte allocated to directory
> > documents is not available for new circuits. Should we add a config
> > option that allows operators to disable being a directory server?  Is
> > it more worthwhile for them to serve these documents or to relay cells?
> Maybe only relays with a threshold of bandwidth or memory should be
> guards?  Dunno.

Possible. I think this is something that was being looked at for the
single guard proposal. I guess we can wait and see what is decided


More information about the tor-dev mailing list