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

George Kadianakis desnacked at riseup.net
Wed Mar 5 22:19:37 UTC 2014


Nicholas Hopper <hopper at cs.umn.edu> writes:

> On Tue, Feb 25, 2014 at 5:04 PM, Nicholas Hopper <hopper at cs.umn.edu> wrote:
>> Another thought: we also should investigate how various thresholds
>> affect the relationship between the cumulative guard weight total and
>> the total exit weight.
>
> Well, that turns out not to be a real issue: even if we set the guard
> threshold to 20MBps, the total guard weight still exceeds the total
> exit weight.
>
> Here is a chart showing what fraction of total guard bandwidth is
> retained as we vary the guard threshold from 0 to 10MBps:
>
> https://www-users.cs.umn.edu/~hopper/guards/guard_thresholds_bandwidth.png
>
> And here's a chart showing what fraction of clients will choose the
> highest (max%) and median (median%) guards as we vary the threshold
> over the same range:
>
> https://www-users.cs.umn.edu/~hopper/guards/guard_thresholds_weight.png
>
> 2MBps and 6MBps look like interesting points on the curves.

OK, let's get back to this. This subthread is blocking us from writing
a proposal for this project, so we should resolve it soon.

There is one very important performance factor that I can't figure out
how to measure well, and that's the impact on the "individual user
performance" if we switch to one guard.

That is, how the performance of the average user would change if we
switch to one guard. But also how the performance of an unlucky user
(one who picked the slowest/overloaded guard) or a lucky user would be
altered if we switch to one guard.

This is a very important factor to consider since the unlucky user
scenario is what forced us to think about imposing more strict
bandwidth cutoffs for guards. This factor is also relevant in the case
where we increase the guard bandwidth thresholds, so we should find a
way to evaluate it.

Nick, do you have any smart ideas on how to measure this?

Tariq's paper does this in 'Figure 10': it has a CDF with the
"expected circuit performance", where you can clearly see that the
number of clients having a super slow circuit (< 100kB/s) with three
guards is extremely low (~0%), but when you switch to one guard they
are not so few anymore (5% of clients). I'm curious to learn how that
CDF was created, for example I guess they only considered the
performance impact of the guard on the circuit, and not of the rest of
the nodes.

Is this kind of measurement adequate to decide whether an unlucky
client will get good enough performance?

For example, should we assume that a guard of 100kB/s is equally
performant to users in a network where one guard is used and in a
network where three guards are used?

And if Tariq's 'Figure 10' approach is indeed good enough for us, how
should we proceed? Are we satisfied by the performance of the one
guard approach in 'Figure 10'? If not, we will probably need to
increase the guard bandwidth cutoffs. Should we make more 'Figure 10'
graphs with different bandwidth cutoffs for the case of 1 guard, and
try to find the bandwidth cutoff that will resemble the current Tor
network most?


More information about the tor-dev mailing list