start work on the reachability section. more work remains.

svn:r8934

1 files changed, 80 insertions, 50 deletions

diff --git a/doc/design-paper/blocking.tex b/doc/design-paper/blocking.tex
index 08af7f619c..754b453683 100644
--- a/doc/design-paper/blocking.tex
+++ b/doc/design-paper/blocking.tex
@@ -1316,60 +1316,87 @@ community, though, this question remains a critical weakness.
 %not publishing their plans. Our goal here is to produce a design---a
 %framework---that can be public and still secure. Where's the tradeoff?
 
-\section{Performance improvements}
-\label{sec:performance}
-
-\subsection{Fetch server descriptors just-in-time}
-
-I guess we should encourage most places to do this, so blocked
-users don't stand out.
-
-
-network-status and directory optimizations. caching better. partitioning
-issues?
+%\section{Performance improvements}
+%\label{sec:performance}
+%
+%\subsection{Fetch server descriptors just-in-time}
+%
+%I guess we should encourage most places to do this, so blocked
+%users don't stand out.
+%
+%
+%network-status and directory optimizations. caching better. partitioning
+%issues?
 
 \section{Maintaining reachability}
 
 \subsection{How many bridge relays should you know about?}
 
-If they're ordinary Tor users on cable modem or DSL, many of them will
-disappear and/or move periodically. How many bridge relays should a
-blockee know
-about before he's likely to have at least one reachable at any given point?
-How do we factor in a parameter for "speed that his bridges get discovered
-and blocked"?
-
-The related question is: if the bridge relays change IP addresses
-periodically, how often does the bridge user need to "check in" in order
-to keep from being cut out of the loop?
-
-Families of bridges: give out 4 or 8 at once, bound together.
-
-\subsection{Cablemodem users don't provide important websites}
+The strategies described in Section~\ref{sec:discovery} talked about
+learning one bridge address at a time. But if most bridges are ordinary
+Tor users on cable modem or DSL connection, many of them will disappear
+and/or move periodically. How many bridge relays should a blocked user
+know about so that she is likely to have at least one reachable at any
+given point? This is already a challenging problem if we only consider
+natural churn: the best approach is to see what bridges we attract in
+reality and measure their churn. We may also need to factor in a parameter
+for how quickly bridges get discovered and blocked by the attacker;
+we leave this for future work after we have more deployment experience.
+
+A related question is: if the bridge relays change IP addresses
+periodically, how often does the blocked user need to fetch updates in
+order to keep from being cut out of the loop?
+
+Once we have more experience and intuition, we should explore technical
+solutions to this problem too. For example, if the discovery strategies
+give out $k$ bridge addresses rather than a single bridge address, perhaps
+we can improve robustness from the user perspective without significantly
+aiding the adversary. Rather than giving out a new random subset of $k$
+addresses at each point, we could bind them together into \emph{bridge
+families}, so all users that learn about one member of the bridge family
+are told about the rest as well.
+
+This scheme may also help defend against attacks to map the set of
+bridges. That is, if all blocked users learn a random subset of bridges,
+the attacker should learn about a few bridges, monitor the country-level
+firewall for connections to them, then watch those users to see what
+other bridges they use, and repeat. By segmenting the bridge address
+space, we can limit the exposure of other users.
+
+\subsection{Cablemodem users don't usually provide important websites}
 \label{subsec:block-cable}
 
-...so our adversary could just block all DSL and cablemodem networks,
-and for the most part only our bridge relays would be affected.
+Another attacker we might be concerned about is that the attacker could
+just block all DSL and cablemodem network addresses, on the theory that
+they don't run any important services anyway. If most of our bridges
+are on these networks, this attack could really hurt.
 
 The first answer is to aim to get volunteers both from traditionally
 ``consumer'' networks and also from traditionally ``producer'' networks.
-
-The second answer (not so good) would be to encourage more use of consumer
-networks for popular and useful websites.  (But P2P exists; minor websites
-exist; gaming exists; IM exists; ...)
-
-Other attack: China pressures Verizon to discourage its users from
-running bridges.
-
-\subsection{Scanning-resistance}
-
-If it's trivial to verify that we're a bridge, and we run on a predictable
-port, then it's conceivable our attacker would scan the whole Internet
-looking for bridges. (In fact, he can just scan likely networks like
-cablemodem and DSL services---see Section~\ref{block-cable} for a related
-attack.) It would be nice to slow down this attack. It would
-be even nicer to make it hard to learn whether we're a bridge without
-first knowing some secret.
+Since bridges don't need to be Tor exit nodes, as we improve our usability
+it seems quite feasible to get a lot of websites helping out.
+
+The second answer (not as practical) would be to encourage more use of
+consumer networks for popular and useful Internet services. 
+%(But P2P exists;
+%minor websites exist; gaming exists; IM exists; ...)
+
+A related attack we might worry about is based on large countries putting
+economic pressure on companies that want to expand their business. For
+example, what happens if Verizon wants to sell services in China, and
+China pressures Verizon to discourage its users in the free world from
+running bridges?
+
+\subsection{Scanning resistance: making bridges more subtle}
+
+If it's trivial to verify that a given address is operating as a bridge,
+and most bridges run on a predictable port, then it's conceivable our
+attacker could scan the whole Internet looking for bridges. (In fact, he
+can just concentrate on scanning likely networks like cablemodem and DSL
+services---see Section~\ref{block-cable} above for related attacks.) It
+would be nice to slow down this attack. It would be even nicer to make
+it hard to learn whether we're a bridge without first knowing some
+secret. We call this general property \emph{scanning resistance}.
 
 Password protecting the bridges.
 Could provide a password to the bridge user. He provides a nonced hash of
@@ -1377,7 +1404,7 @@ it or something when he connects. We'd need to give him an ID key for the
 bridge too, and wait to present the password until we've TLSed, else the
 adversary can pretend to be the bridge and MITM him to learn the password.
 
-We could some kind of ID-based knocking protocol, or we could act like an
+We could use some kind of ID-based knocking protocol, or we could act like an
 unconfigured HTTPS server if treated like one.
 
 We can assume that the attacker can easily recognize https connections
@@ -1464,14 +1491,17 @@ advantage?
 \subsection{The Tor website: how to get the software}
 
 One of the first censoring attacks against a system like ours is to
-block the website and make the software itself hard to find. After
-all, our system works well once the user is running an authentic
-copy of Tor and has found a working bridge, but up until that point
-we need to rely on their individual skills and ingenuity.
+block the website and make the software itself hard to find. Our system
+should work well once the user is running an authentic
+copy of Tor and has found a working bridge, but to get to that point
+we rely on their individual skills and ingenuity.
+
 Right now, most countries that block access to Tor block only the main
 website and leave mirrors and the network itself untouched.
 Falling back on word-of-mouth is always a good last resort, but we should
-also take steps to make sure it's relatively easy for users to get a copy.
+also take steps to make sure it's relatively easy for users to get a copy,
+such as publicizing the mirrors more and making copies available through
+other media.
 See Section~\ref{subsec:first-bridge} for more discussion.
 
 \section{Future designs}