tor/doc/spec/dir-spec-v1.txt

                         Tor Protocol Specification

                              Roger Dingledine
                               Nick Mathewson

0. Preliminaries

  THIS SPECIFICATION IS OBSOLETE.

  This document specifies the Tor directory protocol as used in version
  0.1.0.x and earlier.  See dir-spec.txt for a current version.

1. Basic operation

  There is a small number of directory authorities, and a larger number of
  caches.  Client and servers know public keys for the directory authorities.
  Tor servers periodically upload self-signed "router descriptors" to the
  directory authorities.  Each authority publishes a self-signed "directory"
  (containing all the router descriptors it knows, and a statement on which
  are running) and a self-signed "running routers" document containing only
  the statement on which routers are running.

  All Tors periodically download these documents, downloading the directory
  less frequently than they do the "running routers" document.  Clients
  preferentially download from caches rather than authorities.

1.1. Document format

  Router descriptors, directories, and running-routers documents all obey the
  following lightweight extensible information format.

  The highest level object is a Document, which consists of one or more
  Items.  Every Item begins with a KeywordLine, followed by one or more
  Objects. A KeywordLine begins with a Keyword, optionally followed by
  whitespace and more non-newline characters, and ends with a newline.  A
  Keyword is a sequence of one or more characters in the set [A-Za-z0-9-].
  An Object is a block of encoded data in pseudo-Open-PGP-style
  armor. (cf. RFC 2440)

  More formally:

    Document ::= (Item | NL)+
    Item ::= KeywordLine Object*
    KeywordLine ::= Keyword NL | Keyword WS ArgumentsChar+ NL
    Keyword = KeywordChar+
    KeywordChar ::= 'A' ... 'Z' | 'a' ... 'z' | '0' ... '9' | '-'
    ArgumentChar ::= any printing ASCII character except NL.
    WS = (SP | TAB)+
    Object ::= BeginLine Base-64-encoded-data EndLine
    BeginLine ::= "-----BEGIN " Keyword "-----" NL
    EndLine ::= "-----END " Keyword "-----" NL

    The BeginLine and EndLine of an Object must use the same keyword.

  When interpreting a Document, software MUST reject any document containing a
  KeywordLine that starts with a keyword it doesn't recognize.

  The "opt" keyword is reserved for non-critical future extensions.  All
  implementations MUST ignore any item of the form "opt keyword ....." when
  they would not recognize "keyword ....."; and MUST treat "opt keyword ....."
  as synonymous with "keyword ......" when keyword is recognized.

2. Router descriptor format.

  Every router descriptor MUST start with a "router" Item; MUST end with a
  "router-signature" Item and an extra NL; and MUST contain exactly one
  instance of each of the following Items: "published" "onion-key" "link-key"
  "signing-key" "bandwidth".  Additionally, a router descriptor MAY contain
  any number of "accept", "reject", "fingerprint", "uptime", and "opt" Items.
  Other than "router" and "router-signature", the items may appear in any
  order.

  The items' formats are as follows:
   "router" nickname address ORPort SocksPort DirPort

      Indicates the beginning of a router descriptor.  "address"
      must be an IPv4 address in dotted-quad format. The last
      three numbers indicate the TCP ports at which this OR exposes
      functionality. ORPort is a port at which this OR accepts TLS
      connections for the main OR protocol; SocksPort is deprecated and
      should always be 0; and DirPort is the port at which this OR accepts
      directory-related HTTP connections.  If any port is not supported,
      the value 0 is given instead of a port number.

   "bandwidth" bandwidth-avg bandwidth-burst bandwidth-observed

      Estimated bandwidth for this router, in bytes per second.  The
      "average" bandwidth is the volume per second that the OR is willing
      to sustain over long periods; the "burst" bandwidth is the volume
      that the OR is willing to sustain in very short intervals.  The
      "observed" value is an estimate of the capacity this server can
      handle.  The server remembers the max bandwidth sustained output
      over any ten second period in the past day, and another sustained
      input.  The "observed" value is the lesser of these two numbers.

   "platform" string

      A human-readable string describing the system on which this OR is
      running.  This MAY include the operating system, and SHOULD include
      the name and version of the software implementing the Tor protocol.

   "published" YYYY-MM-DD HH:MM:SS

      The time, in GMT, when this descriptor was generated.

   "fingerprint"

      A fingerprint (a HASH_LEN-byte of asn1 encoded public key, encoded
      in hex, with a single space after every 4 characters) for this router's
      identity key. A descriptor is considered invalid (and MUST be
      rejected) if the fingerprint line does not match the public key.

      [We didn't start parsing this line until Tor 0.1.0.6-rc; it should
       be marked with "opt" until earlier versions of Tor are obsolete.]

   "hibernating" 0|1

      If the value is 1, then the Tor server was hibernating when the
      descriptor was published, and shouldn't be used to build circuits.

      [We didn't start parsing this line until Tor 0.1.0.6-rc; it should
       be marked with "opt" until earlier versions of Tor are obsolete.]

   "uptime"

      The number of seconds that this OR process has been running.

   "onion-key" NL a public key in PEM format

      This key is used to encrypt EXTEND cells for this OR.  The key MUST
      be accepted for at least XXXX hours after any new key is published in
      a subsequent descriptor.

   "signing-key" NL a public key in PEM format

      The OR's long-term identity key.

   "accept" exitpattern
   "reject" exitpattern

       These lines, in order, describe the rules that an OR follows when
       deciding whether to allow a new stream to a given address.  The
       'exitpattern' syntax is described below.

   "router-signature" NL Signature NL

       The "SIGNATURE" object contains a signature of the PKCS1-padded
       hash of the entire router descriptor, taken from the beginning of the
       "router" line, through the newline after the "router-signature" line.
       The router descriptor is invalid unless the signature is performed
       with the router's identity key.

   "contact" info NL

       Describes a way to contact the server's administrator, preferably
       including an email address and a PGP key fingerprint.

   "family" names NL

       'Names' is a whitespace-separated list of server nicknames. If two ORs
       list one another in their "family" entries, then OPs should treat them
       as a single OR for the purpose of path selection.

       For example, if node A's descriptor contains "family B", and node B's
       descriptor contains "family A", then node A and node B should never
       be used on the same circuit.

   "read-history" YYYY-MM-DD HH:MM:SS (NSEC s) NUM,NUM,NUM,NUM,NUM... NL
   "write-history" YYYY-MM-DD HH:MM:SS (NSEC s) NUM,NUM,NUM,NUM,NUM... NL

       Declare how much bandwidth the OR has used recently. Usage is divided
       into intervals of NSEC seconds.  The YYYY-MM-DD HH:MM:SS field defines
       the end of the most recent interval.  The numbers are the number of
       bytes used in the most recent intervals, ordered from oldest to newest.

       [We didn't start parsing these lines until Tor 0.1.0.6-rc; they should
        be marked with "opt" until earlier versions of Tor are obsolete.]

2.1. Nonterminals in routerdescriptors

  nickname ::= between 1 and 19 alphanumeric characters, case-insensitive.

  exitpattern ::= addrspec ":" portspec
  portspec ::= "*" | port | port "-" port
  port ::= an integer between 1 and 65535, inclusive.
  addrspec ::= "*" | ip4spec | ip6spec
  ipv4spec ::= ip4 | ip4 "/" num_ip4_bits | ip4 "/" ip4mask
  ip4 ::= an IPv4 address in dotted-quad format
  ip4mask ::= an IPv4 mask in dotted-quad format
  num_ip4_bits ::= an integer between 0 and 32
  ip6spec ::= ip6 | ip6 "/" num_ip6_bits
  ip6 ::= an IPv6 address, surrounded by square brackets.
  num_ip6_bits ::= an integer between 0 and 128

  Ports are required; if they are not included in the router
  line, they must appear in the "ports" lines.

3. Directory format

  A Directory begins with a "signed-directory" item, followed by one each of
  the following, in any order: "recommended-software", "published",
  "router-status", "dir-signing-key".  It may include any number of "opt"
  items.  After these items, a directory includes any number of router
  descriptors, and a single "directory-signature" item.

    "signed-directory"

        Indicates the start of a directory.

    "published" YYYY-MM-DD HH:MM:SS

        The time at which this directory was generated and signed, in GMT.

    "dir-signing-key"

        The key used to sign this directory; see "signing-key" for format.

    "recommended-software"  comma-separated-version-list

        A list of which versions of which implementations are currently
        believed to be secure and compatible with the network.

    "running-routers" whitespace-separated-list

        A description of which routers are currently believed to be up or
        down.  Every entry consists of an optional "!", followed by either an
        OR's nickname, or "$" followed by a hexadecimal encoding of the hash
        of an OR's identity key.  If the "!" is included, the router is
        believed not to be running; otherwise, it is believed to be running.
        If a router's nickname is given, exactly one router of that nickname
        will appear in the directory, and that router is "approved" by the
        directory server.  If a hashed identity key is given, that OR is not
        "approved".  [XXXX The 'running-routers' line is only provided for
        backward compatibility.  New code should parse 'router-status'
        instead.]

    "router-status" whitespace-separated-list

        A description of which routers are currently believed to be up or
        down, and which are verified or unverified.  Contains one entry for
        every router that the directory server knows.  Each entry is of the
        format:

              !name=$digest  [Verified router, currently not live.]
              name=$digest   [Verified router, currently live.]
              !$digest       [Unverified router, currently not live.]
          or  $digest        [Unverified router, currently live.]

        (where 'name' is the router's nickname and 'digest' is a hexadecimal
        encoding of the hash of the routers' identity key).

        When parsing this line, clients should only mark a router as
        'verified' if its nickname AND digest match the one provided.

    "directory-signature" nickname-of-dirserver NL Signature

  The signature is computed by computing the digest of the
  directory, from the characters "signed-directory", through the newline
  after "directory-signature".  This digest is then padded with PKCS.1,
  and signed with the directory server's signing key.

  If software encounters an unrecognized keyword in a single router descriptor,
  it MUST reject only that router descriptor, and continue using the
  others.  Because this mechanism is used to add 'critical' extensions to
  future versions of the router descriptor format, implementation should treat
  it as a normal occurrence and not, for example, report it to the user as an
  error.  [Versions of Tor prior to 0.1.1 did this.]

  If software encounters an unrecognized keyword in the directory header,
  it SHOULD reject the entire directory.

4. Network-status descriptor

  A "network-status" (a.k.a "running-routers") document is a truncated
  directory that contains only the current status of a list of nodes, not
  their actual descriptors.  It contains exactly one of each of the following
  entries.

     "network-status"

        Must appear first.

     "published" YYYY-MM-DD HH:MM:SS

        (see section 3 above)

     "router-status" list

        (see section 3 above)

     "directory-signature" NL signature

        (see section 3 above)

5. Behavior of a directory server

  lists nodes that are connected currently
  speaks HTTP on a socket, spits out directory on request

  Directory servers listen on a certain port (the DirPort), and speak a
  limited version of HTTP 1.0. Clients send either GET or POST commands.
  The basic interactions are:
    "%s %s HTTP/1.0\r\nContent-Length: %lu\r\nHost: %s\r\n\r\n",
      command, url, content-length, host.
    Get "/tor/" to fetch a full directory.
    Get "/tor/dir.z" to fetch a compressed full directory.
    Get "/tor/running-routers" to fetch a network-status descriptor.
    Post "/tor/" to post a server descriptor, with the body of the
      request containing the descriptor.

    "host" is used to specify the address:port of the dirserver, so
    the request can survive going through HTTP proxies.