[tor-bugs] #4581 [Tor]: Dir auths should defend themselves from too many begindir requests per address

[Tor Bug Tracker & Wiki]

#4581: Dir auths should defend themselves from too many begindir requests per
address
-------------------------+-------------------------------------------------
     Reporter:  arma     |      Owner:  andrea
         Type:  defect   |     Status:  assigned
     Priority:  major    |  Milestone:  Tor: 0.2.7.x-final
    Component:  Tor      |    Version:  Tor: 0.2.7
   Resolution:           |   Keywords:  maybe-proposal, tor-auth,
Actual Points:           |  027-triaged-1-in, SponsorU
       Points:  medium   |  Parent ID:
-------------------------+-------------------------------------------------

Comment (by andrea):

 Some notes on this, including testing strategies.  We'll need a modified
 Tor client with the ability to originate directory connections by an
 arbitrary method to an arbitrary IP/port to perform some of the DoSy
 client behaviors this ticket envisions filtering for.

 {{{
 To poke dirauths for testing:

  - We'll need an interface to create/teardown directory connections on
 demand
    to test any filtering we build on the dirauth side; this is going to
 require
    most of Tor as a subset, so implement by modified Tor client with extra
    control port commands to create/close dirconns.

  - We originate all directory connections through
 directory_initiate_command()/
    directory_initiate_command_rend() path in directory.c.  Modify this to
 accept
    an additional dir_connection_t ** param to pass out the newly created
    connection, and to check if the resource/payload/payload_len params are
 all
    NULL/zero, and avoid calling directory_send_command() if so.

    - Alternately, copy and edit down this function to present a more
 flexible/
      abusable interface for testing purposes (e.g., eliminate the
 automatic
      dirport vs. orport selection and allow manual specification of any
 ip/port
      for any connection method).

  - There are no tests or asserts on resource/payload/payload_len in
    directory_initiate_command_rend(); how does directory_send_command()
    behave if they are NULL/zero?

  - The method directory_initiate_command_rend() uses to set up the
 connection
    is controlled by use_begindir =
 directory_command_should_use_begindir(options,
    _addr, or_port, router_purpose, indirection); and anonymized_connection
 =
    dirind_is_anon(indirection);

    - if !anonymized_connection && !use_begindir, we try
 connection_connect()
    - otherwise, the anonymized_connection and use_begindir flags control
 the
      args to connection_ap_make_link(); use_begindir is passed directly,
 and
      anonymized_connection() controls whether iso_flags is ISO_STREAM or
      ISO_SESSIONGRP.  The conn->dirconn_direct flag is also passed to
      connection_make_ap_link(), and is set to !anonymized_connection.

   - The choice of isolation on the basis of how the connection is tunneled
     will make it impossible to perform some of the DoS attempts we're
 trying
     to filter for using this function; argues in favor of cloning and
 editing
     down for a testing interface.

 To detect weird/aggressive/DoSy dirauth client behavior:

  - Can we *always* declare receiving an extra begindir cell on a tunneled
    connection a weird behavior we should filter? (from directory.c)

 1013     /* Anonymized tunneled connections can never share a circuit.
 1014      * One-hop directory connections can share circuits with each
 other
 1015      * but nothing else. */
 1016     int iso_flags = anonymized_connection ? ISO_STREAM :
 ISO_SESSIONGRP;

   - But we can only classify connections as tunneled or not-tunneled on
 the
     basis of whether the previous hop is a relay in the consensus, and if
 a
     relay also acts as a client and originated one-hop connections, we
 will
     always have some false positives.
 }}}

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/4581#comment:15>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online