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

["Tor Bug Tracker & Wiki" <torproject-admin@xxxxxxxxxxxxxx>]

#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:27 rransom]:


 > Replying to [comment:26 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:
 > > > >
 >
 > Sorry.  That isn't the formula I meant to use there.
 >
 > See my bug3825c branch for a fix.


 Ok. That makes *much* more sense. Though I am still dubious about the 1.5
 factor and if that is a good usage factor.


 Another thing that might be a problem is that NUM_INTRO_POINTS_MAX is not
 being used to compute the *total* maximum number of IP, but rather the
 maximum number of IP to be rebuilt once one dies.

 This means that I could potentially overload a set of IP's and force them
 to always recreate 10 new ones and therefore lead to a very big number of
 IP (theoretically infinite).

 Is this in your intentions? I believe we should pick 60 as the maximum
 number of IP that a HS is connected to (for reasoning of this choice check
 out: #4862).


 line 1001 should read instead:

 - if (n_intro_points_wanted_now < NUM_INTRO_POINTS_DEFAULT) {
 + if ((current_intro_point_countr + n_intro_points_wanted_now) <
 NUM_INTRO_POINTS_DEFAULT) {

 Do you agree?

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/3825#comment:28>
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