[tor-dev] Adding a NotDir router status flag

[Matthew Finkel]

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
-------------- next part --------------
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 630 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150529/e92e1bc3/attachment.sig>