- tor-commits - lists.torproject.org

[torbutton/master] Make it harder to accidentally toggle torbutton.
by mikeperry＠torproject.org 29 Jun '11

29 Jun '11

commit 20d6479ab2e32b868d336b81f0a1a25799272ac2 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Tue Jun 28 18:44:29 2011 -0700 Make it harder to accidentally toggle torbutton. Also make clicking provide a menu rather than auto-toggle. --- src/chrome/content/popup.xul | 4 ++-- src/chrome/content/torbutton.js | 13 ++++--------- src/chrome/content/torbutton.xul | 11 ++++++----- 3 files changed, 12 insertions(+), 16 deletions(-) diff --git a/src/chrome/content/popup.xul b/src/chrome/content/popup.xul index f96b821..bd6fc35 100644 --- a/src/chrome/content/popup.xul +++ b/src/chrome/content/popup.xul @@ -9,12 +9,12 @@ <stringbundleset id="torbutton-stringbundleset"> <stringbundle id="torbutton-bundle" src="chrome://torbutton/locale/torbutton.properties"/> </stringbundleset> - <menupopup id="torbutton-context-menu" onpopupshowing="torbutton_check_protections();"> + <menupopup id="torbutton-context-menu" onpopupshowing="torbutton_check_protections();" + anchor="torbutton-button" position="after_start"> <menuitem id="torbutton-toggle" label="&torbutton.context_menu.toggle;" accesskey="&torbutton.context_menu.toggle.key;" insertafter="context-stop" - key="torbutton-toggle-key" oncommand="torbutton_toggle(true)"/> <menuitem id="torbutton-preferences" label="&torbutton.context_menu.preferences;" diff --git a/src/chrome/content/torbutton.js b/src/chrome/content/torbutton.js index 2a5d8ca..2d90676 100644 --- a/src/chrome/content/torbutton.js +++ b/src/chrome/content/torbutton.js @@ -1726,15 +1726,10 @@ function torbutton_close_on_toggle(mode) { function torbutton_check_protections() { - var pref = m_tb_prefs.getBoolPref("extensions.torbutton.cookie_protections"); - // XXX: This should always be visible if the user enabled it. It does seem to have - // other bugs though. - /* && ((!m_tb_prefs.getBoolPref("extensions.torbutton.tor_memory_jar") - && m_tb_prefs.getBoolPref("extensions.torbutton.tor_enabled")) - || (!m_tb_prefs.getBoolPref("extensions.torbutton.nontor_memory_jar") - && !m_tb_prefs.getBoolPref("extensions.torbutton.tor_enabled"))); - */ - document.getElementById("torbutton-cookie-protector").disabled = !pref; + var cookie_pref = m_tb_prefs.getBoolPref("extensions.torbutton.cookie_protections"); + var locked_pref = m_tb_prefs.getBoolPref("extensions.torbutton.locked_mode") + document.getElementById("torbutton-cookie-protector").disabled = !cookie_pref; + document.getElementById("torbutton-toggle").collapsed = locked_pref; } function torbutton_open_cookie_dialog() { diff --git a/src/chrome/content/torbutton.xul b/src/chrome/content/torbutton.xul index f600f89..8e9cde6 100644 --- a/src/chrome/content/torbutton.xul +++ b/src/chrome/content/torbutton.xul @@ -29,9 +29,10 @@ class="toolbarbutton-1 chromeclass-toolbar-additional" label="Torbutton" tooltiptext="&torbutton.button.tooltip;" - context="torbutton-context-menu" - oncommand="torbutton_toggle(false);" /> + menu="torbutton-context-menu" + context="torbutton-context-menu"/> </toolbarpalette> +  <statusbar id="status-bar"> <statusbarpanel id="torbutton-panel" insertbefore="statusbar-updates" - context="torbutton-context-menu" - onclick="if (event.button == 0) torbutton_toggle(false)"/> + menu="torbutton-context-menu" + context="torbutton-context-menu" />  </statusbar> <popup id="contentAreaContextMenu">

1 0

[arm/master] Adding wizard option for port forwarding
by atagar＠torproject.org 28 Jun '11

28 Jun '11

commit b8101c830699b2c931c30e8a0fdaa10ca8e34d3d Author: Damian Johnson <atagar(a)torproject.org> Date: Tue Jun 28 08:52:35 2011 -0700 Adding wizard option for port forwarding Wizard option for the PortForwarding config option. This will need to be omitted if... - "tor-fw-helper" doesn't exist in the user's PATH - tor doesn't have the PortForwarding option (introduced in 0.2.3.1-alpha) --- src/cli/wizard.py | 4 +++- src/settings.cfg | 4 ++++ 2 files changed, 7 insertions(+), 1 deletions(-) diff --git a/src/cli/wizard.py b/src/cli/wizard.py index d2fb067..7a9eaa0 100644 --- a/src/cli/wizard.py +++ b/src/cli/wizard.py @@ -15,13 +15,14 @@ from util import enum, uiTools RelayType = enum.Enum("RELAY", "EXIT", "BRIDGE", "CLIENT") # all options that can be configured -Options = enum.Enum("DIVIDER", "NICKNAME", "CONTACT", "NOTIFY", "BANDWIDTH", "LIMIT", "CLIENT", "STARTUP", "NOTICE", "POLICY", "WEBSITES", "EMAIL", "IM", "MISC", "PLAINTEXT") +Options = enum.Enum("DIVIDER", "NICKNAME", "CONTACT", "NOTIFY", "BANDWIDTH", "LIMIT", "CLIENT", "PORTFORWARD", "STARTUP", "NOTICE", "POLICY", "WEBSITES", "EMAIL", "IM", "MISC", "PLAINTEXT") RelayOptions = {RelayType.RELAY: (Options.NICKNAME, Options.CONTACT, Options.NOTIFY, Options.BANDWIDTH, Options.LIMIT, Options.CLIENT, + Options.PORTFORWARD, Options.STARTUP), RelayType.EXIT: (Options.NICKNAME, Options.CONTACT, @@ -29,6 +30,7 @@ RelayOptions = {RelayType.RELAY: (Options.NICKNAME, Options.BANDWIDTH, Options.LIMIT, Options.CLIENT, + Options.PORTFORWARD, Options.STARTUP, Options.DIVIDER, Options.NOTICE, diff --git a/src/settings.cfg b/src/settings.cfg index 0ab57a2..435a4d2 100644 --- a/src/settings.cfg +++ b/src/settings.cfg @@ -347,6 +347,7 @@ wizard.message.exit Exits connect between the Tor network and the outside Intern wizard.toggle Notify => Yes, No wizard.toggle Client => Enabled, Disabled +wizard.toggle Portforward => Enabled, Disabled wizard.toggle Startup => Yes, No wizard.toggle Notice => Yes, No wizard.toggle Policy => Default, Custom @@ -367,6 +368,7 @@ wizard.default Notify => true wizard.default Bandwidth => 5 MB/s wizard.default Startup => true wizard.default Client => false +wizard.default Portforward => true wizard.default Notice => true wizard.default Policy => true wizard.default Websites => true @@ -388,6 +390,7 @@ wizard.label.opt Notify => Issue Notification wizard.label.opt Bandwidth => Relay Speed wizard.label.opt Limit => Monthly Limit wizard.label.opt Client => Client Usage +wizard.label.opt Portforward => Port Forwarding wizard.label.opt Startup => Run At Startup wizard.label.opt Notice => Disclaimer Notice wizard.label.opt Policy => Exit Policy @@ -408,6 +411,7 @@ wizard.description.opt Notify => Sends automated email notifications to the abov wizard.description.opt Bandwidth => Limit for the average rate at which you relay traffic. wizard.description.opt Limit => Maximum amount of traffic to relay each month. Some ISPs, like Comcast, cap their customer's Internet usage so this is an easy way of staying below that limit. wizard.description.opt Client => Enable this if you would like to use Tor yourself. This opens or closes the SOCKS port used by applications for connecting to Tor. +wizard.description.opt Portforward => If needed, attempts NAT traversal using UPnP and NAT-PMP. This allows for automatic port forwarding on most home routers. wizard.description.opt Startup => Runs Tor in the background when the system starts. wizard.description.opt Notice => Provides a disclaimer that this is an exit on port 80 (http://www.atagar.com/exitNotice) wizard.description.opt Policy => Ports allowed to exit from your relay. The default policy allows for common services while limiting the chance of getting a DMCA takedown for torrent traffic (http://www.atagar.com/exitPolicy)

1 0

[arm/master] Using @torproject.org address rather than @gmail
by atagar＠torproject.org 28 Jun '11

28 Jun '11

commit 8f1a0975c13478cc1a375b904ca1589362c09cf1 Author: Damian Johnson <atagar(a)torproject.org> Date: Tue Jun 28 07:43:18 2011 -0700 Using @torproject.org address rather than @gmail Switching the address in the man page, readme, and about dialog to my @tpo address. Looks nicer, though if this is ever invalidated then I will be _very_ unhappy. --- README | 2 +- arm.1 | 2 +- src/cli/popups.py | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/README b/README index 835b02b..2e0bd6e 100644 --- a/README +++ b/README @@ -1,5 +1,5 @@ arm (anonymizing relay monitor) - Terminal status monitor for Tor relays. -Developed by Damian Johnson (www.atagar.com - atagar1(a)gmail.com) +Developed by Damian Johnson (www.atagar.com - atagar(a)torproject.org) All code under the GPL v3 (http://www.gnu.org/licenses/gpl.html) Project page: www.atagar.com/arm diff --git a/arm.1 b/arm.1 index 7743035..7edb5ef 100644 --- a/arm.1 +++ b/arm.1 @@ -70,5 +70,5 @@ Your personal arm configuration file Sample armrc configuration file that documents all options .SH AUTHOR -Written by Damian Johnson (atagar1(a)gmail.com) +Written by Damian Johnson (atagar(a)torproject.org) diff --git a/src/cli/popups.py b/src/cli/popups.py index 7254f4a..8a41f73 100644 --- a/src/cli/popups.py +++ b/src/cli/popups.py @@ -170,7 +170,7 @@ def showAboutPopup(): popup.win.box() popup.addstr(0, 0, "About:", curses.A_STANDOUT) popup.addstr(1, 2, "arm, version %s (released %s)" % (version.VERSION, version.LAST_MODIFIED), curses.A_BOLD) - popup.addstr(2, 4, "Written by Damian Johnson (atagar1(a)gmail.com)") + popup.addstr(2, 4, "Written by Damian Johnson (atagar(a)torproject.org)") popup.addstr(3, 4, "Project page: www.atagar.com/arm") popup.addstr(5, 2, "Released under the GPL v3 (http://www.gnu.org/licenses/gpl.html)") popup.addstr(7, 2, "Press any key...")

1 0

[arm/master] fix: cagraph was being imported when running cli
by atagar＠torproject.org 28 Jun '11

28 Jun '11

commit 69ffa459a30c0a5b3fb69150b3f593645abb1be8 Author: Damian Johnson <atagar(a)torproject.org> Date: Tue Jun 28 10:20:50 2011 -0700 fix: cagraph was being imported when running cli The cagraph dependency should only be needed if we're running the gui. However, an import for it accidently slipped in, causing import errors for arm's cli users. --- src/starter.py | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/starter.py b/src/starter.py index 104e0e2..005b43f 100644 --- a/src/starter.py +++ b/src/starter.py @@ -17,7 +17,6 @@ import platform import version import cli.controller import cli.logPanel -import gui.controller import util.conf import util.connections import util.hostnames @@ -436,6 +435,7 @@ if __name__ == '__main__': locale.setlocale(locale.LC_ALL, "") if launchGui == True: + import gui.controller gui.controller.startGui() else: cli.controller.startTorMonitor(time.time() - initTime)

1 0

[tordnsel/master] date the 0.1.0 release.
by andrew＠torproject.org 28 Jun '11

28 Jun '11

commit 8839661e15fb14cecf2e7e064ad742743bc6d3e9 Author: Andrew Lewman <andrew(a)torproject.org> Date: Tue Jun 28 09:49:51 2011 -0400 date the 0.1.0 release. --- ChangeLog | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/ChangeLog b/ChangeLog index b26fee7..54df4d8 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,4 +1,4 @@ -0.1.0 - 201?-??-?? +0.1.0 - 2011-06-28 o Deployment: - Add support for logging messages to stdout, stderr, syslog, or to a file. Syslog logging should be useful for running in a chroot.

1 0

[tordnsel/master] change timeouts from 48 to 24 hours so exit relays aren't listed for 2
by andrew＠torproject.org 28 Jun '11

28 Jun '11

commit 203590063b3877c73e876a94aa93c847976d2116 Author: Andrew Lewman <andrew(a)torproject.org> Date: Sat Jun 18 23:09:15 2011 -0400 change timeouts from 48 to 24 hours so exit relays aren't listed for 2 days beyond their disappearing from consensus. --- src/TorDNSEL/NetworkState/Internals.hs | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/TorDNSEL/NetworkState/Internals.hs b/src/TorDNSEL/NetworkState/Internals.hs index 484537e..933b7eb 100644 --- a/src/TorDNSEL/NetworkState/Internals.hs +++ b/src/TorDNSEL/NetworkState/Internals.hs @@ -668,8 +668,8 @@ expireOldInfo now s = s { nsAddrs = addrs'', nsRouters = routers'' } deleteExitAddresses rid test addrs = foldl' (\as addr -> deleteAddress addr rid as) addrs (M.keys $ tstAddresses test) - maxRouterAge = 48 * 60 * 60 - maxExitTestAge = 48 * 60 * 60 + maxRouterAge = 24 * 60 * 60 + maxExitTestAge = 24 * 60 * 60 -- | Add a new router associated with an address to the address map. insertAddress :: HostAddress -> RouterID -> Map HostAddress (Set RouterID)

1 0

[tordnsel/master] update the Changelog to reflect the max router age.
by andrew＠torproject.org 28 Jun '11

28 Jun '11

commit 8d2c12619dcf6014a68a7f55a849e415ec864480 Author: Andrew Lewman <andrew(a)torproject.org> Date: Sun Jun 19 22:05:16 2011 -0400 update the Changelog to reflect the max router age. --- ChangeLog | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/ChangeLog b/ChangeLog index f09c3fa..b26fee7 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,4 +1,4 @@ -0.1.0 - 2008-0?-?? +0.1.0 - 201?-??-?? o Deployment: - Add support for logging messages to stdout, stderr, syslog, or to a file. Syslog logging should be useful for running in a chroot. @@ -58,6 +58,9 @@ earlier attempted test. - Regenerate the exit-addresses store every time a new network status consensus is received instead of every 15 minutes. + - Reduce the maximum relay age from 48 hours to 24 hours. This should + cut down the length of time a relay is listed in the exitlist after + it has been disabled or changed to a non-exit relay. o Controller: - Close controller connections cleanly with the QUIT command.

1 0

[tordnsel/master] add tordnsel init script.
by andrew＠torproject.org 28 Jun '11

28 Jun '11

commit cb19f6a87f1b238703fafcf2397d59edf504ebb5 Author: Andrew Lewman <andrew(a)torproject.org> Date: Wed Jun 22 21:28:34 2011 -0400 add tordnsel init script. --- config/tordnsel-init.d-script.sample | 169 ++++++++++++++++++++++++++++++++++ 1 files changed, 169 insertions(+), 0 deletions(-) diff --git a/config/tordnsel-init.d-script.sample b/config/tordnsel-init.d-script.sample new file mode 100755 index 0000000..f7a7fd2 --- /dev/null +++ b/config/tordnsel-init.d-script.sample @@ -0,0 +1,169 @@ +#! /bin/sh +### BEGIN INIT INFO +# Provides: TorDNSEL +# Required-Start: $local_fs $remote_fs $syslog $network $time +# Required-Stop: $local_fs $remote_fs $syslog $network $time +# Default-Start: 2 3 4 5 +# Default-Stop: 0 1 6 +# Short-Description: Starts the TorDNSEL daemon process +# Description: Starts TorDNSEL, a name server that provides a +# DNSBL-style interface for detecting connections +# exiting the Tor network. +# +### END INIT INFO + +# Author: Jacob Appelbaum <jacob(a)appelbaum.net> +# Author: tup <tup.tuple(a)googlemail.com> +# +# Please remove the "Author" lines above and replace them +# with your own name if you copy and modify this script. + +# Do NOT "set -e" + +# PATH should only include /usr/* if it runs after the mountnfs.sh script +PATH=/sbin:/usr/sbin:/bin:/usr/bin +DESC="TorDNSEL daemon" +NAME=tordnsel +DAEMON=/usr/local/bin/$NAME +PIDFILE=/var/run/$NAME.pid +SCRIPTNAME=/etc/init.d/$NAME +CONFIGFILE="/etc/tordnsel.conf" +RUNTIMEDIR="/var/run/tordnsel" +USER=tordnsel +ARGS="-f $CONFIGFILE " + +# Exit if the package is not installed +[ -x "$DAEMON" ] || exit 0 + +# Read configuration variable file if it is present +[ -r /etc/default/$NAME ] && . /etc/default/$NAME + +# +# Function that starts the daemon/service +# +do_start() +{ + # Return + # 0 if daemon has been started + # 1 if daemon was already running + # 2 if daemon could not be started + start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --test > /dev/null \ + || return 1 + start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -- $ARGS \ + || return 2 + # Add code here, if necessary, that waits for the process to be ready + # to handle requests from services started subsequently which depend + # on this one. As a last resort, sleep for some time. +} + +# +# Function that stops the daemon/service +# +do_stop() +{ + # Return + # 0 if daemon has been stopped + # 1 if daemon was already stopped + # 2 if daemon could not be stopped + # other if a failure occurred + start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE --name $NAME + RETVAL="$?" + [ "$RETVAL" = 2 ] && return 2 + # Wait for children to finish too if this is a daemon that forks + # and if the daemon is only ever run from this initscript. + # If the above conditions are not satisfied then add some other code + # that waits for the process to drop all resources that could be + # needed by services started subsequently. A last resort is to + # sleep for some time. + start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 --exec $DAEMON + [ "$?" = 2 ] && return 2 + # Many daemons don't delete their pidfiles when they exit. + rm -f $PIDFILE + return "$RETVAL" +} + +case "$1" in + start) + echo "Starting $DESC: $NAME..." + + if ! su -s /bin/sh -c "$DAEMON --verify-config $ARGS" $USER 2> /dev/null; then + echo "ABORTED: TorDNSEL configuration invalid:" >&2 + su -s /bin/sh -c "$DAEMON --verify-config $ARGS" $USER + exit 1 + fi + + do_start + case "$?" in + 0|1) echo "done." ;; + 2) + echo "FAILED." + exit 1 + ;; + esac + ;; + stop) + echo -n "Stopping $DESC: " + do_stop + case "$?" in + 0|1) echo "$NAME." ;; + 2) + echo "FAILED." + exit 1 + ;; + esac + ;; + reload|force-reload) + echo -n "Reloading $DESC configuration: " + + if ! su -s /bin/sh -c "$DAEMON --verify-config $ARGS" $USER 2> /dev/null; then + echo "ABORTED: TorDNSEL configuration invalid:" >&2 + su -s /bin/sh -c "$DAEMON --verify-config $ARGS" $USER + exit 1 + fi + + # Don't send the process a SIGHUP because it won't be able to read its own + # config file when it's chrooted. Instead, use the --reconfigure option to + # dump the contents of the config file to a Unix domain socket on which it's + # listening for this purpose. + ERRMSG=`su -s /bin/sh -c "$DAEMON --reconfigure $RUNTIMEDIR < $CONFIGFILE" $USER 2>&1` + case "$?" in + 0) echo "$NAME." ;; + *) + echo "FAILED." + echo "$ERRMSG" >&2 + exit 1 + ;; + esac + ;; + restart) + if ! su -s /bin/sh -c "$DAEMON --verify-config $ARGS" $USER 2> /dev/null; then + echo "Restarting TorDNSEL ABORTED: TorDNSEL configuration invalid:" >&2 + su -s /bin/sh -c "$DAEMON --verify-config $ARGS" $USER + exit 1 + fi + + echo "Restarting $DESC: $NAME..." + do_stop + case "$?" in + 0|1) + do_start + case "$?" in + 0) echo "done." ;; + 1) echo "FAILED ($DAEMON is still running)." ;; + *) echo "FAILED." ;; # Failed to start + esac + ;; + *) + # Failed to stop + echo "FAILED ($DAEMON won't die)." + exit 1 + ;; + esac + ;; + *) + echo "Usage: $SCRIPTNAME {start|stop|restart|reload|force-reload}" >&2 + exit 3 + ;; +esac + +:

1 0

[torspec/master] Add proposal 182 ("Credit Bucket") by Tschorsch and Scheuermann
by nickm＠torproject.org 27 Jun '11

27 Jun '11

commit 1413093be9d575a4b0805e0328e2867319a543ae Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Jun 27 15:58:45 2011 -0400 Add proposal 182 ("Credit Bucket") by Tschorsch and Scheuermann --- proposals/000-index.txt | 2 + proposals/182-creditbucket.txt | 181 ++++++++++++++++++++++++++++++++++++++++ 2 files changed, 183 insertions(+), 0 deletions(-) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index 06e97b5..43502ec 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -102,6 +102,7 @@ Proposals by number: 179 TLS certificate and parameter normalization [DRAFT] 180 Pluggable transports for circumvention [OPEN] 181 Optimistic Data for Tor: Client Side [OPEN] +182 Credit Bucket [DRAFT] Proposals by status: @@ -114,6 +115,7 @@ Proposals by status: 144 Increase the diversity of circuits by detecting nodes belonging the same provider 175 Automatically promoting Tor clients to nodes 179 TLS certificate and parameter normalization [for 0.2.3.x] + 182 Credit Bucket NEEDS-REVISION: 118 Advertising multiple ORPorts at once 131 Help users to verify they are using Tor diff --git a/proposals/182-creditbucket.txt b/proposals/182-creditbucket.txt new file mode 100644 index 0000000..8796bd1 --- /dev/null +++ b/proposals/182-creditbucket.txt @@ -0,0 +1,181 @@ +Filename: 182-creditbucket.txt +Title: Credit Bucket +Author: Florian Tschorsch and Björn Scheuermann +Created: 22 Jun 2011 +Status: Draft + +Overview: + + The following proposal targets the reduction of queuing times in onion + routers. In particular, we focus on the token bucket algorithm in Tor and + point out that current usage unnecessarily locks cells for long time spans. + We propose a non-intrusive change in Tor's design which overcomes the + deficiencies. + +Motivation and Background: + + Cell statistics from the Tor network [1] reveal that cells reside in + individual onion routers' cell queues for up to several seconds. These + queuing times increase the end-to-end delay very significantly and are + apparently the largest contributor to overall cell latency in Tor. + + In Tor there exist multiple token buckets on different logical levels. They + all work independently. They are used to limit the up- and downstream of an + onion router. All token buckets are refilled every second with a constant + amount of tokens that depends on the configured bandwidth limits. For + example, the so-called RelayedTokenBucket limits relay traffic only. All + read data of incoming connections are bound to a dedicated read token + bucket. An analogous mechanism exists for written data leaving the onion + router. We were able to identify the specific usage and implementation of + the token bucket algorithm as one cause for very high (and unnecessary) + queuing times in an onion router. + + We observe that the token buckets in Tor are (surprisingly at a first + glance) allowed to take on negative fill levels. This is justified by the + TLS connections between onion routers where whole TLS records need to be + processed. The token bucket on the incoming side (i.e., the one which + determines at which rate it is allowed to read from incoming TCP + connections) in particular often runs into non-negligible negative fill + levels. As a consequence of this behavior, sometimes slightly more data is + read than it would be admissible upon strict interpretation of the token + bucket concept. + + However, the token bucket for limiting the outgoing rate does not take on + negative fill levels equally often. Consequently, it regularly happens + that somewhat more data are read on the incoming side than the outgoing + token bucket allows to be written during the same cycle, even if their + configured data rates are the same. The respective cells will thus not be + allowed to leave the onion router immediately. They will thus necessarily + be queued for at least as long as it takes until the token bucket on the + outgoing side is refilled again. The refill interval currently is, as + mentioned before, one second -- so, these cells are delayed for a very + substantial time. In summary, one could say that the two buckets, on the + incoming and outgoing side, work like a double door system and frequently + lock cells for a full token bucket refill interval length. + +General Design: + + In order to overcome the described problem, we propose the following + changes related to the token bucket algorithm. + + We observe that the token bucket on the outgoing connections with its + current design is contra productive in the sense of queuing times. We + therefore propose modifications to the token bucket algorithm that will + eliminate the "double door effect" discussed above. + + Let us start from Tor's current approach: Thus, we have a regular token + bucket on the reading side with a certain rate and a certain burst size. + Let x denote the current amount of tokens in the bucket. On the outgoing + side we need something appropriate that monitors and constrains the + outgoing rate, but at the same time avoids holding back cells (cf. double + door effects) whenever possible. + + Here we propose something that adopts the role of a token bucket, but + realizes this functionality in a slightly different way. We call it a + "credit bucket". Like a token bucket, the credit bucket also has a current + fill level, denoted by y. However, the credit bucket is refilled in a + different way. + + To understand how it works, let us look at the possible operations: + + As said, x is the fill level of a regular token bucket on the incoming + side and thus gets incremented periodically according to the configured + rate. No changes here. + + If x<=0, we are obviously not allowed to read. If x>0, we are allowed to + read up to x bytes of incoming data. If k bytes are read (k<=x), then we + update x and y as follows: + + x = x - k (1) + y = y + k (2) + + (1) is the standard token bucket operation on the incoming side. Whenever + data is admitted in, though, an additional operation is performed: (2) + allocates the same number of bytes on the outgoing side, which will later + on allow the same number of bytes to leave the onion router without any + delays. + + If y + x > -M, we are allowed to write up to y + x + M bytes on the + outgoing side, where M is a positive constant. M specifies a burst size for + the outgoing side. M should be higher than the number of tokens that get + refilled during a refill interval, we would suggest to have M in the order + of a few seconds "worth" of data. Now if k bytes are written on the + outgoing side, we proceed as follows: + + If k <= y then y = y - k + + In this case we use "saved" credits, previously allocated on the incoming + side when incoming data has been processed. + + If k > y then y = 0 and x = x - (k-y) + + We generated additional traffic in the onion router, so that more data is + to be sent than has been read (the credit is not sufficient). We therefore + "steal" tokens from the token buffer on the incoming side to compensate for + the additionally generated data. This will result in correspondingly less + data being read on the incoming side subsequently. As a result of such an + operation, the token bucket fill level x on the incoming side may become + negative (but it can never fall below -M). + + If y + x <= -M then outgoing data will be held back. This may lead to + double-door effects, but only in extreme cases where the outgoing traffic + largely exceeds the incoming traffic, so that the outgoing bursts size M is + exceeded. + + Aside from short-term bursts of configurable size (as with every token + bucket), this procedure guarantees that the configured rate may never be + exceeded (on the application layer, that is; as with the current + implementation, an attacker may easily cause the onion router to + arbitrarily exceed the limits on the lower layers). Over time, we never + send more data than the configured rate: every sent byte needs a + corresponding token on the incoming side; this token must either have been + consumed by an incoming byte before (it then became a "credit"), or it is + "stolen" from the incoming bucket to compensate for data generated within + the onion router. + +Specific Design Changes: + + In the following we briefly point out the specific changes that need to be + done in Tor's source code. By doing so one can see how non intrusive our + modifications are. + + First we need to address the bucket increment and decrement operations. + According to the described logic above, this should be done in the methods + connection_bucket_refill and connection_buckets_decrement respectively. In + particular allocating, saving and "stealing" of tokens need to be + considered here. + + Second the rate limiting, i.e. the amount we are allowed to write + (connection_bucket_write_limit) needs to be adapted in lines of the credit + bucket logic. Meaning in order to avoid the here identified unnecessary + queuing of cells, we need to consider the new burst parameter M. Here we + also need to take non rate limited connections such as from the localhost + into account. The rate limiting on the reading side remains the same. + + At last we need to find good values/ ratios for the parameter M such that + the trade off between avoiding "double door effects" and maintaining + strict rate limits work as expected. As future work and after insights + about the performance gain of the here described proposal we need to find a + way to implement this both using bufferevent rate limiting with libevent + 2.3.x and Tor's rate limiting code. + +Conclusion: + + This proposal can be implemented with moderate effort and requires changes + only at the points where currently the token bucket operations are + performed. + + We feel that this is not the be-all and end-all solution, because it again + introduces a feedback loop between the incoming and the outgoing side. We + therefore still hope that we will be able to come to a both simpler and + more effective design in the future. However, we believe that what we + proposed here is a good compromise between avoiding double-door effects to + the furthest possible extent, strictly enforcing an application-layer data + rate, and keeping the extent of changes to the code small. + + Feedback is highly appreciated. + +References: + + [1] Karsten Loesing. Analysis of Circuit Queues in Tor. August 25, 2009. + [2] https://trac.torproject.org/projects/tor/wiki/sponsors/SponsorD/June2011

1 0

[torflow/master] Merge branch 'ratio-restrictions'
by mikeperry＠torproject.org 27 Jun '11

27 Jun '11

commit 039d5300c6d1bb9adfa7a21af0560620d620978f Merge: 07cbb7c a3fdd01 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Mon Jun 27 11:22:47 2011 -0700 Merge branch 'ratio-restrictions' NetworkScanners/BwAuthority/bwauthority_child.py | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)

1 0