[tor-bugs] #19984 [Core Tor/Tor]: Use a better set of comparison/evaluation functions for deciding which connections to kill when OOS

[Tor Bug Tracker & Wiki]

#19984: Use a better set of comparison/evaluation functions for deciding which
connections to kill when OOS
--------------------------+------------------------------------
 Reporter:  nickm         |          Owner:  nickm
     Type:  defect        |         Status:  accepted
 Priority:  High          |      Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |        Version:
 Severity:  Normal        |     Resolution:
 Keywords:  dos, sockets  |  Actual Points:
Parent ID:                |         Points:  2
 Reviewer:                |        Sponsor:  SponsorV-can
--------------------------+------------------------------------

Comment (by Hello71):

 in other words, it's impossible to, using netblocks only, distinguish
 between "real" clients behind some mobile network's carrier-grade NAT and
 a bunch of regular clients on a VPS somewhere.

 hm... upon further consideration though, perhaps it would be possible to
 use a memory-hard proof of work algorithm here. even phones under $100
 have at least 2 GB of RAM, so completing an occasional 1 GB POW should
 only momentarily slow the device. should be easy on battery life too,
 unlike a CPU POW. I did a quick calculation and an attacker would need s =
 cfn, where s is the required server RAM, c is the challenge difficulty, f
 is the frequency, and n is the number of connections to be held, and if c
 = 1 GB * 3 sec, f = 1/10 min, n = 200, then s = 1 GB, or around $5/month
 per 200 connections, which seems sufficiently expensive to deter this
 particular attack. however, there are a number of downsides to this plan.
 not only does it require additional protocol design (time which could be
 spent doing something else, like IPv6 support), I hear the iOS Tor people
 are limited to 15 MB, so even if the device has 10 GB of RAM that won't
 help. I figure "you must reopen the Tor app every ten minutes to maintain
 your connection" is not a good solution.

 hm... perhaps we could use both: clients that require long-running
 connections for things like IRC must submit proofs of work (either CPU or
 memory), and iOS clients just have to live with occasionally re-
 establishing their connections if the relay is under DoS.

 regardless, in the short to medium term, we should probably implement the
 bandwidth method. this latest surge in fake clients has noticeably
 increased number of "users": https://metrics.torproject.org/userstats-
 relay-country.html?start=2017-12-01&end=2017-12-15&country=all&events=on.
 fortunately, performance has not yet been seriously affected, but it is
 plausible that they will get more servers online and the curve will
 continue going up.

 in terms of implementation, is it correct that right now, only OR
 connections count recent traffic?

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