On Mon, Jan 30, 2012 at 1:14 AM, Roger Dingledine arma@mit.edu wrote:
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.
No, BridgeDB does not allocate bridges by region, nor is load balancing a concern of this proposal. Presently, bridges are served and available to clients of all countries.
The deliverable "Automated bridge allocation to reallocate bridges from a blocked country to others that do not block" either misunderstands how BridgeDB assigns bridges, or is suggesting that BridgeDB should assign bridges by country.
If bridges are assigned by country, then BridgeDB can limit the addresses that these bridges are exposed to, increasing the bridges/addresses ratio for that region, and potentially reduce the rate that bridges get blocked. When the bridges are blocked, they will be made available to other countries.
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.
This is true, but we can control the rate that bridges are consumed because we control when the blocked bridge list is updated.
And I think the strongest argument for exposing this functionality to normal users is that of usability. How many users are turned away because the bridges don't work or "might be blocked"? A censor can afford to check bridges.tpo continuously and block bridges as it sees them, but a user is more likely to just give up.
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?
Yes, BridgeDB does not allocate bridges to countries. This requirement only makes sense if BridgeDB did allocate bridges to countries.
If the client can specify what country he wants to ask about, that makes the above enumeration attack even more effective.
BridgeDB should probably differentiate between requests coming from the requested region and requests coming from outside the requested region, though legitimate requests and requests for legitimate users are likely to arrive from outside the requested region.
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.
That's been our assumption, but I don't think we have any data as to how serial enumeration compares to parallel enumeration. I do think we can control how fast bridges are burned via the blocked bridge list update. Ideally we'll be able to get an idea of what works and what doesn't experimentally, and use that to guide any improvements we make.
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?
Upon reflection, I think solution 2 is too limited. I am convinced that we do want to be able to assign bridges to specific regions, because our distribution strategy should be customizable for different regions.
There are a few questions I'd like to ask too, in the context of this proposal:
1. Although the number of bridges is limited, that may not always be the case. If we had several orders of magnitude more bridges available, how should our strategy change? Do these changes help?
2. Should we be trying to conserve bridges? What about bridges who may not stick around very long anyway? How long do bridges last, on average?
3. Does limiting the set of addresses (region mapping) that correspond to a set of bridges significantly reduce the ability of a censor to obtain the set of bridges? Via a botnet? Via the national ISP?
4. What about censors who hurt Tor users? Could our distribution strategy change for just those regions? For example, bridges that are handed out a limited number of times, never re-allocated to other countries, etc?
Thanks for your feedback!
--Aaron