Re: : Export END_CIRC_REASON_* to controler

[Paul Syverson <syverson@xxxxxxxxxxxxxxxx>]

On Fri, Oct 13, 2006 at 05:09:29PM -0500, Mike Perry wrote:
> 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 should clarify my point. You are right too. This is detectable and
if you are locally building a reputation for nodes you use it might be
fine. Also in practice it might be fine. There are some reasonable
systems out there tracking up time and delivery through mixnets, and
Tor uses a simple reputation system for route selection based on
uptime and self-reported capacity. As well as some OK designs to track
reputation, e.g., George and Len's "heartbeat traffic" paper. But
there are all sorts of attacks on the reputation system itself that
can creep in. As just one example, perhaps I want to reduce the
effectiveness of specific high bandwidth exit nodes in a given part of
the IP space/geographic space/jurisdictional space/whatever. I could
try to DoS them etc., but if they're high bandwidth, that's expensive
and of limited effectiveness. But if there's a global reputation
system I can just do things like mess up circuits (mangle cells/slow
down/whatever) when I own the middle node and the target is the exit
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.

> 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?
> 

These are fine. Chronological order is also probably fine, i.e.,
mix-acc, casc-rep, econp2p. The first one tries to set up a
trusted witness system to track reputation of nodes in a mix
network. I think ultimately that's probably the only viable thing
to get you global reputation resistant to adversaries in a big
distributed system _if_ you can figure out who to trust ;>).
The second one tries to do it without trusted elements in a cascade
setting. It was an interesting exercise in designing robustness
in the face of a negative result. The econp2p is more of a survey
of the difficult issues in this area. 

aloha,
Paul
-- 
Paul Syverson                              ()  ascii ribbon campaign  
Contact info at http://www.syverson.org/   /\  against html e-mail