[tor-dev] Extending BridgeDB to reallocate bridges from a blocked country to others that do not block.
aagbsn at extc.org
Sun Jan 15 17:34:49 UTC 2012
The following is a draft proposal of changes to BridgeDB to address
"Automated bridge allocation to reallocate bridges from a blocked
country to others that do not block"
This draft proposes two different approaches -- any feedback or
questions are very welcome!
Title: BridgeDB Reallocates Bridges
Author: Aaron Gibson
Created: 15 Jan 2015
This proposal outlines the required changes for BridgeDB to reallocate bridges
from a blocked country to others that do not block.
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.
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
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.
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).
As bridges are not allocated to a specific region, bridges could not be
reserved for distribution to specific regions.
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.
More information about the tor-dev