[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #21446 [Core Tor/Tor]: Number of Introduction Points for a (SingleOnion?) HS seems variable, or degrades with time

#21446: Number of Introduction Points for a (SingleOnion?) HS seems variable, or
degrades with time
--------------------------+------------------------------------
 Reporter:  alecmuffett   |          Owner:
     Type:  defect        |         Status:  needs_information
 Priority:  Medium        |      Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |        Version:  Tor: 0.2.9.9
 Severity:  Normal        |     Resolution:
 Keywords:  tor-hs        |  Actual Points:
Parent ID:                |         Points:
 Reviewer:                |        Sponsor:
--------------------------+------------------------------------

Comment (by teor):

 Just to clarify: are these descriptors created using OnionBalance, or
 using Tor?

 Here's what I think is happening:

 '''Issue 1: 5 minute delay before intro circuits are checked'''

 When a hidden service starts, rend_consider_services_intro_points() builds
 `HiddenServiceNumIntroductionPoints + NUM_INTRO_POINTS_EXTRA` introduction
 points.

 When `HiddenServiceNumIntroductionPoints` is between 8 and 10, this means
 that when rend_consider_services_intro_points() next runs, it checks if it
 has built more than MAX_INTRO_CIRCS_PER_PERIOD (10), and then ignores this
 service for INTRO_CIRC_RETRY_PERIOD (5 minutes). Only then will it check
 any of the circuits for failure.

 A similar issue can happen when the number of circuits opened over 5
 minutes due to retries, failures (node down), and expiries exceeds 10.
 There can be up to 3 retries if a node is in the consensus, but refusing
 connections.

 Expiry is triggered after an intro point handles
 INTRO_POINT_MIN_LIFETIME_INTRODUCTIONS (16384). If you have a million
 monthly users, you could be rotating introduction points on the order of
 every hour (they expire after 18-24 hours anyway).

 This bug and the scale of your site exacerbate the next issue:

 '''Issue 2: Intro point count can become stale'''

 Just before a hidden service descriptor is rebuilt,
 rend_consider_services_upload() checks if there are enough intro points
 using count_established_intro_points(). This uses circuit_established,
 which is set in rend_service_intro_established(), and cleared in
 rend_consider_services_intro_points(). Due to the first issue, clearing
 this flag can take up to 5 minutes.

 rend_consider_services_upload() then calls
 rend_service_update_descriptor(), which does the descriptor update. It
 uses find_intro_circuit(), which checks for *current* intro circuits
 before adding them to the descriptor, rather than using
 circuit_established.

 '''Further Questions'''

 I wonder whether your service is failing a lot of connections: that could
 make the above issues worse.

 I also wonder whether the load your service places on some intro points
 makes them start dropping connections. This would cause an increased
 number of retries.

 I wonder if we should delay between retries, rather than trying at 0, 1, 2
 seconds, then giving up.

 And I'd still like to see those logs.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21446#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs