[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[freehaven-cvs] Make tables 2-column; tighten section headers; bruta...



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

Modified Files:
	endpoint-tables.tex network-tables.tex routing-zones.bib 
	routing-zones.ps routing-zones.tex 
Log Message:
Make tables 2-column; tighten section headers; brutalize bibtex for space constraints.
The appendix is still broken, in that I can't manage to get a 2-column
table to appear right after a 1-column heading.


Index: endpoint-tables.tex
===================================================================
RCS file: /home/freehaven/cvsroot/doc/routing-zones/endpoint-tables.tex,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -d -r1.5 -r1.6
--- endpoint-tables.tex	17 Jun 2004 07:18:45 -0000	1.5
+++ endpoint-tables.tex	25 Aug 2004 11:37:57 -0000	1.6
@@ -1,5 +1,5 @@
-%%\begin{table} [h!]
-\begin{small} 
+\begin{table*}[h!]
+%%\begin{small} 
 %%\label{table:tor-network}
 \begin{center}
 \begin{tabular}{l|lp{2in}|l|l}
@@ -26,5 +26,5 @@
 \vspace{8in}
 \end{tabular}
 \end{center}
-\end{small} 
-%%\end{table}
+%%\end{small}
+\end{table*}

Index: network-tables.tex
===================================================================
RCS file: /home/freehaven/cvsroot/doc/routing-zones/network-tables.tex,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -d -r1.10 -r1.11
--- network-tables.tex	18 Jun 2004 04:02:27 -0000	1.10
+++ network-tables.tex	25 Aug 2004 11:37:57 -0000	1.11
@@ -1,5 +1,5 @@
-%%\begin{table} 
-\begin{small} 
+\begin{table*}
+\begin{small}
 %%\caption{Mixmaster nodes as of June 2004}
 %%\label{table:tor-network}
 \begin{center}
@@ -62,8 +62,8 @@
 \end{tabular}
 \end{center}
 \end{small} 
-%%\end{table}
-%%\begin{table} 
+\end{table*}
+\begin{table*} 
 \begin{small} 
 %%\caption{Tor nodes as of June 2004}
 %%\label{table:tor-network}
@@ -110,5 +110,5 @@
 \hline
 \end{tabular}
 \end{center}
-\end{small} 
-%%\end{table}
+\end{small}
+\end{table*}

Index: routing-zones.bib
===================================================================
RCS file: /home/freehaven/cvsroot/doc/routing-zones/routing-zones.bib,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -d -r1.20 -r1.21
--- routing-zones.bib	17 Jun 2004 06:50:37 -0000	1.20
+++ routing-zones.bib	25 Aug 2004 11:37:57 -0000	1.21
@@ -17,7 +17,7 @@
   booktitle =    {Designing Privacy Enhancing Technologies: Workshop
                   on Design Issue in Anonymity and Unobservability},
    editor =       {H. Federrath},
-   publisher =    {Springer-Verlag, LNCS 2009},
+   publisher =    {LNCS 2009},
    pages =       {115--129},
    year =        {2000},
 }
@@ -27,7 +27,6 @@
   author = {Adam Back and Ian Goldberg and Adam Shostack}, 
   institution = {Zero Knowledge Systems, {Inc.}}, 
   year = {2001}, 
-  month = {May}, 
   type = {White Paper}, 
 }
 
@@ -71,7 +70,7 @@
   author = {Ceki G\"ulc\"u and Gene Tsudik}, 
   booktitle = {{Network and Distributed Security Symposium (NDSS 96)}}, 
   year = 1996, 
-  month = {February}, 
+  month = {Feb}, 
   pages = {2--16}, 
   publisher = {IEEE}, 
 }
@@ -95,7 +94,7 @@
   pages =        {245--257},
   year =         2001,
   editor =       {Ira S. Moskowitz},
-  publisher =    {Springer-Verlag, LNCS 2137},
+  publisher =    {LNCS 2137},
 }
 
 @InProceedings{raymond00,
@@ -106,12 +105,10 @@
                   on Design Issue in Anonymity and Unobservability},
   year =         2000,
   month =        {July},
-  pages =        {10-29},
   editor =       {H. Federrath},
-  publisher =    {Springer-Verlag, LNCS 2009},
+  publisher =    {LNCS 2009},
 }
 
-
 @inproceedings{minion-design,
   title = {Mixminion: Design of a Type {III} Anonymous Remailer Protocol},
   author = {George Danezis and Roger Dingledine and Nick Mathewson},
@@ -169,7 +166,7 @@
   booktitle =    {Information Hiding (IH 2002)},
   year =         {2002},
   editor =       {Fabien Petitcolas},
-  publisher =    {Springer-Verlag, LNCS 2578},
+  publisher =    {LNCS 2578},
 }
 
 @misc{pipenet,
@@ -178,8 +175,7 @@
   year = 1996,
   month = {August},
   howpublished = {Usenet post},
-  note = {\url{http://www.eskimo.com/~weidai/pipenet.txt} First mentioned
-      in a post to the cypherpunks list, Feb.\ 1995.},
+  note = {\url{http://www.eskimo.com/~weidai/pipenet.txt}}
 }
 
 @inproceedings{econymics,
@@ -260,7 +256,7 @@
   year = {2003},
   month = {March},
   editor = {Roger Dingledine},
-  publisher = {Springer-Verlag, LNCS 2760},
+  publisher = {LNCS 2760},
   www_ps_url = {http://www.ovmj.org/GNUnet/download/aff.ps},
   www_section = {Anonymous publication},
 }
@@ -269,7 +265,7 @@
   author= "Y. Rekhter and T. Li",
   title="{A Border Gateway Protocol 4 (BGP-4)}",
   note = {RFC 1771},
-  organization = "{Internet Engineering Task Force}",
+  organization = "{IETF}",
   year=1995,
   mon=mar,
 }
@@ -330,8 +326,7 @@
     title = "Tarzan: A Peer-to-Peer Anonymizing Network Layer",
     author = "Michael J. Freedman and Robert Morris",
     booktitle = "Proceedings of the 9th {ACM} {C}onference on {C}omputer and {C}ommunications {S}ecurity",
-    address = "Washington, D.C.",
-    month = nov,
+    month = "Nov",
     year = "2002"
 }
 

Index: routing-zones.ps
===================================================================
RCS file: /home/freehaven/cvsroot/doc/routing-zones/routing-zones.ps,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -d -r1.3 -r1.4
--- routing-zones.ps	18 Jun 2004 04:06:20 -0000	1.3
+++ routing-zones.ps	25 Aug 2004 11:37:57 -0000	1.4
@@ -1,15 +1,16 @@
 %!PS-Adobe-2.0
 %%Creator: dvips(k) 5.86 Copyright 1999 Radical Eye Software
 %%Title: routing-zones.dvi
-%%Pages: 18
+%%Pages: 16
 %%PageOrder: Ascend
 %%BoundingBox: 0 0 612 792
-%%DocumentFonts: Helvetica
+%%DocumentFonts: Helvetica-Bold Helvetica Times-Bold Times-Roman
+%%+ Times-Italic
 %%EndComments
[...7261 lines suppressed...]
+3548 V 375 3525 a(p)r(eerfear)p 870 3548 V 250 w(66.93.132.237)p
+1516 3548 V 167 w(US)p 1860 3548 V 238 w(23504)e(\(Sp)r(eak)n(easy)i
+(Inc\))p 3549 3548 V 328 3622 V 375 3600 a(metacolo)p
+870 3622 V 222 w(193.111.87.20)p 1516 3622 V 167 w(US)p
+1860 3622 V 238 w(24812)e(\(MetaColo)g(AS\))p 3549 3622
+V 328 3697 V 375 3675 a(ned)p 870 3697 V 414 w(80.190.251.24)p
+1516 3697 V 167 w(DE)p 1860 3697 V 230 w(24900)g(\(IPX)j(Serv)n(er\))p
+3549 3697 V 328 3772 V 375 3750 a(p)r(etra)p 870 3772
+V 351 w(69.20.9.201)p 1516 3772 V 249 w(US)p 1860 3772
+V 238 w(27357)d(\(Rac)n(kspace.com\))p 3549 3772 V 328
+3847 V 375 3824 a(TheoryOrg)p 870 3847 V 148 w(64.147.163.247)p
+1516 3847 V 126 w(US)p 1860 3847 V 238 w(29752)g(\(SFcolo)r(cation\))p
+3549 3847 V 328 3921 V 375 3899 a(incognito)p 870 3921
+V 214 w(199.173.10.10)p 1516 3921 V 167 w(US)p 1860 3921
+V 238 w(29944)g(\(PullThePlug)i(T)-7 b(ec)n(hnologies)26
+b(LLC\))p 3549 3921 V 330 3925 3221 4 v Black Black 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.79
retrieving revision 1.80
diff -u -d -r1.79 -r1.80
--- routing-zones.tex	20 Aug 2004 23:19:30 -0000	1.79
+++ routing-zones.tex	25 Aug 2004 11:37:57 -0000	1.80
@@ -34,10 +34,10 @@
 \author{
 \alignauthor Nick Feamster\\
         \affaddr{MIT Laboratory for Computer Science}\\
-        \email{(feamster@lcs.mit.edu)}
+        \email{feamster@lcs.mit.edu}
 \alignauthor Roger Dingledine\\
         \affaddr{The Free Haven Project}\\
-        \email{(arma@mit.edu)}
+        \email{arma@mit.edu}
 }
 \maketitle
 \pagestyle{plain}
@@ -145,7 +145,7 @@
 10\% and 30\% of the time, depending on the location of the initiator
 and responder, and that the single AS that can observe these paths is
 always a backbone ISP.  We conclude that a slightly different node
-selection algorithm can allow users of these networks to minimize the
+selection algorithm can allow users to minimize the
 likelihood that their entry path and exit path traverse the same AS.
 
 \section{Background}
@@ -164,7 +164,7 @@
 and recipient by wrapping messages in layers of public-key cryptography,
 and relaying them through a path composed of \emph{mixes}. Each mix
 in turn decrypts, delays, and re-orders messages, before relaying them
-toward their destinations.
+onward.
 
 Subsequent anonymity systems have diverged in two directions. Systems
 like Babel~\cite{babel}, Mixmaster, and
@@ -211,7 +211,7 @@
 properties of Internet routing at the AS-level, and design ways to
 quantify the results.
 
-\subsection{Overview of Internet Routing and Topology}
+\subsection{Internet Routing and Topology}
 
 To determine the networks that packets will traverse between each node
 of a mix network, we must first understand how packets are routed
@@ -293,9 +293,9 @@
 \begin{figure}[t]
 \begin{small}
 \begin{verbatim}
-   Network          Next Hop            Metric LocPrf Weight Path
-*>i18.0.0.0/8       64.243.30.141                 100      0 6347 3356 3 i
-* i                 65.115.97.141           10    100      0 209 10578 3 i
+   Network    Next Hop      Metric LocPrf Wgt Path
+*>i18.0.0.0/8 64.243.30.141           100   0 6347 3356 3 i
+* i           65.115.97.141     10    100   0 209 10578 3 i
 \end{verbatim}
 \end{small}
 \caption{Example BGP routing table entry (taken from a Cisco-like router).}
@@ -384,7 +384,7 @@
 an adversary observing both Alice and Bob can quickly learn that they
 are communicating. Onion Routing analysis~\cite{onion-routing:pet2000}
 has shown that an adversary observing $c$ of the $n$ nodes in the network
-can use endpoint attacks to break $\frac{c^2}{n^2}$ of the transactions. By
+can break $\frac{c^2}{n^2}$ of the transactions. By
 requiring the path from Alice to the anonymity network and the
 path from the anonymity network to Bob to traverse separate
 ASes, we can prevent all of these
@@ -491,7 +491,7 @@
 Alice can only discover the AS-level path from the destination to her
 chosen exit node using passive inference techniques.
 
-Because of these shortcomings, Alice must be able to {\em passively}
+Because of these shortcomings, Alice must {\em passively}
 determine the AS-level path (or a reasonable approximation of it)
 without having visibility into the routing tables of each hop in her
 intended mix path.  Fortunately, examining the AS paths in a BGP routing
@@ -520,7 +520,7 @@
   adjacencies from a BGP routing table, we can reasonably approximate
   the AS-level topology of the Internet.  
 
-\vspace{0.1in}
+\vspace{0.05in}
   Of course, because the policies are applied based on commercial
   relationships (e.g., an AS may filter routes learned from one peer
   when advertising routes to another peer or provider), certain
@@ -541,7 +541,7 @@
   therefore, it is generally safe to assume that any prefix contained
   within {\tt 18.0.0.0/8} is located in AS~$3$.
 
-\vspace{0.1in} Because ASes often allocate address space to their
+\vspace{0.05in} Because ASes often allocate address space to their
   customers from their own address space, this technique should be
   applied to the most specific prefix in the routing table.
 
@@ -551,7 +551,7 @@
   Fortunately, we can use heuristics from previous work that tend to
   work reasonably well~\cite{Gao2001}.  
 
-\vspace{0.1in} The basic idea is to exploit the {\em valley-free}
+\vspace{0.05in} The basic idea is to exploit the {\em valley-free}
   property of Internet paths to assign pairwise relationships between
   ASes.  That is, an AS path traverses a sequence of customer-provider
   edges, zero or one peering edges, and then a sequence of
@@ -568,7 +568,7 @@
 \item {\em Estimate the AS-level path between the two ASes by finding
   the shortest AS path that complies with common policy practices.}  
 
-\vspace{0.1in}
+\vspace{0.05in}
   Because BGP routers select a single best route to each destination,
   {\em each pair of hosts will typically traverse a single, unique AS
   path in each direction}. (See Section~\ref{sec:bgp} for a discussion
@@ -578,7 +578,7 @@
   peering routes over provider routes.  Mao {\em et al.}'s algorithm
   suggests that this assumption is reasonable.
 
-\vspace{0.1in}
+\vspace{0.05in}
   As AS-level path estimation techniques improve,
   the accuracy of our analysis will also improve. %  More importantly,
   Thus, Alice can expect to be able to make informed decisions about the
@@ -698,7 +698,7 @@
 %% Tor nodes, current Mixminion nodes, current Mixmaster nodes, and we
 %% can compare robustness of the network to zone-based attacks. 
 
-\subsection{Location Independence of Mix Nodes and Paths}
+\subsection{Location Independence of Nodes and Paths}
 
 In this section, we explore and quantify the location independence
 of the Mixmaster and Tor topologies. We examine cases where Tor
@@ -742,7 +742,7 @@
 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
-/8} prefix.  Thus, to achieve location
+/8} prefix.  To achieve location
 independence, a mix network must explicitly consider the actual AS of
 a host, not simply its IP address.
 
@@ -752,7 +752,7 @@
 participation outside of the US.
 
 \subsubsection{Path properties}
-\begin{table}[t]
+\begin{table*}[t]
 \begin{scriptsize} 
 \begin{center}
 \begin{tabular}{r|l|p{0in}r|l} \\ 
@@ -775,7 +775,7 @@
 \end{scriptsize} 
 \caption{Characterizing location independence in Mixmaster and Tor.}
 \label{tab:path_ind}
-\end{table}
+\end{table*}
 
 %% \begin{table}[t]
 %% \begin{tabular}{r|p{1.25in}|p{0.5in}p{0.5in}p{0.5in}p{0.5in}}
@@ -912,10 +912,10 @@
 users) are slightly more vulnerable to observation on both entry and
 exit than vice versa.
 
-\subsection{Location Independence of Entry and Exit Paths}
+\subsection{Independence of Entry and Exit Paths}
 
 
-\begin{table}[t]
+\begin{table*}[t]
 \begin{scriptsize} 
 \begin{center}
 \begin{tabular}{r|p{0.325in}p{0.325in}p{0.325in}p{0.325in}p{0.325in}p{0.325in}p{0.325in}p{0.325in}p{0.325in}p{0.325in}p{0.325in}p{0.325in}p{0.325in}p{0.325in}p{0.325in}}
@@ -1085,9 +1085,9 @@
   from the exit node to the receiver.  Names for each AS are listed in
   Appendix~\ref{sec:send_recv}.}
 \label{tab:as_obs_ee_tor}
-\end{table}
+\end{table*}
 
-\begin{table}[t]
+\begin{table*}[t]
 \begin{scriptsize} 
 \begin{center}
 \begin{tabular}{r|rrrrrrrrrrrrrrr}
@@ -1260,7 +1260,7 @@
 %  AS are listed in Appendix~\ref{sec:send_recv}.
 }
 \label{tab:as_obs_ee_mm}
-\end{table}
+\end{table*}
 
 
 To discover the location independence of the entry and exit paths
@@ -1298,7 +1298,7 @@
 Broadcasting (AS 5662), which includes CNN.  
 
 Location independence for pairs of senders and receivers can be highly
-asymmetric.  For example, in the Tor network topology, from Comcast
+asymmetric.  For example, in the Tor network, from Comcast
 (AS~22909) to indymedia (AS~22489), 45\% of the entry/exit node pairs
 result in paths that traverse the same AS on both entry and exit; from
 indymedia to Comcast, on the other hand, random entry and exit node
@@ -1310,13 +1310,13 @@
 path properties of the Internet.
 
 Interestingly, these tables also show that location independence
-is high when either the sender, the receiver, or both are located in a
+is high when the sender, the receiver, or both are located in a
 tier-1 ISP (e.g., AS 4999, which is part of Sprint).  This might
 be because the path from the sender to the entry point is already
 located in a tier-1 ISP, and thus will not have to cross other tier-1
 ISPs en route to the entry point.
 
-\section{Design Recommendations and Future Work}
+\section{Design Recommendations}
 \label{sec:design}
 
 In light of our analysis, which has shown that certain ASes have
@@ -1345,7 +1345,7 @@
 of our suggested algorithm on all levels of adversary; we leave this
 investigation to future work.
 
-\subsection{Improving Location Independence with Node Placement}
+\subsection{Node Placement}
 
 %Our analysis of inter-mix network paths suggests that currently deployed
 %mix networks could benefit from increased diversity in node placement,
@@ -1476,8 +1476,11 @@
 
 \pagebreak
 \begin{appendix}
+\newpage
 \section{Summary of Endpoints}\label{sec:send_recv}
 \input{endpoint-tables}
+\clearpage
+\newpage
 \section{Summary of Mix Networks}\label{sec:mixnode_summary}
 \input{network-tables}
 \end{appendix}

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