From 5bee80ec1a5604abea7fec54091a197a82b7e312 Mon Sep 17 00:00:00 2001 From: Roger Dingledine Date: Fri, 31 Oct 2003 06:16:21 +0000 Subject: [PATCH] formatting and partial typo fixing svn:r697 --- doc/tor-design.tex | 63 +++++++++++++++++++++++++--------------------- 1 file changed, 35 insertions(+), 28 deletions(-) diff --git a/doc/tor-design.tex b/doc/tor-design.tex index d0b260f618..5493607b1f 100644 --- a/doc/tor-design.tex +++ b/doc/tor-design.tex @@ -251,10 +251,11 @@ are no longer required. deploying isn't there yet, and not all features are implemented. Mention that it runs, is kinda alpha, kinda deployed, runs on win32.] -We review previous work in Section \ref{sec:background}, describe -our goals and assumptions in Section \ref{sec:assumptions}, -and then address the above list of improvements in Sections -\ref{sec:design}-\ref{sec:maintaining-anonymity}. We then summarize +We review previous work in Section~\ref{sec:background}, describe +our goals and assumptions in Section~\ref{sec:assumptions}, +and then address the above list of improvements in +Sections~\ref{sec:design}-\ref{sec:maintaining-anonymity}. We then +summarize how our design stands up to known attacks, and conclude with a list of open problems. @@ -416,7 +417,7 @@ cebolla\\ \Section{Design goals and assumptions} \label{sec:assumptions} -\subsection{Goals} +\SubSection{Goals} Like other low-latency anonymity designs, Tor seeks to frustrate attackers from linking communication partners, or from linking multiple communications to or from a single point. Within this @@ -484,7 +485,7 @@ Tor's evolution. % This last bit sounds completely cheesy. Somebody should tone it down. -NM \end{description} -\subsection{Non-goals} +\SubSection{Non-goals} In favoring conservative, deployable designs, we have explicitly deferred a number of goals. Many of these goals are desirable in anonymity systems, but we choose to defer them either because they are solved elsewhere, @@ -499,8 +500,8 @@ accepted solution. conservative design. \item[Not secure against end-to-end attacks:] Tor does not claim to provide a definitive solution to end-to-end timing or intersection attacks. Some - approaches, such as running an onion router, may help; see Section - \ref{sec:analysis} for more discussion. + approaches, such as running an onion router, may help; see + Section~\ref{sec:analysis} for more discussion. \item[No protocol normalization:] Tor does not provide \emph{protocol normalization} like Privoxy or the Anonymizer. In order to make clients indistinguishable when they use complex and variable protocols such as HTTP, @@ -697,9 +698,9 @@ any special privileges. Currently, each OR maintains a long-term TLS connection to every other OR. (We examine some ways to relax this clique-topology assumption in -section \ref{subsec:restricted-routes}). A subset of the ORs also act as +Section~\ref{subsec:restricted-routes}.) A subset of the ORs also act as directory servers, tracking which routers are currently in the network; -see section \ref{subsec:dirservers} for directory server details. Users +see Section~\ref{subsec:dirservers} for directory server details. Users run local software called an onion proxy (OP) to fetch directories, establish paths (called \emph{virtual circuits}) across the network, and handle connections from user applications. Onion proxies accept @@ -719,15 +720,15 @@ the identity key of a router is considered equivalent to creating a new router. The onion (decryption) key is used for decrypting requests from users to set up a circuit and negotiate ephemeral keys. Finally, link keys are used by the TLS protocol when communicating between -onion routers. We discuss rotating these keys in Section -\ref{subsec:rotating-keys}. +onion routers. We discuss rotating these keys in +Section~\ref{subsec:rotating-keys}. -Section \ref{subsec:cells} discusses the structure of the fixed-size +Section~\ref{subsec:cells} discusses the structure of the fixed-size \emph{cells} that are the unit of communication in Tor. We describe -in section \ref{subsec:circuits} how virtual circuits are -built, extended, truncated, and destroyed. Section \ref{subsec:tcp} +in Section~\ref{subsec:circuits} how virtual circuits are +built, extended, truncated, and destroyed. Section~\ref{subsec:tcp} describes how TCP streams are routed through the network, and finally -Section \ref{subsec:congestion} talks about congestion control and +Section~\ref{subsec:congestion} talks about congestion control and fairness issues. \SubSection{Cells} @@ -735,24 +736,27 @@ fairness issues. % I think we should describe connections before cells. -NM -Traffic passes from one OR to another, or from a user's OP to an OR, +Traffic passes from one OR to another, or between a user's OP and an OR, in fixed-size cells. Each cell is 256 bytes, and consists of a header and a payload. The header includes an -anonymous circuit identifier (ACI) the specifies which circuit the +anonymous circuit identifier (ACI) that specifies which circuit the +% Should we replace ACI with circID ? What is this 'anonymous circuit' +% thing anyway? -RD cell refers to (many circuits can be multiplexed over the single TCP connection between ORs or between an OP and an OR), and a command to describe what to do with the cell's payload. Cells are either \emph{control} cells, which are interpreted by the node that receives them, or \emph{relay} cells, -whichcarry end-to-end stream data. Controls cells can be one of: +which carry end-to-end stream data. Controls cells can be one of: \emph{padding} (currently used for keepalive, but also usable for link padding); \emph{create} or \emph{created} (used to set up a new circuit); or \emph{destroy} (to tear down a circuit). % We need to say that ACIs are connection-specific: each circuit has % a different ACI along each connection. -NM +% agreed -RD Relay cells have an additional header (the relay header) after the -cell header, containing a the stream identifier (many streams can +cell header, containing the stream identifier (many streams can be multiplexed over a circuit); an end-to-end checksum for integrity checking; the length of the relay payload; and a relay command. Relay commands can be one of: \emph{relay @@ -876,8 +880,9 @@ When Alice's application wants to open a TCP connection to a given address and port, it asks the OP (via SOCKS) to make the connection. The OP chooses the newest open circuit (or creates one if none is available), chooses a suitable OR on that circuit to be the exit node (usually the -last node, but maybe others due to exit policy conflicts; see Section -\ref{sec:exit-policies}), chooses a new random stream ID for this stream, +last node, but maybe others due to exit policy conflicts; see +Section~\ref{sec:exit-policies}), chooses a new random stream ID for +this stream, and delivers a relay begin cell to that exit node. It uses a stream ID of zero for the begin cell (so the OR will recognize it), and the relay payload lists the new stream ID and the destination address and port. @@ -939,7 +944,7 @@ length (or pad to some max path length).}, we choose to % accept passive timing attacks, % (How? I don't get it. Do we mean end-to-end traffic % confirmation attacks? -NM) -and preform integrity +and perform integrity checking only at the edges of the circuit. When Alice negotiates a key with the exit hop, they both start a SHA-1 with some derivative of that key, thus starting out with randomness that only the two of them know. From @@ -1052,7 +1057,7 @@ the ability to drop cells when we're full and retransmit later, etc), because the TCP streams already guarantee in-order delivery of each cell. But we need to investigate further the effects of the current parameters on throughput and latency, while also keeping privacy in mind; -see Section \ref{sec:maintaining-anonymity} for more discussion. +see Section~\ref{sec:maintaining-anonymity} for more discussion. \Section{Other design decisions} @@ -1355,7 +1360,7 @@ to special users. When those mirrors are knocked down by DDoS attacks, those special users can switch to accessing Bob's service via the Tor rendezvous system. -\subsection{Integration with user applications} +\SubSection{Integration with user applications} For each service Bob offers, he configures his local onion proxy to know the local IP and port of the server, a strategy for authorizating Alices, @@ -1664,8 +1669,8 @@ directory agreement algorithm described in \ref{subsec:dirservers}, the directory servers are still trust bottlenecks. We must find more decentralized yet practical ways to distribute up-to-date snapshots of network status without introducing new attacks. -\item \emph{Implementing location-hidden servers:} While Section -\ref{sec:rendezvous} provides a design for rendezvous points and +\item \emph{Implementing location-hidden servers:} While +Section~\ref{sec:rendezvous} provides a design for rendezvous points and location-hidden servers, this feature has not yet been implemented. We will likely encounter additional issues, both in terms of usability and anonymity, that must be resolved. @@ -1679,8 +1684,10 @@ deploying a wider network. We will see what happens! %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -%\Section{Acknowledgments} %% commented out for anonymous submission +%\Section{Acknowledgments} +% Peter Palfrader for editing +% Bram Cohen for congestion control discussions %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -- 2.47.3