[tor-bugs] #3825 [Tor Hidden Services]: HS intro points overloaded with CREATE cells cause connectivity failures

[Tor Bug Tracker & Wiki]

#3825: HS intro points overloaded with CREATE cells cause connectivity failures
---------------------------------+------------------------------------------
 Reporter:  atoruser             |          Owner:  rransom           
     Type:  defect               |         Status:  needs_review      
 Priority:  major                |      Milestone:  Tor: 0.2.3.x-final
Component:  Tor Hidden Services  |        Version:  Tor: unspecified  
 Keywords:                       |         Parent:                    
   Points:                       |   Actualpoints:                    
---------------------------------+------------------------------------------

Comment(by hellais):

 Taking a look at commit dae000735e75b178cdf27000d316f6504bf61373 I am a
 bit unsure about the reasoning behind the number of intro points to open
 once it realizes that one should be teared down.

 Let me try and explain how I understand this new Tor behavior:

 n is the original number of IP

 If a Tor HS detects that a intro-point circuit is being overloaded by
 lot's of CREATE cells it will close that intro point.

 At this point it will have n -1 IP active and I need to determine the x
 that I should add the n -1 to have the new number of intro points.

 constants:
 IP_MIN_LT = minimum lifetime in seconds of a IP (18 hours = 18*60*60)
 IP_CON_LT = number of INTRODUCTION2 connections before the IP should dei
 (16384)

 variables
 time_since_publishing = time in seconds since the HS has been published to
 the DA

 x =
 ((time_since_publishing/IP_MIN_LT)*(accepted_ip_connection)/(IP_CON_LT))*1.5

 I have a bit of doubts of this choice since the two members of this
 function converge do 4/3 and 1 therefore x -> 2. Since you are assigning a
 double to int:

 {{{
      n_intro_points_wanted_to_replace_this_one =
        fractional_n_intro_points_wanted_to_replace_this_one;
 }}}

 This will always be equal to one, so there will never be more than one new
 hidden service.

 Another funny thing is that you are checking if
 (fractional_n_intro_points_wanted_to_replace_this_one < 0). When will this
 occur? In the previous formula you are dealing with integers that are
 strictly greater than 0 when will this ever happen?
 It is not a bug, but it is strange to do such a thing.

 I will split this issue into a few new tickets with some proposed
 solutions and better numbers for INTRO_POINT_LIFETIME_INTRODUCTIONS,
 INTRO_POINT_LIFETIME_MIN_SECONDS, INTRO_POINT_LIFETIME_MAX_SECONDS and
 NUM_INTRO_POINTS_MAX.

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