Router twins described in intro. Some more stuff in assumptions section.

svn:r661

1 files changed, 38 insertions, 16 deletions

diff --git a/doc/tor-design.tex b/doc/tor-design.tex
index 07c1776d5..5dcc28a90 100644
--- a/doc/tor-design.tex
+++ b/doc/tor-design.tex
@@ -168,7 +168,20 @@ the fly so it connects to a different webserver, or by tagging encrypted
 traffic and looking for traffic at the network edges that has been
 tagged \cite{minion-design}.
 
-\item \textbf{Robustness to node failure:} router twins
+\item \textbf{Robustness to node failure:} Node failure for a
+  low-latency system like Tor is not as serious a problem as it is for
+  a traditional mix network. Nonetheless, simple mechanisms that allow
+  connections to be established despite slightly dated information
+  from a directory server or very recent node failure are useful.  Tor
+  permits onion routers to have router twins. These share the same
+  private decryption key that is used when establishing a connection
+  through the onion router. Note that because of how connections are
+  now established with perfect forward secrecy, this does not
+  automatically mean that an onion router can read the traffic on a
+  connection established through its twin even while that connection
+  is active. Also, which nodes are twins can change dynamically
+  depending on current circumstances, and twins may or may not be
+  under the same administrative authority.
 
 \item \textbf{Exit policies:}
 Tor provides a consistent mechanism for each node to specify and
@@ -545,23 +558,32 @@ tagging attacks
 
 \SubSection{Assumptions}
 
-All dirservers are honest and trusted.
-
-Somewhere between ten percent and twenty percent of nodes
-are compromised. In some circumstances, e.g., if the Tor network
-is running on a hardened network where all operators have had careful
+For purposes of this paper, we assume all directory servers are honest
+and trusted. Perhaps more accurately, we assume that all users and
+nodes can perform their own periodic checks on information they have
+from directory servers and that all will always have access to at
+least one directory server that they trust and from which they obtain
+all directory information. Future work may include robustness
+techniques to cope with a minority dishonest servers.
+
+Somewhere between ten percent and twenty percent of nodes are assumed
+to be compromised. In some circumstances, e.g., if the Tor network is
+running on a hardened network where all operators have had careful
 background checks, the percent of compromised nodes might be much
-lower. Also, it may be worthwhile to consider cases where many
-of the `bad' nodes are not fully compromised but simply (passive)
-observing adversaries. We assume that all adversary components,
-regardless of their capabilities are collaborating and are connected
-in an offline clique.
-
+lower. It may be worthwhile to consider cases where many of the `bad'
+nodes are not fully compromised but simply (passive) observing
+adversaries or that some nodes have only had compromise of the keys
+that decrypt connection initiation requests. But, we assume for
+simplicity that `bad' nodes are compromised in the sense spelled out
+above. We assume that all adversary components, regardless of their
+capabilities are collaborating and are connected in an offline clique.
+
+We do not assume any hostile users, except in the context of
+rendezvous points. Nonetheless, we assume that users vary widely in
+both the duration and number of times they are connected to the Tor
+network. They can also be assumed to vary widely in the volume and
+shape of the traffic they send and receive.
 
-- Threat model
-- Mostly reliable nodes: not trusted.
-- Small group of trusted dirserv ops
-- Many users of diff bandwidth come and go.
 
 [XXX what else?]