Matthew Finkel <[email protected]> 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? _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
