[or-cvs] Router twins described in intro. Some more stuff in assumpt...

[syverson@seul.org]

Update of /home/or/cvsroot/doc
In directory moria.mit.edu:/tmp/cvs-serv2554

Modified Files:
	tor-design.tex 
Log Message:
Router twins described in intro. Some more stuff in assumptions section.


Index: tor-design.tex
===================================================================
RCS file: /home/or/cvsroot/doc/tor-design.tex,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -d -r1.16 -r1.17
--- tor-design.tex	22 Oct 2003 18:58:44 -0000	1.16
+++ tor-design.tex	22 Oct 2003 22:40:30 -0000	1.17
@@ -168,7 +168,20 @@
 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 @@
 
 \SubSection{Assumptions}
 
-All dirservers are honest and trusted.
+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 compromised. In some circumstances, e.g., if the Tor network
-is running on a hardened network where all operators have had careful
+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?]