[freehaven-cvs] edits in sec6

[arma@seul.org (Roger Dingledine)]

Update of /home/freehaven/cvsroot/doc/routing-zones
In directory moria.mit.edu:/home2/arma/work/freehaven/doc/routing-zones

Modified Files:
	routing-zones.tex 
Log Message:
edits in sec6


Index: routing-zones.tex
===================================================================
RCS file: /home/freehaven/cvsroot/doc/routing-zones/routing-zones.tex,v
retrieving revision 1.58
retrieving revision 1.59
diff -u -d -r1.58 -r1.59
--- routing-zones.tex	29 Jan 2004 05:58:58 -0000	1.58
+++ routing-zones.tex	29 Jan 2004 06:29:40 -0000	1.59
@@ -600,8 +600,9 @@
 and how these properties would change in response to an increased number
 and diversity of mix nodes.  This analysis is independent of our model
 for mix network users (i.e., senders and receivers), since we are only
-examining properties of the mix nodes themselves.  (To the extent
-possible, a user should try to minimize the ASes that can observe
+examining properties of the mix nodes themselves.  (In addition to
+worrying about endpoints,
+we should try to minimize the cases where one AS can observe
 multiple links along a mix network path.)  Next, we compute the
 probability that the AS-level path from the sender to the entry node and
 the path from the exit node to the receiver traverse the same AS (i.e.,
@@ -750,12 +751,12 @@
 the length of a mix network path increases, the likelihood that an AS
 will be able to observe the path at more than one location
 increases.  To test this hypothesis, we generated random mix paths through
-the mix network. Using both the \emph{remailer} node selection
-algorithm and the \emph{onion routing} algorithm, and varying lengths from
+the mix network. Using both the \emph{remailer} and \emph{onion routing}
+node selection algorithms, and varying lengths from
 two hops to eight hops, we measured the probability that
 a path crosses the same AS on multiple links.  For each length and
-type of path, we ran 10,000 trials and counted the number of times the
-mix network path traversed the same AS more than once.
+type of path, we ran 10,000 trials. % and counted the number of times the
+%mix network path traversed the same AS more than once.
 
 %% \footnotetext{The fraction is lower for 4-hop (i.e., 3-link) paths than
 %%   for 5-hop paths as an artifact of discretization: ``at least $3/4$ of
@@ -803,7 +804,7 @@
 node to be used only once (``without replacement'', as in {\em onion
 routing}).  Figure~\ref{fig:as_observe} shows two interesting results.
 First, for all mix paths shorter than four hops, a single AS can observe
-all of of the links on the mix network path.  Second, Tor's node
+all of the links on the mix network path.  Second, Tor's node
 selection algorithm (i.e., the onion routing scheme) provides
 significant protection against observation at multiple links, but this
 node selection scheme helps the Mixmaster topology less.  For example, a four-hop
@@ -889,12 +890,12 @@
 of times the path from the sender to the entry node traversed at least
 one AS on both paths.  Tables~\ref{tab:as_obs_ee_tor}
 and~\ref{tab:as_obs_ee_mm} show the probability, for each sender and
-receiver, of this event.  The table also shows the AS
-that was traversed upon both entry and exit most often.  We see that
+receiver, of this event. We see that
 each pair of sender and receiver has at least some subset of entry and
 exit paths that traverse the same AS upon both entry and exit.
-Additionally, for all sender/receiver pairs, the AS that was traversed
-upon both entry and exit most often was {\em always} a tier-1 ISP.
+Upon further investigation, we learned that the AS that was traversed
+%Additionally, for all sender/receiver pairs, the AS that was traversed
+on both entry and exit most often was {\em always} a tier-1 ISP.
 
 These results suggest that the sender in a mix network should exercise
 care when selecting entry and exit nodes to avoid choosing entry and

***********************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe freehaven-cvs       in the body. http://freehaven.net/