[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
peculiar server "bandwidth" posted by server "mnl" and possible new type of attack
Over the last several days, a server nicknamed "mnl" has been posting
descriptor updates bearing highly suspect data rate information. I have
contacted the person at the contact-info address, so he is aware that the
observed data rate (misnamed "bandwidth") reported in mnl's server descriptor
is probably inaccurate by a factor of 10 or greater. His server has been
up for over a month, and IIRC, is usually a relay with a very high data rate
and therefore to be considered a significant benefit to the tor network's
overall performance.
However, mnl has lately been claiming to have had ten-second peak rates
on the order of eight to ten times the peak rates typically published by
blutmagie, the extraordinarily high-rate server that is nearly always a big
chunk of the tor network capacity's foundation. Here is the latest of mnl's
descriptors from my cached-descriptors file:
router mnl 159.149.71.27 9001 0 9030
platform Tor 0.2.0.30 (r15956) on Linux i686
opt protocols Link 1 2 Circuit 1
published 2008-09-08 14:41:50
opt fingerprint ABD3 8668 D3F4 76F5 0232 FEC0 B6DB 6550 EA43 EDD0
uptime 2781643
bandwidth 5242880 10485760 52239166
^^^^^^^^ ---> ~48.8 MB/s (!)
opt extra-info-digest 791494258CFA222ABCA7CD60D41CBFA108275E36
onion-key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBAMZ7P0H3/DUwp/L1+eLx9CZlq8ZYh0vmcI4fA/5IzL4xld0/zOUGBXgI
QVv9qKaLOWB5ljn/LH/cyW2zW/mfJAURyZd00ffbsmA76QEJuJldzgOMQVrVZQwA
+QZCMh2+CgyvHhyyim9gFDsNHbkJQFbdX9hW3//sAMI0Oc4Lp+T7AgMBAAE=
-----END RSA PUBLIC KEY-----
signing-key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBANo7EyYEVcDchLG30pHczPvjC9nB3pwn7CMo2vsa1uuXmvi5Kil1W6go
KhQDvbowfe2TpjMRMxCZ2o02+dmRUQrgwCVZeKqlIbAfbMUpxuB6wCl352nNK6uT
v6cgGNd5cd5aXZN1TVPkVlohi8h9cekDjrWhUu0lIz4GftOQviGxAgMBAAE=
-----END RSA PUBLIC KEY-----
contact cavok@xxxxxxxxxxxxxxxxxxxxxxxx
reject *:*
router-signature
-----BEGIN SIGNATURE-----
YBaKbNNJXSVVuqGTlLRwAAdp1GHdRpGCQwiM5j6ws2Z2W13nbPHUk7PyKJ/3pMEl
EYeVtP1P9G+Hc0ItoC2CmdREDnz/R5I9M9uNG+bHdD1lea/oyQRD6WXMczDFwrvs
54XpWr/MRUXyN0mF5hq8AtHU3NcL6Do4kXXnO9/6m+8=
-----END SIGNATURE-----
Nearly 49 MB/s seems a bit of a stretch. The server's operator sent me
a note saying that the server is attached to the 1 GB/s campus backbone net,
but it is attached via a 100 Mb/s router, so the reported data rate is four
to five times the rate physically possible due to the router's limitation.
The server, according to its operator, is running on a 2.6 GHz P4, and its
descriptor says the machine is running LINUX. Based upon postings quite a
while back from blutmagie's operator and from a few other operators of very
high-data-rate servers, it seems to me that a 2.6 GHz P4 (Northwood?) running
LINUX would not be capable of handling a load eight to ten times that of
blutmagie, regardless of its network connection's capacity.
All of the above leads me to suspect two things. One is that there may
be some bug triggered only under exceedingly odd conditions that leads to
reporting of data rates grossly out of line with reality.
The second is that when a server claims such disproportionately high
capacity, the overall performance of the tor server network can be compromised.
This would happen due to the statistical method used for selecting nodes to
be ussed to construct a circuit, which is partially based upon reported, recent
(i.e., in the preceding 24 hours), peak data rates. In other words, a server
reporting wildly high data rates distorts the PDF, such that an inordinately
high fraction of circuit routes worldwide will include that server, regardless
of whether that server can actually keep up with that workload. If circuits
fail or fail to be built as a result of the overallocated errant server being
in those circuits' routes, the effect is merely to reduce to networkwide total
capacity of the tor network.
That brings us back to something I've already posted on OR-TALK, namely,
the apparent slowdown in tor traffic that has reduced the traffic through my
tor server by at least 30% and, judging from the reduced peaks shown for a lot
of the high-volume servers listed on the torstatus page, the tor network at
large. If this is actually what has been going on, then not only should the
bug be tracked down and killed ASAP, it serves as a call to rethink the method
of circuit route selection to find ways to prevent a reduction-in-throughput
attack that could be made by almost any creep by setting up a corrupted relay.
(mnl is not even an exit.)
(deep breath) I want to state right now that I do not in any way
whatsoever suspect mnl's operator of any nefarious activity. I believe that
he is at least as perplexed over his server's behavior as I am, especially
given other information he provided about events over the weekend. I do not
have a clue what sort of bug in tor could cause a server to begin reporting
exaggerated data rates, but the majority of bugs fixed by Roger, Nick, et al.
are ones that I would never have imagined either. Something weird is going
on, and we both want it figured out.
This note is intended as a loud cry for comment. I want urgently
to be told how I have it all wrong, am hysterical over nothing, that the
current tor network slowdown is due to something else (e.g., greatly reduced
user demand), and that the tor network is not vulnerable in the aforedescribed
manner. Thanks in advance for any reassurance anyone can provide.
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 *
**********************************************************************