[or-cvs] formatting and partial typo fixing
Roger Dingledine
arma at seul.org
Fri Oct 31 06:16:24 UTC 2003
Update of /home/or/cvsroot/doc
In directory moria.mit.edu:/tmp/cvs-serv19353
Modified Files:
tor-design.tex
Log Message:
formatting and partial typo fixing
Index: tor-design.tex
===================================================================
RCS file: /home/or/cvsroot/doc/tor-design.tex,v
retrieving revision 1.41
retrieving revision 1.42
diff -u -d -r1.41 -r1.42
--- tor-design.tex 30 Oct 2003 23:05:40 -0000 1.41
+++ tor-design.tex 31 Oct 2003 06:16:21 -0000 1.42
@@ -251,10 +251,11 @@
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 @@
\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 @@
% 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 @@
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 @@
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 @@
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 @@
% 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 @@
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 @@
% 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 @@
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 @@
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 @@
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 @@
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-%\Section{Acknowledgments}
%% commented out for anonymous submission
+%\Section{Acknowledgments}
+% Peter Palfrader for editing
+% Bram Cohen for congestion control discussions
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
More information about the tor-commits
mailing list