doc/spec/proposals/ideas/xxx-rate-limit-exits.txt

   1
   2 1. Overview
   3
   4   We should rate limit the volume of stream creations at exits:
   5
   6 2.1. Per-circuit limits
   7
   8   If a given circuit opens more than N streams in X seconds, further
   9   stream requests over the next Y seconds should fail with the reason
  10   'resourcelimit'. Clients will automatically notice this and switch to
  11   a new circuit.
  12
  13   The goal is to limit the effects of port scans on a given exit relay,
  14   so the relay's ISP won't get hassled as much.
  15
  16   First thoughts for parameters would be N=100 streams in X=5 seconds
  17   causes 30 seconds of fails; and N=300 streams in X=30 seconds causes
  18   30 seconds of fails.
  19
  20   We could simplify by, instead of having a "for 30 seconds" parameter,
  21   just marking the circuit as forever failing new requests. (We don't want
  22   to just close the circuit because it may still have open streams on it.)
  23
  24 2.2. Per-destination limits
  25
  26   If a given circuit opens more than N1 streams in X seconds to a single
  27   IP address, or all the circuits combined open more than N2 streams,
  28   then we should fail further attempts to reach that address for a while.
  29
  30   The goal is to limit the abuse that Tor exit relays can dish out
  31   to a single target either for socket DoS or for web crawling, in
  32   the hopes of a) not triggering their automated defenses, and b) not
  33   making them upset at Tor. Hopefully these self-imposed bans will be
  34   much shorter-lived than bans or barriers put up by the websites.
  35
  36 3. Issues
  37
  38 3.1. Circuit-creation overload
  39
  40   Making clients move to new circuits more often will cause more circuit
  41   creation requests.
  42
  43 3.2. How to pick the parameters?
  44
  45   If we pick the numbers too low, then popular sites are effectively
  46   cut out of Tor. If we pick them too high, we don't do much good.
  47
  48   Worse, picking them wrong isn't easy to fix, since the deployed Tor
  49   servers will ship with a certain set of numbers.
  50
  51   We could put numbers (or "general settings") in the networkstatus
  52   consensus, and Tor exits would adapt more dynamically.
  53
  54   We could also have a local config option about how aggressive this
  55   server should be with its parameters.
  56
  57 4. Client-side limitations
  58
  59   Perhaps the clients should have built-in rate limits too, so they avoid
  60   harrassing the servers by default?
  61
  62   Tricky if we want to get Tor clients in use at large enclaves.
  63