Re: how many connections are legitimate to a DirPort?

[Scott Bennett <bennett@xxxxxxxxxx>]

     On Thu, 17 Jan 2008 01:34:48 -0500 Roger Dingledine <arma@xxxxxxx>
wrote:
>On Wed, Jan 16, 2008 at 08:18:28PM -0600, Scott Bennett wrote:
>>      How many simultaneous connections from a tor client to a directory
>> mirror's DirPort are legitimate?  Is more than a single such connection
>> necessary, and if so, why?
>
>Here are three cases where it occurs legitimately:
>
>a) Sometimes there are multiple Tor clients natted behind a single
>IP address.

     That case doesn't explain what I'm seeing, though.
>
>b) Since Squid doesn't like URLs >= 4096 bytes, and you never know where a
>transparent squid proxy will pop up, Tor limits each directory request to
>96 descriptors. So it's possible that a Tor client that's just starting
>up will want more than 96 descriptors from you, in which case it will
>use multiple (parallel) connections.

     This one would explain what I see from many IP addresses, but basically
they do it for a little while, then stop.  The problem cases are the ones
that keep doing it for long periods of time (say, hours), tying up my
transmission bandwidth.
>
>c) If a Tor client has a connection, but it's going slowly, and not long
>after it learns that it wants to fetch some more descriptors (say it gets
>a new networkstatus concensus, or some other directory request fails),
>and it picks you for the next fetch.

     This one could also explain some of the seemingly innocuous cases, but
not the problem cases.
>
>I'll let you know if I think of others. But these are some already. :)
>
>You could make the case that we should queue requests for a given relay
>so we only ask them one at a time. Maybe one day we'll fix the code so

     Yes.  I don't see any obvious reasons that multiple connections would
send all the data any faster than a single connection would, but multiple
connections surely do incur a lot more overhead.  Furthermore, multiple
connections seriously reduce the savings from V-J header compression over
point-to-point links.
     I'm a little surprised that directory fetching is handled this way,
especially given how multiple streams and circuits are handled over single
connections between tor servers.  I would have expected directory streams
to be handled similarly.

>it does that more reliably; but that's not on the list for 0.2.0.x.
>
>I'm not sure what is causing the DirPort DoSes that some people have been
>seeing. More details (e.g. what they're asking for) would be helpful in
>tracking those down.
>
     Well, some time back you asked me to give you the LOGINFO messages the
next time it happened, so I kept my eyes open, and the next time I saw it
happening, I saved the log file for you.  I then posted a note on this list,
asking whether you or anyone else still wanted to see it and if so, what to do
with it.  I got no response, so after a week or two I deleted it.  If you want
me to trap the LOGINFO data the next time again, I will, but please let me
know what to do with it once I have it.
     I'm currently trying to make up my mind whether to remove the filtering
rules from my router for the first three cases, from which I notice the packet
counts have gone down to nearly zero each time I've checked.  The one I added
for today's (Wednesday's) incident I'll leave in place for at least a few
Days until the frequent attempts cease.


                                  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         *
**********************************************************************