Bridge stability

[Mike Perry]

Thus spake Karsten Loesing (karsten.loesing at gmx.net):

> Okay, here are the new results, this time with taking IP address changes
> into account. The graph shows the fraction of random bridge subsets
> (containing 3 bridges, 1 of them running on port 443) that had at least
> 1 bridge running continuously throughout 6/24/48/96 hours. For example,
> a value of 0.9 on the y axis means that 90% of all samples taken at the
> date and time on the x axis were useful for another 6/24/48/96 hours.
> 
> http://freehaven.net/~karsten/volatile/bridge-stability-ipchange-2010-04-01.png
> 
> For comparison between the analysis with and without IP address changes,
> here are the two 96 hours lines for both analyses. The red line in the
> following graph is equivalent to the purple line in the previous graph.
> 
> http://freehaven.net/~karsten/volatile/bridge-stability-96h-2010-04-01.png
> 
> So, yes, when we take IP address changes into account, bridge stability
> is worse than we thought from the first analysis. But still, it's not as
> bad as one might have imagined. Note that the reasons for the drops on
> December 11, 23, and 31 are probably problems with the bridge authority,
> not with all bridges (I could make the analysis more precise by looking
> at self-reported bridge uptimes, if required). That means that the 4
> days before those drops are probably too low in the graphs. In this
> case, the 96 hours line is between 60% and 90%. Or to rephrase that, in
> 3 out of 4 cases, people had a working bridge 4 days after requesting
> bridge addresses, and the 4th person would have to request another set
> of bridges.
> 
> I'd like to hear what others say about these results. Am I missing
> something? Is "3 out of 4" a horrible result?

I don't know. I feel like there is a significant difference between:
http://freehaven.net/~karsten/volatile/bridge-stability-4-bridges.png
and
http://freehaven.net/~karsten/volatile/bridge-stability-96h-2010-04-01.png

I am especially suspicious as to why sets of 4 bridges weren't as
dramatically affected by the bridge db failure?

The big question on my mind is does it really cost us that much in
terms of adversary effort to enumerate X% of the bridges if we hand
out one extra?

Can we run some simulations or math as to how many samples of 3, 4, or
5 bridges it would take for an adversary to get 50%, 60%, 70%, 80%,
90% blockage coverage of all of them?

If the answer is that it doesn't significantly reduce the number of
hits against https://bridges.tp.o that the adversary has to do to get
75% coverage, I think we should really consider handing out more to
get that reliability boost.


Also, reliability isn't the only issue here. We also should simulate
blocking probability too, in conjunction with reliability.

For example, what is the likelihood that all of your 3, 4 or 5 bridges
from tp.o will be blocked or down if the adversary has 75% of the
bridges blocked (or whatever the blockage rate was during the recent
bridge blocking event in march). How much does this change if we hand
out 4 or 5 bridges instead?

There may be some sweet spot in that it takes the adversary less hits
to block 75% of the network if we hand out 4 or 5 bridges, but it is
also more likely for a user to still have at least one of their
bridges not blocked and still running at this blockage rate.

The best way to answer this is probably to get an estimate on the
number of 3-bridge samples China needed to block the percentage of the
network they blocked in March, and expect that they will devote this
same effort in the future. Using this number of samples, does the
likelihood of a user being blocked go up or down if China blocks an
additional percentage of the network because we handed out an extra
bridge, but they have an extra bridge IP or two to work with.




-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20100406/77847df6/attachment.pgp>