[tor-bugs] #26294 [Core Tor/Tor]: attacker can force intro point rotation by ddos

[Tor Bug Tracker & Wiki]

#26294: attacker can force intro point rotation by ddos
-------------------------------------------------+-------------------------
 Reporter:  arma                                 |          Owner:  asn
     Type:  defect                               |         Status:
                                                 |  assigned
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  unspecified
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-hs, tor-dos, network-team-       |  Actual Points:
  roadmap-2019-Q1Q2                              |
Parent ID:  #29999                               |         Points:  7
 Reviewer:                                       |        Sponsor:
                                                 |  Sponsor27-must
-------------------------------------------------+-------------------------

Comment (by s7r):

 I like 'a' as a short term plan as well. Proof of work solutions are non
 trivial engineering challenges, consume time and it eventually still gets
 down to the simple question how much resources/work/time/bandwidth is the
 attacker willing to give to pull this of.

 what if we add a time based lifetime for each intro point, which will be a
 random value chosen at intro point selection between n and m hours, along
 with a ALLOW_RESET_CACHE parameter which will be a random number between o
 and p and also maintain the intro requests lifetime rand(16384, 16384*2)
 which will be combined with ALLOW_RESET_CACHE, and rebuild descriptor when
 the first from these two is reached. This way we don't have to increase
 the cache but only reset it.

 For example:
 An onion service selects Z as intro point. It also chooses these random
 values and remembers them for this intro point:
 - time based lifetime = 5 hours (let's pretend n = 1; m = 6)
 - ALLOW_RESET_CACHE = 1400 (let's pretend ALLOW_RESET_CACHE = rand(100,
 7000))
 - intro requests lifetime = 20122 (rand(16384, 16384*2)

 Now, this intro point will be rotated either after 5 hours, if the onion
 service is not under attack, either after 20122 * 1400 = 28,170,800 intro
 requests.

 If high values would have been chose for ALLOW_RESET_CACHE and intro
 requests lifetime, indeed we will be getting many introduction requests
 through the same introduction point, but we still have the time based
 lifetime parameter as a safety precaution that will eventually move us
 from this introduction point.

 We can go even go more crazy about this and use the introduction point
 measured bandwidth  or consensus weight so we choose parameters based on
 how much the intro point is actually able to support in terms of
 bandwidth, so we don't end up with maintaining an introduction point that
 is hammered and can't process the requests because it's too slow.  Or find
 another way to check if the intro point is actually responding to intro
 requests. But even without these smarter computations the presented
 solution still has to be better than what we have now.

 All 3 parameters must be randomized as described, otherwise we open the
 door for easier analysis and predictability for attackers, like estimate
 with high probability when will the intro point change occur, etc.
 (outside the scope of this ticket).

 The numbers for time based lifetime and ALLOW_RESET_CACHE don't have any
 analysis behind, they are just from top of my head and only to illustrate
 and example about the logic we need to code. We need to evaluate and
 choose good parameters for these values, if we think this is a good idea.

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