Re: Path-spec - fast circuits
On Sat, 13 Feb 2010 11:18:33 -0500 Nick Mathewson ni...@freehaven.net wrote: On Sat, Feb 13, 2010 at 5:33 AM, Scott Bennett benn...@cs.niu.edu wrote: [...] =A0 =A0 I've withheld comment on the above for a long time, mainly becaus= e I had intended to include it in a write-up that I still haven't found the time to do, but I really think it cannot be avoided any longer. I would greatly appreciate a justification for the presumption that any process other than the tor node in question can possibly provide a more accurate measurement of its data rate capacities. =A0Any other process, *even on the same computer*--much less anywhere else, can only measure the performance of the TCP connections between itself and the tor node in question, whereas the tor node in question has a complete picture of all of its simultaneous connections to all processes, wherever they may exist around the planet. Right. If I'm a Tor node, I have a better picture of my own actual usage than any other process anywhere in the network. But one big problem is that you have no guarantee whatsoever that I'm telling you the truth about my measurements. See for example Kevin Bauer et al's Low Resource Routing Attacks Against Tor. Yes, I've understood that from the outset, but I haven't seen any evidence that such abuse is actually happening. As a hackish workaround, we had clipped the largest believable self-reported bandwidth, so that a hosstile or broken server couldn't trivially claim to have infinite capacity and attack or DOS the network. But this meant that genuinely high-capacity nodes got underutilized. That was also apparent and created an *actual* problem of wasted resources. Neither of the above points is imaginary; Bauer et al demonstrated their attacks on planetlab, and the underutilized capacity really existed. I disagree. They showed by experiment how such a problem would work, an exercise that struck me as kind of silly because it was clear from theory that such an attack would have to work like that. But IIRC they did *not* show that such abuse was actually occurring in the wild, and AFAIK, no one else has shown that either. Meanwhile, the measurement- from-afar method is creating *actual* misallocation of resources, so a problem has been intentionally introduced *by the tor developers* to counteract a problem that had *not* been shown to be occurring in the actual global tor network and should therefore have been considered imaginary pro tempore. (A smaller problem was that nodes were reporting their observed bandwidth _usage_, whereas clients really care about the expected performance of their circuits.) Now you've finally touched upon the worst problem of resource allocation that existed prior to introduction of the measurement-from-afar method. The number being reported in descriptors is *past peak data rate utilization*, which is being used for two incompatible purposes. One of those purposes is as grist for statistical analysis of tor network performance by the developers and other interested parties. The other use is by client code as a proxy for data rate *capacity* for route selection. Using historical (i.e., since the node was initialized) data rate usage information, which is recorded in a manner useful for statical analysis, as an approximation for capacity information can be a reasonable approach, but it stumbles badly if it is updated quasi-periodically but not as *successive* approximations that converge upon the true capacity. What is needed is to detect the actual capacity as closely as possible for the benefit of clients, which requires that successive approximations converge upon reality. Reported usage will normally be less than or equal to the actual limits on capacity, so it is harmful to ever report a value in a descriptor that is less than any value in descriptors published previously since the most recent initialization because a lesser value than previously reported is a *less accurate* (i.e., diverging) approximation than previously reported approximations. What the client needs from the reported values, then, is incompatible with the needs of researchers like the tor developers and others engaged in statistical studies of tor network loading. There are other aspects of the current data reporting/collection that are problematical from the perspective of sampling theory and time-series analysis, both for network performance analysis and for capacity detection for use by clients. For example, the value reported is not a binned value, but rather is the maximum value of the moving minimum value in a 10-sample- wide moving window, where the base sampling rate at this level is 1 Hz. For the purpose of statistical analysis of network performance, such a value gives a rather distorted picture of what is going on in the network. For client use, it is more helpful because it more closely approximates the capacity than simple averages or totals,
Re: getinfo circuit-status
OK, I already thought, that a node with real name (not the fingerprint) could be identified clearly. Can someone help with my first question (which of the circuits from getinfo circuit-status TOR will use)? Am 14.02.2010 01:04, schrieb Damian Johnson: Not sure about the first question (my guess would be either multiple circuits are built for added bandwidth or for complimentary exit policies - docs or someone else could answer this). As for the second question, I'm assuming that entries using nickname (verses a fingerprint like $4F0826FA4C325C3CAA0054A6E023E566302C20C7) have the named flag and hence won't have a problem with ambiguity. Unfortunately the control-spec is a little tight lipped on this point so don't blame you for wondering about it. Cheers! -Damian On Sat, Feb 13, 2010 at 12:21 PM, Nico Weinreichi...@web-unity.de wrote: Hi, when interacting with tor control I can get the circuit with command getinfo circuit-status. What's a bit confusing for me, there are more than one circuits: getinfo circuit-status 250+circuit-status= 51 BUILT rueckgrat,myrnaloy,$2DDAC53D4E7A556483ACE6859A57A63849F2C4F6 PURPOSE=GENERAL 50 BUILT Freedom,nixnix,$4744AD962D32A11CD7CF4513617FAC33B339806B PURPOSE=GENERAL 15 BUILT HW2,$4F0826FA4C325C3CAA0054A6E023E566302C20C7,RainCloud PURPOSE=GENERAL 14 BUILT Freedom,SuperDave,bp1 PURPOSE=GENERAL So I have two questions: -which circuit does tor use (is it alway the circuit with the highest number?) -is there a way to get this nodes always as fingerprint (for example, there are many nodes with name idideditheconfig and how do I know which one is it when the node is listed in plain text?) *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/ *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/ *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Path-spec - fast circuits
Thus spake Nick Mathewson (ni...@freehaven.net): 2010/2/12 ilter yüksel ilteryuk...@gmail.com: For circuits that do not need to be fast, when choosing among multiple candidates for a path element, we choose randomly. For fast circuits, we pick a given router as an exit with probability proportional to its bandwidth. Could anybody explain why Tor pick exit router with probability proportional to its bandwidth only for fast circuits? As far as i know Tor uses this technique for load-balance. But why it uses this technique only for fast circuits? First of all, Fast circuits are a bit misnamed as used in path-spec.txt. Basically, fast means bandwidth-sensitive. The only ones that aren't don't need to be fast in this sense are ones that are going to be used only for a tiny amount of traffic. That said, I think the statement in path-spec.txt may be poor. It probably makes sense to weight all choices by bandwidth, now that bandwidth is measured rather than just being self-advertised. To see what the code is actually doing, the string to search for is need_capacity or NEED_CAPACITY. The most interesting layer to look for this is at is where it's passed as a flag to circuit_launch_by_router() or circuit_launch_by_extend_info(). Ok, I've gone ahead and fixed both the spec and the code in mikeperry/consensus-bw-weights4 in my git repo. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpSAWY5Ln2FT.pgp Description: PGP signature
Re: Path-spec - fast circuits
On 14 February 2010 03:15, Scott Bennett benn...@cs.niu.edu wrote: But one big problem is that you have no guarantee whatsoever that I'm telling you the truth about my measurements. See for example Kevin Bauer et al's Low Resource Routing Attacks Against Tor. Yes, I've understood that from the outset, but I haven't seen any evidence that such abuse is actually happening. Tor isn't just designed to be resilient to attacks that are actually being employed. It is designed to be resistant to theoretical attacks too - as well it should be. Indeed: complaining that we're protecting against attacks, but nobody is using them is like saying `I bought this expensive umbrella, but then I didn't even get wet.':
Re: Path-spec - fast circuits
+1. I was kinda floored at the logic behind 'since this attack hasn't been used in the wild it should be ignored' but... for each their own. ;) -Damian On Sun, Feb 14, 2010 at 9:16 PM, Flamsmark flamsm...@gmail.com wrote: On 14 February 2010 03:15, Scott Bennett benn...@cs.niu.edu wrote: But one big problem is that you have no guarantee whatsoever that I'm telling you the truth about my measurements. See for example Kevin Bauer et al's Low Resource Routing Attacks Against Tor. Yes, I've understood that from the outset, but I haven't seen any evidence that such abuse is actually happening. Tor isn't just designed to be resilient to attacks that are actually being employed. It is designed to be resistant to theoretical attacks too - as well it should be. Indeed: complaining that we're protecting against attacks, but nobody is using them is like saying `I bought this expensive umbrella, but then I didn't even get wet.': *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Path-spec - fast circuits
On Mon, 15 Feb 2010 00:16:28 -0500 Flamsmark flamsm...@gmail.com wrote: On 14 February 2010 03:15, Scott Bennett benn...@cs.niu.edu wrote: But one big problem is that you have no guarantee whatsoever that I'm telling you the truth about my measurements. See for example Kevin Bauer et al's Low Resource Routing Attacks Against Tor. Yes, I've understood that from the outset, but I haven't seen any evidence that such abuse is actually happening. Tor isn't just designed to be resilient to attacks that are actually being employed. It is designed to be resistant to theoretical attacks too - as well it should be. Indeed: complaining that we're protecting against attacks, but nobody is using them is like saying `I bought this expensive umbrella, but then I didn't even get wet.': That wasn't my point at all. What I was complaining about was the introduction of a new, *actual* problem as the cure for a disease we had no sign of suffering from. Of course, a clear avenue of attack should be blocked, but let's pick a way of doing it that embodies the first, do no harm concept. The method that the developers have employed in this case simply adds to the misallocation problems that were already bogging tor down. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
