Sadly it took a few months for me to get back to prop 237 (All relays are directory servers), but now I have a revised version of the proposal and updated tor[0] and torspec[1][2] branches. These will benefit from your review. Previously, proposal 237 took advantage of the V2Dir flag because Authorities already vote on it and it accomplished 90% of what we need. But I realized that's not exactly what we want. Now the proposal introduces a new status flag, NotDir. The reasoning for this is the V2Dir flag indicates a router (is expected to) respond to directory requests, usually, because the operator configured the router's DirPort. But, in a network where nearly all relays are directory servers, why are relays with the V2Dir flag special? Basically, after this proposal is implemented nearly every relay should receive the V2Dir flag, so the NotDir flag is the complement of V2Dir. This allows the V2Dir be deprecated at some time in the future. Thoughts? Thanks, Matt [0] https://git.torproject.org/user/sysrqb/tor.git, feature12538_rebased_6 [1] https://git.torproject.org/user/sysrqb/torspec.git, prop237_update [2] feature12538
Filename: 237-directory-servers-for-all.txt
Title: All relays are directory servers
Author: Matthew Finkel
Created: 29-Jul-2014
Status: Open
Target: 0.2.7.x
Overview:
This proposal aims at simplying how users learn about the relays
in the Tor network. This is accomplished by changing the default
functionality of relays to include directory servers (also known as
directory caches), too. Currently, when an operator configures a
relay they may set it as a relay, a directory server, or both. This
proposal reduces and simplifies the options by having (nearly) all
relays cache and serve directory documents, without additional
configuration.
Motivation:
When a client's guard is not a directory server, it
must choose and query a distinct directory server. For clients who
do not disable guards this should not be necessary, but as a
consequence, this adds another position within the network for
profiling and partitioning users. With the orthogonally proposed move
of clients using a single guard, the resulting benefits could be
reduced by clients using distinct directory servers. In addition, in
the case where the client does not use guards, it is important they
have the largest possible amount of diversity in the set of directory
servers. In a network where (almost) every relay is a directory
server, the profiling and partitioning attack vector is reduced to the
guard (for clients who use them), which is already in a privileged
position for similar behavior.
Design:
Currently all relays download and cache the majority of relay
documents in any case, so the slight increased memory usage from
downloading all of them should have minimal consequences. However,
taking into account the use of resource-constrained devices as relays,
we allow operators disable this option. For this proposal there are
necessary logical changes in the client, router, and directory code.
Currently directory servers are defined as such if they advertise
having an open directory port. We can not assume this is true
anymore. To this end, we introduce a new boolean server descriptor
entry.
"dir-cache" NL
The presence of this line indicates that the relay is caching
documents and accepts tunnelled directory requests. For a relay that
implements this proposal, this line MUST be added to its descriptor
if it does not advertise a directory port, and the line MAY be added
if it does advertise an open directory port. In addition to this,
relays 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 server behavior. All relays 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.
Directory Authorities now assign a relay the NotDir flag if any
of these are true:
- it "does not support a version of the directory protocol which
is useful to clients" (version 3, at the time of writing)
- it has neither:
- an open directory port
- an open and reachable OR port
- it has an open and reachable OR port but does not advertise
"dir-cache" in its server descriptor.
In addition, we introduce a new networkstatus consensus parameter,
BelieveNotDir. This flag's default value is 0, specifying clients
should not trust the NotDir flag, or the implied meaning of it being
absent from a relay's status. Directory Authorities should set
this parameter as 1 after a sufficient number of Authorities upgrade
to a version of Tor which implements this proposal. If this parameter
is not set correctly, new, bootstrapping, clients may select a Guard
relay, without the NotDir flag, which actually is not a directory
server but the client will ask it for documents as if it were a cache.
Until this consensus parameter is 1, client should continue relying
upon the value of a relay's dir port.
Clients choose a directory by using the current criteria with the
additional criterion that a server must not have the NotDir status
flag.
Security Considerations and Implications:
Currently all directory servers are explicitly configured. This
is necessary because they must have a configured and reachable
external port. However, within Tor, this requires additional
configuration and results in a reduced number of directory servers in
the network. As a consequence, this could allow an adversary to
control a non-negligable fraction of the servers. By increasing the
number of directory servers in the network the likelihood of selecting
one that is malicious is reduced. Also, with this proposal, it will
be more likely that a client's entry guard is also a directory server
(as alluded to in Proposal 207). However, the reduced anonymity set
created when the guard does not have, or is unwilling to distribute, a
specific document still exists.
Another question that may need further consideration is whether we
trust bad directories to be good guards and exits.
Specification:
The version 3 directory protocol specification does not
currently document the use of directory guards. This spec should be
updated to mention the preferred use of directory guards during
directory requests. In addition, the new criteria for assigning the
NotDir flag should be documented.
Impact on local resources:
Should relays download documents from another cache before asking
an authority? All relays, with minor exceptions, now contact the
authorities for documents, but this will not scale well and
partitions users from relays. This latter point seems like less
of a problem than the former. A future proposal should provide a way
for a directory cache to obtain the most recent directory documents
from non-authorities, perhaps using the directory sources instead.
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 most relays, however on memory constrained relays (BeagleBone,
Raspberry Pi, and similar), every megabyte allocated to directory
documents is not available for new circuits. For this reason, a new
configuration option will be introduced within Tor for these systems,
named DirCache, which the operator may choose to set as 0, thus
disabling caching of directory documents and denying client directory
requests.
Future Considerations:
Should the DirPort be deprecated at some point in the future?
Write a proposal requiring that a relay must be a directory server
as part of the criteria for being a guard.
Notes:
Proposal 185 originally proposed a very similar idea accomplishing
the same objective. Unfortunately this was missed and this proposal
was written. After reviewing 185, some ideas were reused as
improvement in this proposal.
Transitioning to a NotDir flag from the V2Dir flag is proposed
because the consensus status flags signify something special about the
relay. At this time, a relay is given the V2Dir flag if it provides a
dirport. This is something special. In the future based on this
proposal nearly every relay caches and serves documents, so that's not
a special trait anymore. The relays that are not caches are in the
minority and should be flagged as such. In addition, an added benefit
of this flag-name is that it is directory protocol version agnostic.
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev