[tor-bugs] #15463 [Tor]: Tor deals poorly with a very large number of incoming connection requests.

[Tor Bug Tracker & Wiki]

#15463: Tor deals poorly with a very large number of incoming connection requests.
--------------------------+--------------------------------------
     Reporter:  alberto   |      Owner:
         Type:  defect    |     Status:  new
     Priority:  critical  |  Milestone:  Tor: 0.2.7.x-final
    Component:  Tor       |    Version:  Tor: 0.2.5.11
   Resolution:            |   Keywords:  tor-hs SponsorR SponsorZ
Actual Points:            |  Parent ID:
       Points:            |
--------------------------+--------------------------------------

Comment (by asn):

 I managed to reproduce this and do a few tests with short-term solutions:
 - Decreasing `MAX_REND_FAILURES` didn't really help.
 - Completely disabling relaunches and killing rend circuit on first
 timeout did not help either.
 - Hard-coding the second hop (with my `sticky_mids` branch) in an attempt
 to reduce path selection CPU time did not really help either.

 Another thought. Can we figure out whether such volume of `INTRODUCE1`
 cells is possible without #15515? If the attacker is not using #15515, and
 the IP can handle that many circuits, why can't our hidden service also
 handle them? If the attacker is using #15515, we should really fix it.
 A small info that might point towards #15515, is that on the first logs,
 the HS had 3 IPs. The first IP sent us 11k `INTRODUCE2` cells, the second
 3.5k `INTRODUCE2` cells, and the last only 200. Similarly, on the last
 logs the first IP sent 6k `INTRODUCE2` cells, the second 3k `INTRODUCE2`
 cells and the last about 50. What I'm trying to say here friends is that
 the distribution is not uniform as would be expected by a normal client,
 and also the two distributions are quite similar.

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