[tor-dev] Extending BridgeDB to reallocate bridges from a blocked country to others that do not block.

[Roger Dingledine]

On Sun, Jan 15, 2012 at 09:34:49AM -0800, Aaron wrote:
>  This proposal outlines the required changes for BridgeDB to reallocate bridges
>  from a blocked country to others that do not block.

I guess I'll be the grumpy one here, but: doesn't bridgedb already do
that, just based on how it picks its answers? Or are we trying to load
balance by giving out bridges-blocked-in-China more commonly to Saudi
users? I'm missing the big picture goals here.

> Current Status:
> 
>   Presently, BridgeDB does not allocate bridges to specific countries. The
>   HTTPS distributor divides bridges into a cluster of rings. Requests for
>   bridges are mapped to a single ring in the cluster using the class C network
>   of the client, so that the IPv4 space is divided amongst the rings in the
>   cluster (presently 4 rings). For an attacker to obtain the complete set of
>   bridges she must control a number of IP addresses in diverse networks. The
>   email based distributor uses a single ring, and bridge buckets are dumped
>   from a single pool of unallocated bridges.

Ok.

> Required modifications:
> 
>   1. BridgeDB must be able to produce an unblocked set of bridges for a
>      specific country, if these bridges are available.

Ok. Though I'd be nervous about enabling this functionality for normal
users, since it makes "ask for some bridges, block them; wait for bridgedb
to notice; ask for new bridges, block them" easier.

>   2. If a bridge is blocked in a country, it must be available to users in
>      other countries.

Why does this need a modification? It is already the case, right?

>   BridgeDB could be modified to assign bridges to geographic regions. To do so,
>   the cluster concept must be extended to support 'geographic clusters' of
>   bridges that correspond to a set of country codes, so that requests will be
>   directed to a corresponding cluster, by either automatic geoip detection or
>   by client choice.

If the client can specify what country he wants to ask about, that makes
the above enumeration attack even more effective.

>   Alternately, BridgeDB could be modified to guarantee that a client requesting
>   unblocked bridges for a region would receive these bridges, if unblocked
>   bridges exist. Presently, patches exist for BridgeDB that mark known blocked
>   bridges as "Might be blocked", but makes no further effort to respond with
>   unblocked bridges, even if those bridges exist.

Right -- I thought we considered that a feature. We are telling the user
that we think the bridges we're giving them won't work, and we're not
giving them replacements because that would accelerate the defeat of
the rate limiting goals.

> Proposed Solution 1
> 
>   Modify BridgeDB to assign bridges to geographic regions. Regions are
>   designated by a list of country codes.  Regions should be balanced in size,
>   or proportional to the number of bridge users. If a bridge is blocked in a
>   region, the bridge should be reallocated to another region. Bridges for a
>   region are stored in a cluster of rings.
> 
> Pitfalls
> 
>   Bridges assigned to one geographic area are not available to clients
>   requesting bridges from other regions.
> 
> Possible Solution 2
> 
>   Modify BridgeDB to dynamically produce rings of bridges 'Not blocked in' a
>   specified country. Bridges are not mapped to a specific country or region,
>   but BridgeDB's response would contain only unblocked bridges (if available).

Again, some security analysis would be good here: in what situations
are we expecting this to be a good idea?

--Roger