Re: [tor-dev] [DRAFT] Proposal: All Routers are Directory Servers

Matthew Finkel matthew.finkel@gmail.com writes:

Hi All,

Below is a draft proposal for making all relays also be directory servers (by default). It's almost ready for a number, but it can use some feedback beforehand (give or take a few days).

Tonight I also found that Nick actually created a similar proposal a few moons ago (Proposal 185: Directory caches without DirPort). This new proposal may benefit from superseding that one, but I recommend they remain distinct proposals, for now.

In general I'm not tied to any of the proposed names, so suggestions are welcome.

Thanks!

Thanks for the proposal! Some clarifying questions below:

=======================================================================

Filename: directory-servers-for-all.txt Title: All routers are directory servers Author: Matthew Finkel Created: 29-Jul-2014 Status: Draft Target: 0.2.6.x

Overview:

(In practice we refer to the servers that mirror directory documents

as directory servers, directory mirrors, and directory caches. Sometimes we also shorten directory to dir. This proposal attempts to consistently use directory server to refer to this functionality. We also typically use the term router and relay interchangably. This proposal uses (onion) router.)

Starting with a parenthesis might be considered a bit dry. I would maybe move this to a "terminology" section or something.

<snip>

Currently directory servers are defined as such if they advertise

having an open directory port. We can no longer assume this is true. To this end, we will introduce a new server descriptor line.

"tunnelled-dir-server"

I guess that's a '"tunneled-dir-server" NL' following the format of dir-spec.txt.

The presence of this line indicates that the router accepts

tunnelled directory requests. For a router that implements this proposal, this line MUST be added to its descriptor if it does not advertise a directory port, and MAY be added if it also advertises an open directory port. In addition to this, routers will now download and cache all descriptors and documents listed in the consensus, regardless of whether they are deemed useful or usable, exactly like the current directory servers. All routers will also accept directory requests when they are tunnelled over a connection established with a BEGIN_DIR cell, the same way these connections are already accepted by bridges and directory servers with an open DirPort.

So, IIUC, from now on, just having an ORPort in your torrc means that you will be replying to BEGIN_DIR queries and advertising tunneled-dir-server.

This makes sense to me.

Directory Authorities will now assign the V2Dir flag to a server if

it supports a version of the directory protocol which is useful to clients and it has at least an open directory port or it has an open OR port and advertises "tunnelled-dir-server" in its server descriptor.

Clients choose a directory by using the current criteria with the

additional qualification 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. This will minimize the increased number of clients that prefer begindir over direct connections and thus also minimizes the additional overhead on the network from clients establishing OR connections for directory requests.

Does BEGIN_DIR actually impose additional overhead to the network?

It was my *impression* that BEGIN_DIR happens over a direct connection (a "one-hop circuit"). Is that false?