From 8ee82830b4f68224a62c4707823eb1b00b842d1f Mon Sep 17 00:00:00 2001 From: Paul Syverson Date: Wed, 22 Oct 2003 22:40:30 +0000 Subject: [PATCH] Router twins described in intro. Some more stuff in assumptions section. svn:r661 --- doc/tor-design.tex | 50 +++++++++++++++++++++++++++++++++------------- 1 file changed, 36 insertions(+), 14 deletions(-) diff --git a/doc/tor-design.tex b/doc/tor-design.tex index 07c1776d5a..5dcc28a90a 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. +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?]