[freehaven-cvs] tweaks and last minute fixes

[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:
	network-tables.tex routing-zones.ps routing-zones.tex 
Log Message:
tweaks and last minute fixes


Index: network-tables.tex
===================================================================
RCS file: /home/freehaven/cvsroot/doc/routing-zones/network-tables.tex,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -d -r1.9 -r1.10
--- network-tables.tex	15 Jun 2004 18:28:55 -0000	1.9
+++ network-tables.tex	18 Jun 2004 04:02:27 -0000	1.10
@@ -103,7 +103,7 @@
 {\bf nymip} & {\bf 66.92.0.206} & {\bf US} & {\bf 23504 (Speakeasy Inc)} \\ 
 {\bf peerfear} & {\bf 66.93.132.237} & {\bf US} & {\bf 23504 (Speakeasy Inc)} \\ 
 {\bf metacolo} & {\bf 193.111.87.20} & {\bf US} & {\bf 24812 (MetaColo AS)} \\ 
-{\bf ned} & {\bf 80.190.251.24} & {\bf Germany} & {\bf 24900 (IPX Server)} \\ 
+{\bf ned} & {\bf 80.190.251.24} & {\bf DE} & {\bf 24900 (IPX Server)} \\ 
 {\bf petra} & {\bf 69.20.9.201} & {\bf US} & {\bf 27357 (Rackspace.com)} \\ 
 {\bf TheoryOrg} & {\bf 64.147.163.247} & {\bf US} & {\bf 29752 (SFcolocation)} \\ 
 {\bf incognito} & {\bf 199.173.10.10} & {\bf US} & {\bf 29944 (PullThePlug Technologies LLC)} \\ 

Index: routing-zones.ps
===================================================================
RCS file: /home/freehaven/cvsroot/doc/routing-zones/routing-zones.ps,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- routing-zones.ps	29 Jan 2004 09:08:20 -0000	1.1
+++ routing-zones.ps	18 Jun 2004 04:02:27 -0000	1.2
@@ -1,15 +1,15 @@
 %!PS-Adobe-2.0
 %%Creator: dvips(k) 5.86 Copyright 1999 Radical Eye Software
 %%Title: routing-zones.dvi
-%%Pages: 19
+%%Pages: 18
 %%PageOrder: Ascend
 %%BoundingBox: 0 0 612 792
 %%DocumentFonts: Helvetica
 %%EndComments
 %DVIPSWebPage: (www.radicaleye.com)
-%DVIPSCommandLine: dvips -t letter routing-zones.dvi -o routing-zones.ps
[...7209 lines suppressed...]
+871 3070 V 198 w(66.93.132.237)p 1498 3070 V 113 w(US)p
+1799 3070 V 183 w(23504)j(\(Sp)r(eak)n(easy)d(Inc\))p
+3561 3070 V 356 3161 V 370 3134 a(metacolo)p 871 3161
+V 171 w(193.111.87.20)p 1498 3161 V 113 w(US)p 1799 3161
+V 183 w(24812)j(\(MetaColo)f(AS\))p 3561 3161 V 356 3253
+V 370 3225 a(ned)p 871 3253 V 375 w(80.190.251.24)p 1498
+3253 V 113 w(DE)p 1799 3253 V 174 w(24900)h(\(IPX)f(Serv)n(er\))p
+3561 3253 V 356 3344 V 370 3317 a(p)r(etra)p 871 3344
+V 309 w(69.20.9.201)p 1498 3344 V 201 w(US)p 1799 3344
+V 183 w(27357)h(\(Rac)n(kspace.com\))p 3561 3344 V 356
+3435 V 370 3408 a(TheoryOrg)p 871 3435 V 89 w(64.147.163.247)p
+1498 3435 V 69 w(US)p 1799 3435 V 183 w(29752)g(\(SFcolo)r(cation\))p
+3561 3435 V 356 3527 V 370 3499 a(incognito)p 871 3527
+V 163 w(199.173.10.10)p 1498 3527 V 113 w(US)p 1799 3527
+V 183 w(29944)g(\(PullThePlug)h(T)-7 b(ec)n(hnologies)29
+b(LLC\))p 3561 3527 V 358 3530 3205 4 v Black 1919 5442
+a Fr(18)p Black eop
 %%Trailer
 end
 userdict /end-hook known{end-hook}if

Index: routing-zones.tex
===================================================================
RCS file: /home/freehaven/cvsroot/doc/routing-zones/routing-zones.tex,v
retrieving revision 1.75
retrieving revision 1.76
diff -u -d -r1.75 -r1.76
--- routing-zones.tex	18 Jun 2004 00:09:24 -0000	1.75
+++ routing-zones.tex	18 Jun 2004 04:02:27 -0000	1.76
@@ -71,7 +71,7 @@
 networks like Onion Routing~\cite{tor-design,or-jsac98} are more directly
 vulnerable: an eavesdropper on both ends of the connection can quickly
 link sender to recipient through packet counting or timing attacks
-\cite{defensive-dropping,SS03,danezis-pet2004}.
+\cite{danezis-pet2004,defensive-dropping,SS03}.
 
 Anonymity designs use three major strategies to mitigate these attacks.
 \begin{tightlist}
@@ -94,7 +94,7 @@
 the overlay
 topology so messages can enter or exit at more places in the network
 (compared to a cascade topology~\cite{disad-free-routes});
-or by \emph{location arbitrage} --- coordinating network behavior
+and by \emph{location arbitrage} --- coordinating network behavior
 so each transaction is spread over multiple jurisdictions.
 
 In this paper, we investigate a variant of location arbitrage that
@@ -117,7 +117,7 @@
 that node selection algorithms that look only at IP prefixes, such as
 those used in
 Tarzan~\cite{freedman:ccs02} and MorphMix~\cite{morphmix:fc04}, are
-likely to be ineffective at achieving location independence.
+likely to be less effective at achieving location independence.
 
 Next, we measure the location independence of paths inside
 the mix network. We find that for short paths, given existing mix
@@ -446,7 +446,7 @@
 with the route that is the longest prefix match for $i+1$'s IP address.
 
 Unfortunately, Alice cannot ask for routing tables for
-each of the mix nodes when constructing a mix tunnel.  
+each of the mix nodes when constructing a mix tunnel.
 First, her act of requesting a routing table from a particular network
 might attract the attention of an eavesdropper, particularly if she asks
 for a large number of routing tables. Second, asking each network that
@@ -454,19 +454,17 @@
 slow, since each full routing table is approximately 10 megabytes;
 additionally, as routes are continually changing, parts of the table are
 likely to be out-of-date even before she requests it.  Third, this
-method introduces another vulnerability to attack: if an adversary
-compromises any of the domains that contain a mix node, he could send
+method introduces another vulnerability to attack: an adversary who
+compromises any of the domains that contain a mix node could send
 back an inaccurate version of the routing table. 
 
-Although active measurement tools such as ``traceroute'' are generally
-useful for discovering AS-level paths, the {\em active measurement}
-activity required to these paths is not acceptable; further, performing
-these measurements would not be robust against single compromised nodes.
-For example, the mix network operator could execute traceroutes between
-each pair of mix nodes to determine the IP-level paths (and, hence, the
-AS-level paths) between them.  Although this technique could be
-effective for determining the AS-level paths within the mix network,
-Alice must {\em also} know the AS-level path between herself and the mix
+\emph{Active measurement} tools such as ``traceroute'' could also be
+used to discover AS-level paths. For example, the mix network operator
+could execute traceroutes between each pair of mix nodes to determine the
+IP-level paths (and, hence, the AS-level paths) between them. First, note
+that these measurements would not be robust against single compromised
+mixes. More importantly, however, Alice must \emph{also} determine the
+AS-level path between herself and the mix
 entry she selects, as well as the AS-level path between the mix exit she
 selects and the destination where she is sending packets.  To discover
 the AS-level path between herself and a good candidate mix node, Alice
@@ -488,14 +486,14 @@
 without having visibility into the routing tables of each hop in her
 intended mix path.  Fortunately, examining the AS paths in a BGP routing
 table gives a reasonable estimation of %the Internet's AS-level topology
-(i.e., what ASes connect to what other ASes and can provide reasonable
+what ASes connect to what other ASes, and can provide reasonable
 information about what path an arbitrary Internet host might take to
 reach any given destination.
 %Mao {\em et al.} have recently developed
 %similar techniques for passively determining AS-level paths between two
 %Internet hosts~\cite{Mao2004}, given a view of the AS-level topology.
 
-We now summarize AS-level path estimation technique, which is based on
+We now summarize an AS-level path estimation technique that is based on
 the technique recently proposed by Mao {\em et al.}\cite{Mao2004}
 Although it is admittedly impossible to determine an AS's routing policy
 with absolute certainty, Mao's work suggests that inferring AS-level
@@ -568,7 +566,7 @@
   that prefers the shortest AS path that is consistent with the best
   common practice of preferring customer routes over peering routes and
   peering routes over provider routes.  Mao {\em et al.}'s algorithm
-  suggest that this assumption is reasonable.
+  suggests that this assumption is reasonable.
 
 \vspace{0.1in}
   As AS-level path estimation techniques improve,
@@ -586,7 +584,7 @@
 Mixmaster nodes, and we wanted to directly compare the Tor and Mixmaster
 networks. As part of our future work, we plan to use {\tt 
 traceroute} to measure pairwise paths on the Tor network and compare the
-accuracy AS-level estimations that Alice would make using this technique
+accuracy of the AS-level estimations that Alice would make using this technique
 against the ``ground truth''.}
 %For example, we can determine if a mix network
 %path will traverse the same AS twice (i.e., at two different hops along
@@ -713,7 +711,7 @@
 operated by {\em volunteers}, many of whom commonly operate mix nodes
 from their Internet connections at home (i.e., DSL providers, etc.).
 However, the fact that both of these networks have multiple duplicated
-jurisdictions suggests that users of these mix
+ASes suggests that users of these mix
 networks should exercise caution when selecting mix nodes (particularly
 the entry and exit nodes).
 
@@ -734,15 +732,14 @@
 these pairs (those in ASes 3269, 7132, and 23504) not only have distinct
 {\tt /16} prefixes, they also have distinct {\tt /8} prefixes.
 Similarly, one of the Tor network nodes in AS 23504 has a distinct {\tt
-/16} prefix.  Thus, to achieve location
+/8} prefix.  Thus, to achieve location
 independence, a mix network must explicitly consider the actual AS of
 a host, not simply its IP address.
 
-Finally, we note that all of the Tor network's exit nodes are currently
+Finally, we note that many of the Tor network's exit nodes are currently
 located in the United States.  In practice, this network could achieve
 greater location independence by increasing exit node
-participation outside of the US.  
-
+participation outside of the US.
 
 \subsubsection{Path properties}
 \begin{table}[t]
@@ -892,7 +889,7 @@
 all mix paths shorter than four hops, a single AS can observe all of the
 links in the mix network path.  Second, Tor's node selection algorithm
 (i.e., the onion routing scheme) provides significant protection against
-observation at multiple links for both the the Tor and Mixmaster network
+observation at multiple links for both the Tor and Mixmaster network
 topologies.  For example, a four-hop path constructed from Tor nodes
 without node replacement will be observed by a single AS on all links
 with probability 0.10, whereas a four-hop path constructed with node
@@ -1264,7 +1261,7 @@
 
 To do this, we generated 10,000 random entry and exit pairs
 for each network and, for each sender/receiver pair, observed the number
-of times the path from the sender to the entry node traversed at least one
+of times the path from the sender to the entry node traversed at least
 one AS on both paths; we performed this analysis for both forward and
 reverse paths through the mix network.  Tables~\ref{tab:as_obs_ee_tor}
 and~\ref{tab:as_obs_ee_mm} show the probability, for each sender and
@@ -1436,7 +1433,7 @@
   even when the initiator chooses distinct entry and exit nodes, a
   single AS will often be able to observe both the entry and exit path
   to the mix network between 10\% and 30\% of the time.  Because of path
-  asymmetry in the Internet, a entry/exit node pair that has good
+  asymmetry in the Internet, an entry/exit node pair that has good
   location independence for a forward path through the mix network may
   not always have good location independence in the reverse direction.
   However, if the initiator chooses entry and exit nodes with location

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