[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[freehaven-cvs] more cleaning
Update of /home/freehaven/cvsroot/doc/rta04
In directory moria.mit.edu:/home2/arma/work/freehaven/doc/rta04
Modified Files:
nato-rta04.tex
Log Message:
more cleaning
it's now a fine first early draft
Index: nato-rta04.tex
===================================================================
RCS file: /home/freehaven/cvsroot/doc/rta04/nato-rta04.tex,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -d -r1.5 -r1.6
--- nato-rta04.tex 8 Jan 2004 06:39:15 -0000 1.5
+++ nato-rta04.tex 8 Jan 2004 07:03:28 -0000 1.6
@@ -218,9 +218,7 @@
activities); and must not be difficult or expensive to implement (for
example, by requiring kernel patches, or separate proxies for every
protocol). We also cannot require non-anonymous parties (such as
-websites) to run our software. (Our rendezvous point design does not
-meet this goal for non-anonymous users talking to hidden servers,
-however; see Section~\ref{sec:rendezvous}.)
+websites) to run our software.
\textbf{Usability:} A hard-to-use system has fewer users---and because
anonymity systems hide users among users, a system with fewer users
@@ -327,10 +325,10 @@
try to decrease the network's reliability by attacking nodes or by
performing antisocial activities from reliable servers and trying to
get them taken down; making the network unreliable flushes users to
-other less anonymous systems, where they may be easier to attack.
-The Tor design provides various protections against these various threats.
-Discussion of how well the Tor design defends
-against each of these attacks is presented in \cite{tor-design}.
+other less anonymous systems, where they may be easier to attack.
+%The Tor design provides various protections against these various threats.
+%Discussion of how well the Tor design defends
+%against each of these attacks is presented in \cite{tor-design}.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@@ -449,11 +447,6 @@
\subsection{Exit policies and abuse}
\label{subsec:exitpolicies}
-% originally, we planned to put the "users only know the hostname,
-% not the IP, but exit policies are by IP" problem here too. Not
-% worth putting in the submission, but worth thinking about putting
-% in sometime somehow. -RD
-
Exit abuse is a serious barrier to wide-scale Tor deployment. Anonymity
presents would-be vandals and abusers with an opportunity to hide
the origins of their activities. Attackers can harm the Tor network by
@@ -466,8 +459,6 @@
and other attackers already have access to thousands of misconfigured
systems worldwide, and the Tor network is far from the easiest way
to launch antisocial or illegal attacks.
-%Indeed, because of its limited
-%anonymity, Tor is probably not a good way to commit crimes.
But because the
onion routers can easily be mistaken for the originators of the abuse,
and the volunteers who run them may not want to deal with the hassle of
@@ -494,16 +485,14 @@
in-band network status updates: each router flooded a signed statement
to its neighbors, which propagated it onward. But anonymizing networks
have different security goals than typical link-state routing protocols.
-For example, delays (accidental or intentional)
-that can cause different parts of the network to have different views
-of link-state and topology are not only inconvenient: they give
-attackers an opportunity to exploit differences in client knowledge.
-We also worry about attacks to deceive a
-client about the router membership list, topology, or current network
-state. Such \emph{partitioning attacks} on client knowledge help an
-adversary to efficiently deploy resources
-against a target \cite{minion-design}.
-
+For example, delays (accidental or intentional) that can cause different
+parts of the network to have different views of link-state and topology
+are not only inconvenient: they give attackers an opportunity to
+exploit differences in client knowledge. We also worry about attacks to
+deceive a client about the router membership list, topology, or current
+network state. Such \emph{partitioning attacks} on client knowledge
+help an adversary to efficiently deploy resources against a target
+\cite{minion-design}.
Tor uses a small group of redundant, well-known onion routers to
track changes in network topology and node state, including keys and
@@ -523,8 +512,8 @@
Flooding is expensive, and complicates the analysis when we
start experimenting with non-clique network topologies. Signed
directories can be cached by other
-onion routers.
-Thus directory servers are not a performance
+onion routers, so
+directory servers are not a performance
bottleneck when we have many users, and do not aid traffic analysis by
forcing clients to periodically announce their existence to any
central point.
@@ -550,7 +539,6 @@
A social attacker who offers an illegal or disreputable location-hidden
service should not be able to ``frame'' a rendezvous router by
making observers believe the router created that service.
-%slander-resistant? defamation-resistant?
\textbf{Application-transparent:} Although we require users
to run special software to access location-hidden servers, we must not
require them to modify their applications.
@@ -574,14 +562,13 @@
The extra level of indirection also allows Bob to respond to some requests
and ignore others.
-
\subsection{Integration with user applications}
-Bob configures his onion proxy to know the local IP address and port of his
-service, a strategy for authorizing clients, and a public key. Bob
-publishes the public key, an expiration time (``not valid after''), and
-the current introduction points for his service into the DHT, indexed
-by the hash of the public key. Bob's webserver is unmodified,
+Bob configures his onion proxy to know the local IP address and port of
+his service, a strategy for authorizing clients, and a public key. Bob
+publishes the public key, an expiration time (``not valid after''),
+and the current introduction points for his service into the DHT,
+indexed by the hash of the public key. Bob's webserver is unmodified,
and doesn't even know that it's hidden behind the Tor network.
Alice's applications also work unchanged---her client interface
@@ -594,8 +581,6 @@
examines addresses; if they're destined for a hidden server, it decodes
the key and starts the rendezvous as described above.
-
-
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Future Directions}
@@ -630,11 +615,6 @@
traffic and long-range cover traffic to determine whether some simple padding
method offers provable protection against our chosen adversary.
-%%\emph{Offer two relay cell sizes:} Traffic on the Internet tends to be
-%%large for bulk transfers and small for interactive traffic. One cell
-%%size cannot be optimal for both types of traffic.
-% This should go in the spec and todo, but not the paper yet. -RD
-
\emph{Caching at exit nodes:} Perhaps each exit node should run a
caching web proxy, to improve anonymity for cached pages (Alice's request never
leaves the Tor network), to improve speed, and to reduce bandwidth cost.
***********************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe freehaven-cvs in the body. http://freehaven.net/