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:
- 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.
- 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