| 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263 |
- 1. Overview
- We should rate limit the volume of stream creations at exits:
- 2.1. Per-circuit limits
- If a given circuit opens more than N streams in X seconds, further
- stream requests over the next Y seconds should fail with the reason
- 'resourcelimit'. Clients will automatically notice this and switch to
- a new circuit.
- The goal is to limit the effects of port scans on a given exit relay,
- so the relay's ISP won't get hassled as much.
- First thoughts for parameters would be N=100 streams in X=5 seconds
- causes 30 seconds of fails; and N=300 streams in X=30 seconds causes
- 30 seconds of fails.
- We could simplify by, instead of having a "for 30 seconds" parameter,
- just marking the circuit as forever failing new requests. (We don't want
- to just close the circuit because it may still have open streams on it.)
- 2.2. Per-destination limits
- If a given circuit opens more than N1 streams in X seconds to a single
- IP address, or all the circuits combined open more than N2 streams,
- then we should fail further attempts to reach that address for a while.
- The goal is to limit the abuse that Tor exit relays can dish out
- to a single target either for socket DoS or for web crawling, in
- the hopes of a) not triggering their automated defenses, and b) not
- making them upset at Tor. Hopefully these self-imposed bans will be
- much shorter-lived than bans or barriers put up by the websites.
- 3. Issues
- 3.1. Circuit-creation overload
- Making clients move to new circuits more often will cause more circuit
- creation requests.
- 3.2. How to pick the parameters?
- If we pick the numbers too low, then popular sites are effectively
- cut out of Tor. If we pick them too high, we don't do much good.
- Worse, picking them wrong isn't easy to fix, since the deployed Tor
- servers will ship with a certain set of numbers.
- We could put numbers (or "general settings") in the networkstatus
- consensus, and Tor exits would adapt more dynamically.
- We could also have a local config option about how aggressive this
- server should be with its parameters.
- 4. Client-side limitations
- Perhaps the clients should have built-in rate limits too, so they avoid
- harrassing the servers by default?
- Tricky if we want to get Tor clients in use at large enclaves.
|
