Re: : Export END_CIRC_REASON_* to controler

[Mike Perry <mikepery@xxxxxxxxxx>]

Thus spake Paul Syverson (syverson@xxxxxxxxxxxxxxxx):

> On Fri, Oct 13, 2006 at 01:14:53AM -0500, Mike Perry wrote:
> > 
> > One issue I would like to guard against/watch for is an adversary
> > destroying circuits if they do not detect one of their colluders at
> > each end.  Adversaries doing this would be able to ensure that the
> > only time they waste bandwidth on a connection is if they know they
> > are able to determine its origin, thus gaining an advantage over the
> > expected rate of O((c/n)^2).
> > 
> > For the scanner to detect this, there shouldn't be any way a node can
> > make us mistake a malicious closure from one that should happen
> > normally (ie was requested by us). Taking the reason right from the
> > wire enables a node to do this.
> > 
> 
> I'm probably not getting some key assumption here, but I don't see how
> this can be prevented without some major developments.  This sort of
> attack is roughly how the experiments to detect hidden servers were
> conducted
> (http://www.onion-router.net/Publications.html#locating-hidden-servers)
> In that case we controlled the requesting client so could easily drop
> the circuit without doing anything otherwise odd.  But I don't see why
> any entry or exit node can't simply stop sending if a colluder is not
> detected on the other end.  Then he can close the circuit or others
> on the circuit will close it for him, and there will be no easy way to
> recognize that node as the culprit.  One coud construct testing and
> reputation mechanisms to recognize nodes that do this flagrantly and
> repeatedly. But some of us have worked on that and it can get tricky
> quickly, plus framing other nodes becomes a big issue.

Actually you're right. There still is the possibility of lowering the
bandwidth of non-captured streams to almost nothing, but giving them
just enough to stay alive. This would require a slightly more
sophisticated approach of using watermarks (or other non-intrusive
fingerprinting) instead of more reliable protocol breaks, but it
probably is doable.

This may still be detectible if I made the scanner track incidences of
really low bandwidth streams even though all nodes in the path have
displayed significantly higher stream bandwidth capabilities in other
situations. If these abberations happen a lot for a node or set of
nodes, something may be going on (bug, network issue, or malicious
node) that a human could attempt to divine out.

I see 3 papers on reputation systems by you guys:

http://freehaven.net/doc/econp2p03/econp2p03.pdf
http://freehaven.net/doc/casc-rep/casc-rep.pdf
http://freehaven.net/doc/mix-acc/mix-acc.pdf

Any others? Which one do you recommend I start with?

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