[tor-dev] Guard node security: ways forward (An update from the dev meeting)
PhillW at PhillW.net
Tue Feb 25 08:16:48 UTC 2014
I'm trying to follow this, so perhaps if someone could explain a little bit
to me.... metrics reports.....
r phillw tNrlqRlQkVqUXVGLWFYhQeYBYI0
14:29:23 184.108.40.206 9001 0
s Fast Guard Named Running Stable Valid
v Tor 0.2.4.20
p reject 1-65535
I'm guessing that the cut off level proposed is 'Bandwidth'... to what
level would it fall before said relay was not used with guard, or am I
totally wrong in my thoughts of what is being proposed?
On 25 February 2014 04:51, Tariq Elahi <tariq.elahi at uwaterloo.ca> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Hey George,
> Glad to see that guard questions are still being asked.
> Some thoughts from your plots.
> On 24-Feb-14 9:06 PM, George Kadianakis wrote:
> > And because release-early-release-often, here is a graph:
> > https://people.torproject.org/~asn/guards/guard_boxplot_4000.png
> > The middle boxplot is the probability distribution of our current
> > guard selection process (e.g. the most likely to be selected guard
> > node is selected with probability ~0.013). The right boxplot is
> > the probability distribution we would have if we pruned the guard
> > nodes that are slower than 4MB/s. We can see that in that case, the
> > most popular guard node has probability of ~0.15 being selected.
> A question: How much of the total BW was dropped due to the condition
> "guard BW must be greater than 4MB"?
> - From a security perspective:
> While the top guard did get ~0.015 rather than ~0.013, a change of
> +~15% on its original probability of being selected, all the other
> guards also got a boost. Thinking about it from a steady state: the
> increase in chance (+X%) of being picked is due to the fact that they
> _do_ now own +X% more bw than before. They haven't gained something
> for nothing. So it seems that dropping bandwidth is not harmful if we
> forget about the previous state of the network.
> Have I got something wrong in this analysis?
> Other thoughts: raising the bar on guards leads to good things(tm).
> Not amazing(R), though. One, you get less relays that shouldn't really
> be guards slowing things down. Two, an adversary can't take control of
> a large number of slow relays (like in a botnet of residential
> computers) and run guards that in aggregate give them a lot of
> bandwidth (which is how guards are selected, i.e. the adversary gets
> one of their bots picked because the chance of one of the bots being
> picked in aggregate is high) and at the same time slow down service
> for a client who actually will use that bad guard with low bandwidth.
> The trick, as you have pointed out, is in picking this cut-off point.
> But dropping the bottom most doesn't really hurts things, apart form
> the feeling of leaving bandwidth on the table.
> Looking forward to seeing progress. :)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.15 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> -----END PGP SIGNATURE-----
> tor-dev mailing list
> tor-dev at lists.torproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tor-dev