commit 69b010d08f259daaebd3f7360db9882612f19b4f Author: Nick Mathewson <nickm@torproject.org> Date: Tue Nov 13 23:02:11 2012 -0500 Revise "other design decisions" section --- todo | 5 +++-- tor-design-2012.tex | 48 +++++++++++++++++++----------------------------- 2 files changed, 22 insertions(+), 31 deletions(-) diff --git a/todo b/todo index ac44c7f..af508bf 100644 --- a/todo +++ b/todo @@ -6,6 +6,7 @@ LEGEND: o Done . Partially done ? Do we really need to do this? + X Abandoned: we don't need to do this. ITEMS: @@ -24,7 +25,7 @@ ITEMS: o stream isolation . Integrate content from the third blog post [steven] o link protocol tls - ? rise and fall of .exit + X rise and fall of .exit . controller protocol o torbutton o tor browser bundle @@ -37,7 +38,7 @@ ITEMS: o Revise tor-design up to "opening and closing streams" [nick] . Revise tor-design "opening and closing streams" onward [steven] o Revise hidden services section [nick] - . Revise "other design decisions" [nick] + o Revise "other design decisions" [nick] CAN DO AFTER SPONSOR DEADLINE: - Revise related work [steven] diff --git a/tor-design-2012.tex b/tor-design-2012.tex index 2f48cbb..035bf0d 100644 --- a/tor-design-2012.tex +++ b/tor-design-2012.tex @@ -1452,7 +1452,8 @@ others. First of all, there are several CPU-consuming denial-of-service attacks wherein an attacker can force an OR to perform expensive -cryptographic operations. For example, an attacker can fake the +cryptographic operations at little cost to the attacker. +For example, an attacker can fake the start of a TLS handshake, forcing the OR to carry out its (comparatively expensive) half of the handshake at no real computational cost to the attacker. @@ -1470,8 +1471,6 @@ symmetric cryptography operations that keep cells flowing. This rate limiting could, however, allow an attacker to slow down other users when they build new circuits. -% What about link-to-link rate limiting? - The Tor network itself can be exploited as a DoS amplifier, because for every relay cell sent into an OP, a cell is generated at each hop on the circuit. An adversary could create @@ -1494,9 +1493,6 @@ requests and so cannot generate a path of longer than 8 hops. This does not however prevent an adversary tunneling Tor over Tor, and connecting from an exit node back to the Tor network. -% Mention long-path defense -NM -% Believed done -SJM - Adversaries can also attack the Tor network's hosts and network links. Disrupting a single circuit or link breaks all streams passing along that part of the circuit. Users similarly lose @@ -1510,19 +1506,22 @@ require more buffering at the network edges, however, and the performance and anonymity implications from this extra complexity still require investigation. -% Mention asymmetries in protocols, where a little effort from an attacker -% can make Tor do more calculation. That's bad. -NM - -\subsection{Exit policies and abuse} +In general, deliberate denial of service attacks have not yet had a +noticeable impact on the Tor network in the wild. While we are +aware to the possibility, and looking for more ways to mitigate +possible DoS attack vectors, we are currently more concerned with +circumstances under which misbehaving nodes accidentally ``attack'' +part of the network. For example, our decision to have the +directory authorities act both as the initial contact point for +clients to get directory information has led to clients placing +excessive load on those authorities during times when they couldn't +find pieces of directory information. + +\subsection{Exit policies, node history, and abuse} \label{subsec:exitpolicies} -% This whole section's introduction should get rewritten based on our -% experiences with the network. -NM - -% The thing with exit policies isn't so much (as we phrase it) a "mitigate -% abuse" thing. It's about allowing servers who can't tolerate *any* abuse -% to contribute to the network. Our thinking was kinda muddled there. -NM -Exit abuse is a serious barrier to wide-scale Tor +The prospect of exit abuse limits the number of users willing to run +Tor nodes. 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 implicating @@ -1531,17 +1530,8 @@ use IP-based authentication (such as institutional mail or webservers) can be fooled by the fact that anonymous connections appear to originate at the exit OR. -We stress that Tor does not enable any new class of -abuse. Spammers and other attackers already have access to -thousands of misconfigured systems worldwide, and the Tor -network is far from the easiest way to launch attacks. But -because the onion routers can be mistaken for the originators of -the abuse, and the volunteers who run them may not want to deal -with the hassle of explaining anonymity networks to irate -administrators, we must block or limit abuse through the Tor -network. - -To mitigate abuse issues, each onion router's \emph{exit policy} +To enable volunteers to run nodes without having to necessarily +worry about these abuse issues, each onion router's \emph{exit policy} describes to which external addresses and ports the router will connect. On one end of the spectrum are \emph{open exit} nodes that will connect anywhere. On the other end are @@ -1551,7 +1541,7 @@ local host or network. A private exit can allow a client to connect to a given host or network more securely---an external adversary cannot eavesdrop traffic between the private exit and the final destination, and so is less sure of Alice's -destination and activities. Most onion routers in the current +destination and activities. Many onion routers in the current network function as \emph{restricted exits} that permit connections to the world at large, but prevent access to certain abuse-prone addresses and services such as SMTP. The OR might