Changes between Initial Version and Version 1 of Ticket #16052


Ignore:
Timestamp:
May 16, 2015, 3:02:38 PM (4 years ago)
Author:
yawning
Comment:

Personally I'm in favor of "a" since it's the easiest to implement, and if it's tunable, people can choose the right number for their HS. Something that's more automagic like "b" would be nicer, but the implementation gets more complicated.

As far as I can tell the impact of this is only a DoS, either through totally bogging the application/tor down, or by causing exhaustion of file descriptors/unused ports on the loopback interface (which is why I suggest "c", though realistically I suspect that the app or tor will die before most systems manage to exhaust the available port space).

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #16052

    • Property Cc yawning added
  • Ticket #16052 – Description

    initial v1  
    99b) Apply throttling to RELAY_BEGINs over a given circuit.  Something like "allow up to N streams to complete immediately, then each subsequent stream will be delayed for x seconds, doubling for each additional RELAY_BEGIN, resetting after y seconds".  Annoying since queuing is required (OOM hazard here?).
    1010
    11 c) "If you want to be more resilient to this, use an AF_UNIX backed HS".  This should* shift the part that crumples to the app code, at which point it's kind of not our problem.
    12                                                                                                                        
    13 
     11c) "If you want to be more resilient to this, use an AF_UNIX backed HS".  This should shift the part that crumples to the app code, at which point it's kind of not our problem (the HS code might fall down for other reasons in this case, so I don't see this as being a real solution...)