Re: [tor-talk] Guard flag vs relay bandwidth

[Paul Syverson <syverson@xxxxxxxxxxxxxxxx>]

On Wed, Nov 14, 2012 at 04:18:34PM +0600, Roman Mamedov wrote:
> On Wed, 14 Nov 2012 04:47:38 -0500
> Roger Dingledine <arma@xxxxxxx> wrote:
> 
> > Right. I've got a half-drafted "the lifecycle of a new Tor relay" blog
> > post sitting around here somewhere.
> 
> That would be great. :)
> 
> > If you want to read a lot more about guard flag allocation, see
> > "Changing of the Guards: A Framework for Understanding and Improving
> > Entry Guard Selection in Tor"
> > published at this year's WPES:
> > http://freehaven.net/anonbib/#wpes12-cogs
> 
> Yes I have read descriptions of the Guard flag, but to be honest I am not
> convinced at all by the arguments presented in its favour.
> 
> To me it just seems to be an elaborate trade off that results in "if you
> are f***ed, ensure you are f***ed as completely as possible and with the most
> dire consequences possible".
> 
> "An adversary has a chance to see some of my entry traffic for some time"
> 
> ...seems rather harmless to me compared to the Guards system's of:
> 
> "an adversary has a chance to see ALL of my entry traffic for a long period"

It isn't. One of the lessons of 
http://www.freehaven.net/anonbib/#hs-attack06
and
http://www.freehaven.net/anonbib/#bauer:wpes2007
is that the chance and the time matter.
It turns out that if you communicate with a destination at all
regularly, the adversary will deanonymize that relationship very
quickly with very few resources. If this is a concern, then you
are much better off using guards since if none are bad then
(for this class of attack) none of your connections are deanonymized.
And you also overstate the threat of a compromised guard:
the adversary sees ALL the traffic but doesn't deanonymize
it. That only happens when he combines this with some other attack,
most notably when he owns the other end of the connection as well.
Plus he doesn't see all the traffic, even in this sense, just
a third of it on average (averaging out differences between guards).


> 
> > Oh, and I'll leave you with one final thought: ensuring "maximum possible
> > bandwidth consumption" might not actually be the best goal here. Every
> > time your relay's bandwidthrate token bucket runs dry, that's a pile of
> > Tor users who have to wait another second before their bytes will move
> > forward. The best Tor network is one where no relays are bottlenecked.
> 
> The nodes are far from being at network bottleneck, I mean b/w consumption in
> terms of terabytes per month, since in most cases what I have is a bandwidth
> arrangement where on a 100 Mbit or 1 Gbit port usage of X TB/month is possible
> and this costs Y USD. Unused bandwidth from one month does not carry over to
> the next, so it's suboptimal when a node only uses like 30-50% of what it could
> have used that month.

I don't think that's Roger's point. 1. You can induce all kinds of
congestion and scheduling messes for circuits going through you if
you're optimizing for TB/month processed. 2. There can be advantages
to the performance of the network for everyone by throttling your
connections even if your node is processing everything with no
significant delay. See our paper
http://www.freehaven.net/anonbib/#bauer:wpes2007

HTH,
Paul
_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk