[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):

 Replying to [comment:25 rransom]:
 > Replying to [comment:24 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:
 >
 > What does “converge” mean?
 >

 Correct me if I am wrong, but from what I understand time_since_publishing
 -> INTRO_POINT_LIFETIME_MAX_SECONDS (24*3600) and accepted_ip_connection
 -> INTRO_POINT_LIFETIME_INTRODUCTIONS.

 Is there any circumstance when accepted_ip_connection is >>
 INTRO_POINT_LIFETIME_INTRODUCTIONS AND time_since_publishing >>
 INTRO_POINT_LIFETIME_MAX_SECONDS?

 > >
 > {{{
 >      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.
 >
 > No.
 >

 If my argument above is incorrect then maybe it might also be greater than
 1, but it would still not be greater than 2. Is there a case in which this
 would not happen?


 > > 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?
 >
 > The difference between the current time and the time at which an
 introduction point was first published may be negative.

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