The following is a draft proposal of changes to BridgeDB to address the deliverable "Automated bridge allocation to reallocate bridges from a blocked country to others that do not block" (https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorE/PhaseThr...)
This draft proposes two different approaches -- any feedback or questions are very welcome!
--Aaron
==== Filename: xxx-bridgedb-reallocates-bridges.txt Title: BridgeDB Reallocates Bridges Author: Aaron Gibson Created: 15 Jan 2015 Status: Draft
Introduction:
This proposal outlines the required changes for BridgeDB to reallocate bridges from a blocked country to others that do not block.
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.
Required modifications:
1. BridgeDB must be able to produce an unblocked set of bridges for a specific country, if these bridges are available.
2. If a bridge is blocked in a country, it must be available to users in other countries.
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.
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.
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).
Pitfalls
As bridges are not allocated to a specific region, bridges could not be reserved for distribution to specific regions.
Common pitfalls
As BridgeDB learns about blocked bridges that it may no longer provide, BridgeDB replaces blocked bridges with good bridges. An attacker with control over addresses from many class C networks could iteratively request and block bridges, until the entire set has been consumed. The rate of consumption could be limited by the rate that blocked bridges are updated, but clients would be more likely to receive a bridge that has been blocked.