Re: Path-spec - fast circuits

[Scott Bennett <bennett@xxxxxxxxxx>]

Hi Paul,
     On Mon, 15 Feb 2010 11:27:56 -0500 Paul Syverson
<syverson@xxxxxxxxxxxxxxxx> wrote:
>On Mon, Feb 15, 2010 at 12:30:22AM -0600, Scott Bennett wrote:
>>      On Mon, 15 Feb 2010 00:16:28 -0500 Flamsmark <flamsmark@xxxxxxxxx>
>> wrote:
>> >On 14 February 2010 03:15, Scott Bennett <bennett@xxxxxxxxxx> 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.
>
>This is a good point, but it's hard to gauge both the urgency and the
>significance of a threat you discover. In the case of one that had
>been shown to work on the live Tor network and that was easy to do, it
>seemed clear that some remediation was needed quickly.  Note that the
>Bauer et al. simulation was a year after Lasse Overlier and I
>demonstrated this attack on the live Tor network (not simulated) using
>just a single corrupt Tor node that lied about its bandwidth to find
>hidden services, as we described in "Locating Hidden Services" in
>2006. Of course we structured things so that we would only attack

     But a remedy was already available!  The moment such an attack were
noticed, the directory authority operators should immediately assign an
"Invalid" flag to the offending node(s).  Such a response would take the
miscreant(s) out of the picture completely and in short order, as well
as obviating any kind of "attack-by-tor-developers-against-the-whole-net"
approaches.  It would also have a much smaller effect upon the total tor
network capacity than the measurement-from-afar method.  Various kinds
of monitoring tools to detect possible cases of such an attack could and
should be developed, of course, to notify the directory authorities of
possible cases.  For the present time, though, frequent, but brief,
perusals the torstatus pages should suffice for the notification function.
Likewise, the subscribers to this list and to the TOR-RELAYS list can be
counted upon to report anything weird that they notice.  We do that
already for countless other problems, including the "bad exit" problems.
Surely, the development team must know this by now.

>ourselves without affecting others. See the paper for details.  This
>prompted a couple of changes. One was the capping of allowed claimed
>bandwidth, another was entry guards (which Bauer et al. showed could
>also be used to create attacks without the caps).
>
>Your comments on and suggestions for (and even complaints about ;>)
>how to measure the network and how to use that information in routing
>are a welcome part of the picture, but this remains a complicated
>balancing act that we continue to refine as best we can, including
>in that the considerations that you have raised.
>
     I've been thinking about these issues for quite a while.  You and
all the other tor developers should feel free to contact me on or off
this list to discuss any/all of them.  I would like to reiterate here,
though, that the single, most urgent problem is the conflation of two
purposes in the reporting to date of the throughput capacities by relays
in the descriptors they publish.  This really, really needs to be
addressed and redesigned before most of the other problems can be tackled
properly.  Separating those purposes first will not only avoid a lot of
wasted development effort in the future, it will encourage much better
analysis and definition of each of those two purposes, so that the data
reported will be more valuable for each purpose.
     One last comment I have here is to thank the developers for the
recent reexamination of the methods of determining how to use Guard and
Exit flags in route selection (along with how to assign those flags),
which is sure to improve performance.


                                  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 majordomo@xxxxxxxxxxxxxx with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/