[or-cvs] r18573: {projects} Add a bibliography for performance.tex (projects/performance)

Mon Feb 16 12:25:04 UTC 2009

Author: sjm217
Date: 2009-02-16 07:25:04 -0500 (Mon, 16 Feb 2009)
New Revision: 18573

Added:
   projects/performance/performance.bib
Modified:
   projects/performance/Makefile
   projects/performance/performance.tex
Log:
Add a bibliography for performance.tex

Modified: projects/performance/Makefile
===================================================================

--- projects/performance/Makefile	2009-02-16 12:22:04 UTC (rev 18572)
+++ projects/performance/Makefile	2009-02-16 12:25:04 UTC (rev 18573)
@@ -1,3 +1,5 @@
+LATEX=pdflatex
+
 all: performance.pdf
 
 performance.pdf: node-selection/exit-capacity.pdf \
@@ -3,12 +5,16 @@
 	node-selection/optimum-selection-probabilities.pdf \
 	node-selection/relative-selection-probabilities.pdf \
-	node-selection/vary-network-load.pdf
+	node-selection/vary-network-load.pdf \
+	performance.bbl
 
-%.pdf: %.tex
+%.pdf %.aux: %.tex
 	rm -f $*.ps $*.pdf
-	pdflatex $< || { rm -f $*.pdf $*.dvi $*.aux $*.idx && false ; }
+	$(LATEX) $< || { rm -f $*.pdf $*.dvi $*.aux $*.idx && false ; }
 	while grep 'Rerun to get cross-references right.' $*.log ; do \
-	  pdflatex $< || { rm -f $*.pdf $*.dvi $*.aux $*.idx && false ; } ; done
+	  $(LATEX) $< || { rm -f $*.pdf $*.dvi $*.aux $*.idx && false ; } ; done
 
+%.bbl: %.bib %.aux
+	bibtex $* || { rm -f $*.pdf $*.dvi $*.aux $*.bbl && false ; }
+
 node-selection/optimum-selection-probabilities.pdf \
 node-selection/relative-selection-probabilities.pdf: node-selection/plot-node-selection.R
@@ -21,5 +27,5 @@
 clean:
 	rm -f *~ \
 	      *.Rout \
-	      *.aux *.log *.out *.pdf
+	      *.aux *.log *.out *.bbl *.blg *.pdf
 	rm -f node-selection/*.pdf node-selection/*.Rout  node-selection/*~

Added: projects/performance/performance.bib
===================================================================
--- projects/performance/performance.bib	                        (rev 0)
+++ projects/performance/performance.bib	2009-02-16 12:25:04 UTC (rev 18573)
@@ -0,0 +1,61 @@
+ at InProceedings{tuneup,
+  author =       {Robin Snader and Nikita Borisov},
+  title =        {A Tune-up for {Tor}: Improving Security and Performance in the {Tor} Network},
+  booktitle = {Network \& Distributed System Security Symposium},
+  year =         {2008},
+  month =        {February},
+  publisher = {Internet Society},
+}
+
+ at inproceedings{mccoy-pet2008,
+  title = {Shining Light in Dark Places: Understanding the {Tor} Network}, 
+  author = {Damon McCoy and Kevin Bauer and Dirk Grunwald and Tadayoshi Kohno and Douglas
+        Sicker}, 
+  booktitle = {Proceedings of the Eighth International Symposium on Privacy Enhancing
+        Technologies (PETS 2008)}, 
+  year = {2008}, 
+  month = {July}, 
+  address = {Leuven, Belgium}, 
+  pages = {63--76}, 
+  editor = {Nikita Borisov and Ian Goldberg}, 
+  publisher = {Springer}, 
+  www_section = {Misc}, 
+  bookurl = {http://petsymposium.org/2008/}, 
+  www_pdf_url = {http://www.cs.washington.edu/homes/yoshi/papers/Tor/PETS2008_37.pdf}, 
+  www_tags = {selected}, 
+}
+
+ at inproceedings{murdoch-pet2008,
+  title = {Metrics for Security and Performance in Low-Latency Anonymity Networks}, 
+  author = {Steven J. Murdoch and Robert N. M. Watson}, 
+  booktitle = {Proceedings of the Eighth International Symposium on Privacy Enhancing
+        Technologies (PETS 2008)}, 
+  year = {2008}, 
+  month = {July}, 
+  address = {Leuven, Belgium}, 
+  pages = {115--132}, 
+  editor = {Nikita Borisov and Ian Goldberg}, 
+  publisher = {Springer}, 
+  www_section = {traffic}, 
+  bookurl = {http://petsymposium.org/2008/}, 
+  www_pdf_url = {http://www.cl.cam.ac.uk/~sjm217/papers/pets08metrics.pdf}, 
+  www_tags = {selected}, 
+}
+
+ at Misc{tls-cbc,
+  author = 	 {Bodo M\"{o}ller},
+  title = 	 {Security of {CBC} Ciphersuites in {SSL}/{TLS}: Problems and Countermeasures},
+  month = 	 {May},
+  year = 	 {2004},
+  note = 	 {\url{http://www.openssl.org/~bodo/tls-cbc.txt}},
+}
+
+ at Misc{tls-empty-record,
+  author = 	 {Ben Laurie},
+  title = 	 {On {TLS} Empty Record Insertion},
+  month = 	 {December},
+  howpublished = {Email to or-dev at freehaven.net, in thread ``Re: Empty {TLS} application records being injected in {Tor} streams''},
+  year = 	 {2008},
+  note = 	 {\url{http://archives.seul.org/or/dev/Dec-2008/msg00005.html}},
+}
+

Modified: projects/performance/performance.tex
===================================================================
--- projects/performance/performance.tex	2009-02-16 12:22:04 UTC (rev 18572)
+++ projects/performance/performance.tex	2009-02-16 12:25:04 UTC (rev 18573)
@@ -78,7 +78,7 @@
 
 \section{Peer-to-peer bandwidth estimation}
 
-Snader and Borisov proposed that each Tor node opportunistically monitor the data rates that it achieves when communicating with other Tor nodes.
+Snader and Borisov~\cite{tuneup} proposed that each Tor node opportunistically monitor the data rates that it achieves when communicating with other Tor nodes.
 Since currently Tor uses a clique topology, given enough time, all nodes will communicate with all other Tor nodes.
 If each Tor node reported their measurements back to a central authority, it would be possible to estimate the capacity of each Tor node.
 This estimate would be difficult to game, when compared to the current self-advertisement of bandwidth capacity.
@@ -112,7 +112,7 @@
 \subsection{Further work}
 
 To properly balance exit node usage, it is necessary to know the usage of the Tor network, by port.
-McCoy \etal have figures for protocol usage in Tor, but these figures were generated through deep packet inspection, rather than by port number.
+McCoy \detal~\cite{mccoy-pet2008} have figures for protocol usage in Tor, but these figures were generated through deep packet inspection, rather than by port number.
 Furthermore, the exit node they ran used the fairly permissive default exit policy.
 Therefore, their measurements will underestimate the relative traffic on ports which are present in the default exit policy, and are also present in more restrictive policies.
 To accurately estimate the Tor network usage by port, it is necessary to measure the network usage by port on one or more exit nodes, while simultaneously recording the exit policy of all other exit nodes considered usable.
@@ -120,7 +120,7 @@
 \section{Altering node selection algorithm}
 
 Currently Tor selects nodes with a probability proportional to their bandwidth contribution to the network, however this may not be the optimal algorithm.
-Murdoch and Watson investigated the performance impact of different node selection algorithms, and derived a formula for estimating average latency $T$:
+Murdoch and Watson~\cite{murdoch-pet2008} investigated the performance impact of different node selection algorithms, and derived a formula for estimating average latency $T$:
 
 \begin{equation}
 T = \sum_{i=1}^n q_i t_i = \sum_{i=1}^n \frac{q_i x_i (2 - q_i x_i \Lambda)}{2 (1 - q_i x_i \Lambda)}
@@ -183,7 +183,7 @@
 
 OpenSSL will, by default, insert an empty TLS application record before any one which contains data.
 This is to prevent an attack, by which someone who has partial control over the plaintext of a TLS stream, can also confirm guesses as to the plaintext which he does not control.
-By including an empty application record, which incorporates a MAC, the attacker is made unable to control the CBC initialization vector, and hence does not have control of the input to the encryption function\footnote{\url{http://www.openssl.org/~bodo/tls-cbc.txt}}.
+By including an empty application record, which incorporates a MAC, the attacker is made unable to control the CBC initialization vector, and hence does not have control of the input to the encryption function~\cite{tls-cbc}.
 
 This application record does introduce an appreciable overhead.
 Most Tor cells are sent in application records of their own, giving application records of 512 bytes (cell) $+$ 20 bytes (MAC) $+$ 12 bytes (TLS padding) $+$ 5 bytes (TLS application record header) $=$ 549 bytes.
@@ -196,7 +196,7 @@
 The reduction in TCP/IP header overhead would be $37/(549 + 37) = 6.3\%$.
 
 Of course, the empty application record was inserted for a reason -- to prevent an attack on the CBC mode of operation used by TLS, so before removing it we must be confident the attack does not apply to Tor.
-Ben Laurie (one of the OpenSSL developers), concluded that in his opinion Tor could safely remove the insertion of empty TLS application records\footnote{\url{http://archives.seul.org/or/dev/Dec-2008/msg00005.html}}.
+Ben Laurie (one of the OpenSSL developers), concluded that in his opinion Tor could safely remove the insertion of empty TLS application records~\cite{tls-empty-record}.
 I was able to come up with only certificational weaknesses (discussed in the above analysis), which are expensive to exploit and give little information to the attacker.
 
 To be successful, the attacker must have full control of the plaintext application record before the one he wishes to guess.
@@ -208,6 +208,9 @@
 
 % Mike Perry provided many of the ideas discussed here
 
+\bibliographystyle{acm}
+\bibliography{performance}
+
 \end{document}
 
 Other items to add in somewhere:

