Bridge stability

Roger Dingledine arma at
Mon Feb 15 19:14:33 UTC 2010

On Mon, Feb 15, 2010 at 09:29:19AM +0100, Karsten Loesing wrote:
> So, are these good news? Personally, I had expected worse
>results. During most of the time, availability is surprisingly high. An
>80% chance of the bridges working even after 96 hours seems fair.

Hi Karsten,

Thanks for the analysis. This result is indeed good. But:

> I should state that there is one major inaccuracy in the analysis:
>Bridges that change their IP address are not reachable by their
>clients anymore. In theory, clients are able to download updated bridge
>descriptors from the bridge authority to learn about new IP addresses,
>but this functionality is not implemented yet. However, I cannot take
>changing IP addresses into account for this analysis, because I removed
>the IP addresses when sanitizing the bridge descriptors. Hah! Maybe we
>should just fix this problem by implementing the missing functionality.

This part is worrisome. That means your analysis is assuming the bridges
always stick to the same IP address, right? It's worth trying to do
the analysis when we take into account that some bridges are on highly
dynamic IPs (e.g. daily).

What's the process by which we sanitize them? It seems that a fine
solution would be to hash the IP addresses keyed with a secret that
remains constant across the hashes. So you could tell if the IP addresses
are the same without being able to tell what they are. The main challenge
there is keeping the secret somewhere secret in between batches (and
maybe rotating the secret monthly, for some level of forward secrecy).

> Another minor issue that Roger told me is that the bridge authority
>assigns the Stable flag to almost every bridge. If there was a sane way
>of assigning the Stable flag and we gave out, say, at least 1 bridge
>with the Stable flag, would this improve availability? This is rather
>hard to simulate. Maybe we should fix the Stable flag for bridges and
>run this analysis a second time as soon as we have some data. So many
>things to fix...

Yep. If we want to get even more ambitious, we might want to revive
Nick's proposal 146, "Add new flag to reflect long-term stability".


More information about the tor-dev mailing list