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

[Aaron]

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/PhaseThree)

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.