[tor-dev] Guard node security: ways forward (An update from the dev meeting)

[Phill Whiteside]

Hi,

I'm trying to follow this, so perhaps if someone could explain a little bit
to me.... metrics reports.....

valid-after 2014-02-25
00:00:00<https://exonerator.torproject.org/consensus?valid-after=2014-02-25-00-00-00>
r phillw tNrlqRlQkVqUXVGLWFYhQeYBYI0
pR9ddClTA2Eo6AI989NA3BGXNs4<https://exonerator.torproject.org/serverdesc?desc-id=a51f5d742953036128e8023df3d340dc119736ce>
2014-02-24
14:29:23 176.31.156.199 9001 0
s Fast Guard Named Running Stable Valid
v Tor 0.2.4.20
w Bandwidth=7530
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?

Regards,

Phill.


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. :)
>
> Cheers,
> Tariq
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.15 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJTDCFnAAoJEJaS+qOeq5CkB1QH/2Elbogxn4jY54fi69UxT4lp
> hgRBSrYJwVH41SqmIe+pZgKk0R6SvLMK3UQiEMKGqH/ah25uR18KBV+g/t57gXzm
> hI/u/tXophbF6fIk+EnA1PdYgyFsF3fPoxieT4HHvsui/y/Xadt49reRBrE209I0
> /uMT1yIWDv24Hr03HQz2vFX8EXM/L0veBnbBjH9BvHWa2+bEKnYd/RdY/+4BLHY6
> jfi6/eqOSgvRGgazSuepH3sNUJ2s9OtvOVtp33I8WX90QVW+UWPwXeozNi3m9PSg
> p8CYHiL4VhBcM3ttj39U15s4Z1jKW/c1bUnb+AkGxdCVEqTPT3aONGegv2EbTvo=
> =GsDo
> -----END PGP SIGNATURE-----
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>



-- 
https://wiki.ubuntu.com/phillw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20140225/8655359f/attachment.html>