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

[George Kadianakis]

Matthew Finkel <matthew.finkel at 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?