Tor 0.2.1.12-alpha is out

[Scott Bennett]

     On Tue, 10 Feb 2009 04:54:29 -0500 Roger Dingledine <arma at mit.edu>
wrote:
>On Tue, Feb 10, 2009 at 11:34:31AM +0200, Jari Turkia wrote:
>> Roger Dingledine wrote:
>> >Tor 0.2.1.12-alpha features several more security-related fixes. You
>> ...
>> >    - Fix a temporary DoS vulnerability that could be performed by
>> >      a directory mirror. Bugfix on 0.2.0.9-alpha; reported by lark.
>> 
>> Is there a bug report about excessive log flooding?
>> Feb 01 04:02:32.473 [warn] Failing because we have 1016 connections 
>> already. Please raise your ulimit -n.
>> Feb 01 04:02:32.860 [warn] Failing because we have 1016 connections 
>> already. Please raise your ulimit -n.
>> Feb 01 04:02:35.847 [notice] accept failed: Too many open files. 
>> Dropping incoming connection.
>> Feb 01 04:02:35.847 [notice] accept failed: Too many open files. 
>> Dropping incoming connection.
>> 
>> Raising ulimit -n is not an option for all of us. What is needed is a 
>> config option to limit number of connections and limit the logging. In a 
>> couple of hours there will be 3 gigabytes of log. This makes it possible 
>> to DoS a tor-node.
>
>You should set your MaxAdvertisedBandwidth line in your torrc, at a
>low enough number that it's advertising a rate that doesn't cause those
>log entries.

     Roger, this is definitely like shaking a tree by its trunk to get the
ripe fruit to fall.  Not only will it shake loose unripe fruit, it won't
necessarily shake loose all of the ripe fruit.  The man is right:  we need
a way either a) to send something back to the client that says, "I can't
open a new OR connection" (or perhaps simply, "I can't connect to that OR")
or b) force immediate closing of the oldest OR connection that is not
currently bearing any circuits.  Having such a signal would enable exactly
the sort of control he is requesting.  Moreover, if option b) is taken, tor
ought then to operate like UNIX pagedaemons in the sense of maintaining some
minimum number of available fd's that can be opened for new OR connections
like pagedaemons try to maintain a free page frame pool to avoid having stalls
occur until needed page frames can be made available.
>
>(If you ignore them, you are denying service to clients who are trying
>to use your relay and failing.)

     The relay needn't ignore them if it has a way to say, "I can't open
more OR fd's at present", which would be option a) above.
>
>Eventually, you're right, we should design a Tor network and protocol
>where each relay doesn't have to reach each other relay. That's harder
>than it sounds, though, if you want to keep anonymity and have low
>directory overhead too.

     Most electronics-store routers have very limited internal memory and
cannot keep track of more than a few hundred simultaneous connections.
A tor relay running on a network connected via such a router (e.g., Linksys,
Netgear, Belkin, etc.) lose track of old connections when their fixed-size
state or NAT tables become overloaded, so tor ends up closing the lost
OR connections anyway.  When I used to run tor behind such a router, including
combined ADSL modem+router devices, I rarely had more than a couple of
hundred connections, and more than ~150 connections resulted in various
problems occurring.  Now that I connect a computer directly to a cable
modem and let that computer serve as the router for my LAN, I can see that
the connection count initially grows rapidly far beyond what it ever reached
with an electronics-store router and grows more slowly after the first 1,300
or so connections.  At present, my relay has been up for over two months
and currently has over 3,000 ESTABLISHED connections and usually another
50 - 200 connections in transitional states.
     tor already closes unused OR connections after some amount of time has
elapsed.  How hard would it be to adapt that process to trim unused connections
by proximity of the oount of ESTABLISHED connections to some limit?
>
>Why is raising ulimit -n not an option for you?
>
     Is that message issued on non-UNIX, non-LINUX systems?


                                  Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet:       bennett at cs.niu.edu                              *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."                                               *
*    -- Gov. John Hancock, New York Journal, 28 January 1790         *
**********************************************************************