Re: : Export END_CIRC_REASON_* to controler

[Mike Perry <mikepery@xxxxxxxxxx>]

Thus spake Paul Syverson (syverson@xxxxxxxxxxxxxxxx):

> node. There are other things like this. I haven't looked at all cases,
> but my guess is that the bad guys can always win this game (i.e.,
> damage your reputation more than their own, cf. the casc-rep paper),
> so you just need to design to be robust enough that it doesn't
> matter. That will not always be possible.

Well considering the fact that I blame everyone in the circuit when
there is a non-specific failure, I'm not sure they would be able to
damage a particular node more then themselves. At best they could
contribute an equal amount of failure to their target node and
themselves. I'm counting on the fact that over time, even if you give
some false accusation to some nodes, the ones really dropping circuits
will have higher loss rates than everyone else, simply because in a
free route mix they cannot be next to all of their targets all of the
time.

Of course, if there are weaknesses in Tor itself that allow you to
make it look like another node had the failure by corrupting its
traffic on the way back or something, there still are issues.
Hopefully whenever Tor is not absolutely sure a node is at fault it
does not report a Path field to the controller, or reports everyone in
the Path field. At a glance, this seemed to be the case, but I'll try
to double check the src at some point.

I will have a look at those papers to see if there's anything to
be gleaned from them as well. Sometime. :)

Btw, Roger&Nick: 

Any thoughts on 
http://fscked.org/proj/minihax/SnakesOnATor/fail_reasons 
http://fscked.org/proj/minihax/SnakesOnATor/fail_rates ?

Useful, not useful, anything additional that might help? Maybe node 
version info? 

Maybe not useful by itself, but might give you guys an idea if a node
needs some special attention/probing/stress testing, or do you already
do this w/ your own dev servers?

-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs