tor-commits January 2016

tor-commits@lists.torproject.org

19 participants
1449 discussions

[translation/bridgedb] Update translations for bridgedb
by translation＠torproject.org 15 Jan '16

15 Jan '16

commit bb755f3dd0ac7d17fafbc31510dbbfe37729314d Author: Translation commit bot <translation(a)torproject.org> Date: Fri Jan 15 15:45:03 2016 +0000 Update translations for bridgedb --- mr/LC_MESSAGES/bridgedb.po | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/mr/LC_MESSAGES/bridgedb.po b/mr/LC_MESSAGES/bridgedb.po index 3c53158..9494be5 100644 --- a/mr/LC_MESSAGES/bridgedb.po +++ b/mr/LC_MESSAGES/bridgedb.po @@ -9,7 +9,7 @@ msgstr "" "Project-Id-Version: The Tor Project\n" "Report-Msgid-Bugs-To: 'https://trac.torproject.org/projects/tor/newticket?component=BridgeDB&keywo…'\n" "POT-Creation-Date: 2015-07-25 03:40+0000\n" -"PO-Revision-Date: 2016-01-15 08:24+0000\n" +"PO-Revision-Date: 2016-01-15 15:44+0000\n" "Last-Translator: Vikrant Korde <vikrant.korde(a)gmail.com>\n" "Language-Team: Marathi (http://www.transifex.com/otf/torproject/language/mr/)\n" "MIME-Version: 1.0\n" @@ -32,7 +32,7 @@ msgstr "" #. "Tor Browser" #: bridgedb/https/server.py:167 msgid "Sorry! Something went wrong with your request." -msgstr "" +msgstr "क्षमस्व! काहीतरी चूक झाली आहे" #: bridgedb/https/templates/base.html:79 msgid "Report a Bug" @@ -79,18 +79,18 @@ msgstr "मिळवताना गडबड झाली" msgid "" "This QRCode contains your bridge lines. Scan it with a QRCode reader to copy" " your bridge lines onto mobile and other devices." -msgstr "" +msgstr "ह्या QR कोड मध्ये आपल्या ब्रिज ओळी आहेत. आपल्या ब्रिज ओळी मोबाइल आणि इतर साधनांवर वर कॉपी करण्यासाठी QR कोड वाचकाने स्कॅन करा." #: bridgedb/https/templates/bridges.html:131 msgid "There currently aren't any bridges available..." -msgstr "" +msgstr "सध्या कोणतेही ब्रिजेस उपलब्ध नाहीत ... " #: bridgedb/https/templates/bridges.html:132 #, python-format msgid "" " Perhaps you should try %s going back %s and choosing a different bridge " "type!" -msgstr "" +msgstr "तुम्ही %s मागे %s जाउन दुसरा ब्रिज प्रकार निवडावा" #: bridgedb/https/templates/index.html:11 #, python-format @@ -100,7 +100,7 @@ msgstr "पायरी %s1%s" #: bridgedb/https/templates/index.html:13 #, python-format msgid "Download %s Tor Browser %s" -msgstr "" +msgstr "डाउनलोड %s टोर ब्राउझर %s" #: bridgedb/https/templates/index.html:25 #, python-format @@ -120,7 +120,7 @@ msgstr "पायरी %s3%s" #: bridgedb/https/templates/index.html:38 #, python-format msgid "Now %s add the bridges to Tor Browser %s" -msgstr "" +msgstr "आता %s ब्रिजेस टोर ब्राउझर मध्ये टाका %s" #. TRANSLATORS: Please make sure the '%s' surrounding single letters at the #. beginning of words are present in your final translation. Thanks! @@ -129,19 +129,19 @@ msgstr "" #: bridgedb/https/templates/options.html:38 #, python-format msgid "%sJ%sust give me bridges!" -msgstr "" +msgstr "%sम%sला ब्रिजेस द्या!" #: bridgedb/https/templates/options.html:51 msgid "Advanced Options" -msgstr "" +msgstr "प्रगत पर्याय" #: bridgedb/https/templates/options.html:86 msgid "No" -msgstr "" +msgstr "नाही" #: bridgedb/https/templates/options.html:87 msgid "none" -msgstr "" +msgstr "काहीही नाही" #. TRANSLATORS: Please make sure the '%s' surrounding single letters at the #. beginning of words are present in your final translation. Thanks! @@ -149,7 +149,7 @@ msgstr "" #: bridgedb/https/templates/options.html:124 #, python-format msgid "%sY%ses!" -msgstr "" +msgstr "%sहो%sय!" #. TRANSLATORS: Please make sure the '%s' surrounding single letters at the #. beginning of words are present in your final translation. Thanks! @@ -157,15 +157,15 @@ msgstr "" #: bridgedb/https/templates/options.html:147 #, python-format msgid "%sG%set Bridges" -msgstr "" +msgstr "%s पूल %s मिळवा" #: bridgedb/strings.py:43 msgid "[This is an automated message; please do not reply.]" -msgstr "" +msgstr "[हा एक स्वयंचलित संदेश आहे; कृपया प्रत्युत्तर देऊ नका ]" #: bridgedb/strings.py:45 msgid "Here are your bridges:" -msgstr "" +msgstr "येथे आपला पूल आहे:" #: bridgedb/strings.py:47 #, python-format @@ -182,7 +182,7 @@ msgstr "" #. TRANSLATORS: Please DO NOT translate the word "BridgeDB". #: bridgedb/strings.py:53 msgid "Welcome to BridgeDB!" -msgstr "" +msgstr "ब्रिज DB मध्ये आपले स्वागत आहे!" #. TRANSLATORS: Please DO NOT translate the words "transport" or "TYPE". #: bridgedb/strings.py:55 @@ -200,7 +200,7 @@ msgstr "हॅलो, मित्रा !" #: bridgedb/strings.py:58 bridgedb/https/templates/base.html:90 msgid "Public Keys" -msgstr "" +msgstr "पब्लिक किज्" #. TRANSLATORS: This string will end up saying something like: #. "This email was generated with rainbows, unicorns, and sparkles

1 0

[tor/master] Include square brackets and port number in calcs for max_dl_per_request
by nickm＠torproject.org 15 Jan '16

15 Jan '16

commit d748c193e16bc13b6d00de168e5fff0a372620bc Author: Fergus Dall <fergus(a)beware.dropbear.id.au> Date: Wed Jan 13 18:05:35 2016 +1030 Include square brackets and port number in calcs for max_dl_per_request --- src/or/routerlist.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/src/or/routerlist.c b/src/or/routerlist.c index 8edab2c..139a292 100644 --- a/src/or/routerlist.c +++ b/src/or/routerlist.c @@ -4440,15 +4440,15 @@ static int max_dl_per_request(const or_options_t *options, int purpose) { /* Since squid does not like URLs >= 4096 bytes we limit it to 96. - * 4096 - strlen(http://ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff - * /tor/server/d/.z) == 4034 - * 4034/41 (40 for the hash and 1 for the + that separates them) => 98 + * 4096 - strlen(http://[ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff]:65535 + * /tor/server/d/.z) == 4026 + * 4026/41 (40 for the hash and 1 for the + that separates them) => 98 * So use 96 because it's a nice number. * * For microdescriptors, the calculation is - * 4096 - strlen(http://ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff - * /tor/micro/d/.z) == 4035 - * 4035/44 (43 for the hash and 1 for the - that separates them) => 91 + * 4096 - strlen(http://[ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff]:65535 + * /tor/micro/d/.z) == 4027 + * 4027/44 (43 for the hash and 1 for the - that separates them) => 91 * So use 90 because it's a nice number. */ int max = 96;

1 0

[tor/master] Update the limits in max_dl_per_request for IPv6 address length
by nickm＠torproject.org 15 Jan '16

15 Jan '16

commit 91077d3aca2ea027816f4ea733bb8193dd60a2f2 Author: Fergus Dall <fergus(a)beware.dropbear.id.au> Date: Wed Jan 13 06:49:56 2016 +1030 Update the limits in max_dl_per_request for IPv6 address length --- changes/17573 | 3 +++ src/or/routerlist.c | 13 ++++++++++--- 2 files changed, 13 insertions(+), 3 deletions(-) diff --git a/changes/17573 b/changes/17573 new file mode 100644 index 0000000..fe1fd1c --- /dev/null +++ b/changes/17573 @@ -0,0 +1,3 @@ + o Minor bigfixes (IPv6): + - Update the limits in max_dl_per_request for IPv6 address + length. Closes ticket 17573. diff --git a/src/or/routerlist.c b/src/or/routerlist.c index 853c07d..8edab2c 100644 --- a/src/or/routerlist.c +++ b/src/or/routerlist.c @@ -4440,13 +4440,20 @@ static int max_dl_per_request(const or_options_t *options, int purpose) { /* Since squid does not like URLs >= 4096 bytes we limit it to 96. - * 4096 - strlen(http://255.255.255.255/tor/server/d/.z) == 4058 - * 4058/41 (40 for the hash and 1 for the + that separates them) => 98 + * 4096 - strlen(http://ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff + * /tor/server/d/.z) == 4034 + * 4034/41 (40 for the hash and 1 for the + that separates them) => 98 * So use 96 because it's a nice number. + * + * For microdescriptors, the calculation is + * 4096 - strlen(http://ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff + * /tor/micro/d/.z) == 4035 + * 4035/44 (43 for the hash and 1 for the - that separates them) => 91 + * So use 90 because it's a nice number. */ int max = 96; if (purpose == DIR_PURPOSE_FETCH_MICRODESC) { - max = 92; + max = 90; } /* If we're going to tunnel our connections, we can ask for a lot more * in a request. */

1 0

[translation/bridgedb] Update translations for bridgedb
by translation＠torproject.org 15 Jan '16

15 Jan '16

commit 1d099afe572b8b94c449a4e535bc1e35dc336db7 Author: Translation commit bot <translation(a)torproject.org> Date: Fri Jan 15 08:45:04 2016 +0000 Update translations for bridgedb --- mr/LC_MESSAGES/bridgedb.po | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/mr/LC_MESSAGES/bridgedb.po b/mr/LC_MESSAGES/bridgedb.po index 13a8011..3c53158 100644 --- a/mr/LC_MESSAGES/bridgedb.po +++ b/mr/LC_MESSAGES/bridgedb.po @@ -9,7 +9,7 @@ msgstr "" "Project-Id-Version: The Tor Project\n" "Report-Msgid-Bugs-To: 'https://trac.torproject.org/projects/tor/newticket?component=BridgeDB&keywo…'\n" "POT-Creation-Date: 2015-07-25 03:40+0000\n" -"PO-Revision-Date: 2016-01-15 05:25+0000\n" +"PO-Revision-Date: 2016-01-15 08:24+0000\n" "Last-Translator: Vikrant Korde <vikrant.korde(a)gmail.com>\n" "Language-Team: Marathi (http://www.transifex.com/otf/torproject/language/mr/)\n" "MIME-Version: 1.0\n" @@ -110,7 +110,7 @@ msgstr "पायरी %s2%s" #: bridgedb/https/templates/index.html:27 #, python-format msgid "Get %s bridges %s" -msgstr "" +msgstr "%s पूल %s मिळवा" #: bridgedb/https/templates/index.html:36 #, python-format @@ -196,7 +196,7 @@ msgstr "ओय, %s!" #: bridgedb/strings.py:57 msgid "Hello, friend!" -msgstr "" +msgstr "हॅलो, मित्रा !" #: bridgedb/strings.py:58 bridgedb/https/templates/base.html:90 msgid "Public Keys"

1 0

[translation/bridgedb] Update translations for bridgedb
by translation＠torproject.org 15 Jan '16

15 Jan '16

commit 9040dbd6c2cf067d5d47c529ae481cb575e15e30 Author: Translation commit bot <translation(a)torproject.org> Date: Fri Jan 15 05:45:03 2016 +0000 Update translations for bridgedb --- mr/LC_MESSAGES/bridgedb.po | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/mr/LC_MESSAGES/bridgedb.po b/mr/LC_MESSAGES/bridgedb.po index 77b8bca..13a8011 100644 --- a/mr/LC_MESSAGES/bridgedb.po +++ b/mr/LC_MESSAGES/bridgedb.po @@ -3,13 +3,13 @@ # This file is distributed under the same license as the BridgeDB project. # # Translators: -# Vikrant Korde <vikrant.korde(a)gmail.com>, 2015 +# Vikrant Korde <vikrant.korde(a)gmail.com>, 2015-2016 msgid "" msgstr "" "Project-Id-Version: The Tor Project\n" "Report-Msgid-Bugs-To: 'https://trac.torproject.org/projects/tor/newticket?component=BridgeDB&keywo…'\n" "POT-Creation-Date: 2015-07-25 03:40+0000\n" -"PO-Revision-Date: 2015-12-24 11:15+0000\n" +"PO-Revision-Date: 2016-01-15 05:25+0000\n" "Last-Translator: Vikrant Korde <vikrant.korde(a)gmail.com>\n" "Language-Team: Marathi (http://www.transifex.com/otf/torproject/language/mr/)\n" "MIME-Version: 1.0\n" @@ -95,7 +95,7 @@ msgstr "" #: bridgedb/https/templates/index.html:11 #, python-format msgid "Step %s1%s" -msgstr "" +msgstr "पायरी %s1%s" #: bridgedb/https/templates/index.html:13 #, python-format @@ -105,7 +105,7 @@ msgstr "" #: bridgedb/https/templates/index.html:25 #, python-format msgid "Step %s2%s" -msgstr "" +msgstr "पायरी %s2%s" #: bridgedb/https/templates/index.html:27 #, python-format @@ -115,7 +115,7 @@ msgstr "" #: bridgedb/https/templates/index.html:36 #, python-format msgid "Step %s3%s" -msgstr "" +msgstr "पायरी %s3%s" #: bridgedb/https/templates/index.html:38 #, python-format @@ -192,7 +192,7 @@ msgstr "" #: bridgedb/strings.py:56 #, python-format msgid "Hey, %s!" -msgstr "" +msgstr "ओय, %s!" #: bridgedb/strings.py:57 msgid "Hello, friend!"

1 0

[translation/tor-messenger-privproperties_completed] Update translations for tor-messenger-privproperties_completed
by translation＠torproject.org 14 Jan '16

14 Jan '16

commit dbcfc0135cbae58d36844c88bdd801d7714a0cd2 Author: Translation commit bot <translation(a)torproject.org> Date: Thu Jan 14 19:16:41 2016 +0000 Update translations for tor-messenger-privproperties_completed --- ca/priv.properties | 1 + 1 file changed, 1 insertion(+) diff --git a/ca/priv.properties b/ca/priv.properties new file mode 100644 index 0000000..53ac506 --- /dev/null +++ b/ca/priv.properties @@ -0,0 +1 @@ +priv.account=S'està generant una clau privada per a %S (%S)...

1 0

[tor-commits] [translation/tor-messenger-facebookproperties_completed] Update translations for tor-messenger-facebookproperties_completed
by translation＠torproject.org 14 Jan '16

14 Jan '16

commit 142743df064a40537f0115fc2011410762b0d4cc Author: Translation commit bot <translation(a)torproject.org> Date: Thu Jan 14 19:16:24 2016 +0000 Update translations for tor-messenger-facebookproperties_completed --- ca/facebook.properties | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/ca/facebook.properties b/ca/facebook.properties new file mode 100644 index 0000000..3dc2124 --- /dev/null +++ b/ca/facebook.properties @@ -0,0 +1,7 @@ +# This Source Code Form is subject to the terms of the Mozilla Public +# License, v. 2.0. If a copy of the MPL was not distributed with this +# file, You can obtain one at http://mozilla.org/MPL/2.0/. + +connection.error.useUsernameNotEmailAddress=Feu servir el vostre nom d'usuari del Facebook, no el correu electrònic + +facebook.chat.name=Xat de Facebook

1 0

[translation/tor-messenger-facebookproperties] Update translations for tor-messenger-facebookproperties
by translation＠torproject.org 14 Jan '16

14 Jan '16

commit b1e665bc60f1b8110a23c1144119add4841a52cb Author: Translation commit bot <translation(a)torproject.org> Date: Thu Jan 14 19:16:17 2016 +0000 Update translations for tor-messenger-facebookproperties --- ca/facebook.properties | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ca/facebook.properties b/ca/facebook.properties index aaf7cdc..3dc2124 100644 --- a/ca/facebook.properties +++ b/ca/facebook.properties @@ -2,6 +2,6 @@ # License, v. 2.0. If a copy of the MPL was not distributed with this # file, You can obtain one at http://mozilla.org/MPL/2.0/. -connection.error.useUsernameNotEmailAddress=Please use your Facebook username, not an email address +connection.error.useUsernameNotEmailAddress=Feu servir el vostre nom d'usuari del Facebook, no el correu electrònic -facebook.chat.name=Facebook Chat +facebook.chat.name=Xat de Facebook

1 0

[torspec/master] Add my removing-obsolete-clients proposal as 266
by nickm＠torproject.org 14 Jan '16

14 Jan '16

commit 99acfe0bb19f0a0bcb7c1ec4866c817d91ade7c8 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Jan 14 11:24:16 2016 -0500 Add my removing-obsolete-clients proposal as 266 --- proposals/000-index.txt | 2 + .../266-removing-current-obsolete-clients.txt | 204 ++++++++++++++++++++ 2 files changed, 206 insertions(+) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index 718dd31..411093b 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -186,6 +186,7 @@ Proposals by number: 263 Request to change key exchange protocol for handshake v1.1 [OPEN] 264 Putting version numbers on the Tor subprotocols [OPEN] 265 Load Balancing with Overhead Parameters [DRAFT] +266 Removing current obsolete clients from the Tor network [DRAFT] Proposals by status: @@ -213,6 +214,7 @@ Proposals by status: 259 New Guard Selection Behaviour 260 Rendezvous Single Onion Services 265 Load Balancing with Overhead Parameters + 266 Removing current obsolete clients from the Tor network NEEDS-REVISION: 190 Bridge Client Authorization Based on a Shared Secret OPEN: diff --git a/proposals/266-removing-current-obsolete-clients.txt b/proposals/266-removing-current-obsolete-clients.txt new file mode 100644 index 0000000..3d8a6c3 --- /dev/null +++ b/proposals/266-removing-current-obsolete-clients.txt @@ -0,0 +1,204 @@ +Filename: 266-removing-current-obsolete-clients.txt +Title: Removing current obsolete clients from the Tor network +Author: Nick Mathewson +Created: 14 Jan 2016 +Status: Draft + + +1. Introduction + + Frequently, we find that very old versions of Tor should no longer be + supported on the network. To remove relays is easy enough: we + simply update the directory authorities to stop listing relays that + advertise versions that are too old. + + But to disable clients is harder. + + In another proposal I describe a system for letting future clients go + gracefully obsolete. This proposal explains how we can safely + disable the obsolete clients we have today (and all other client + versions of Tor to date, assuming that they will someday become + obsolete). + +1.1. Why disable clients? + + * Security. Anybody who hasn't updated their Tor client in 5 + years is probably vulnerable to who-knows-what attacks. They + aren't likely to get much anonymity either. + + * Withstand zombie installations. Some Tors out there were once + configured to start-on-boot systems that are now unmaintained. + (See 1.4 below.) They put needless load on the network, and help + nobody. + + * Be able to remove backward-compatibility code. Currently, Tor + supports some truly ancient protocols in order to avoid breaking + ancient versions or Tor. This code needs to be maintained and + tested. Some of it depends on undocumented or deprecated or + non-portable OpenSSL features, and makes it hard to produce a + conforming Tor server implementation. + + * Make it easier to write a conforming Tor relay. If a Tor relay + needs to support every Tor client back through the beginning of + time, that makes it harder to develop and test compatible + implementations. + +1.2. Is this dangerous? + + I don't think so. This proposal describes a way to make older + clients gracefully disconnect from the network only when a majority + of authorities agree that they should. A majority of authorities + already have the ability to inflict arbitrary degrees of sabotage on + the consensus document. + +1.3. History + + The earliest versions of Tor checked the recommended-versions field + in the directory to see whether they should keep running. If they + saw that their version wasn't recommended, they'd shut down. There + was an "IgnoreVersion" option that let you keep running anyway. + + Later, around 2004, the rule changed to "shut down if the version is + _obsolete_", where obsolete was defined as "not recommended, and + older than a version that is recommended." + + In 0.1.1.7-alpha, we made obsolete versions only produce a warning, + and removed IgnoreVersion. (See 3ac34ae3293ceb0f2b8c49.) + + We have still disabled old tor versions. With Tor 0.2.0.5-alpha, + we disabled Tor versions before 0.1.1.6-alpha by having the v1 + authorities begin publishing empty directories only. + + In version 0.2.5.2-alpha, we completely removed support for the v2 + directory protocol used before Tor 0.2.0; there are no longer any v2 + authorities on the network. + + Tor versions before 0.2.1 will currently not progress past fetching + an initial directory, because they believe in a number of directory + authority identity keys that no longer sign the directory. + + Tor versions before 0.2.4 are (lightly) throttled in multihop + circuit creation, because we prioritize ntor CREATE cells over + TAP ones when under load. + +1.4. The big problem: slow zombies and fast zombies + + It would be easy enough to 'disable' old clients by simply removing + server support for the obsolete protocols that they use. But there's + a problem with that approach: what will the clients do when they fail + to make connections, or to extend circuits, or whatever else they are + no longer able to do? + + * Ideally, I'd like such clients to stop functioning _quietly_. If + they stop contacting the network, that would be best. + + * Next best would be if these clients contacted the network only + occasionally and at different times. I'll call these clients + "slow zombies". + + * Worse would be if the clients contact the network frequently, + over and over. I'll call these clients "fast zombies". They + would be at their worst when they focus on authorities, or when + they act in synchrony to all strike at once. + + One goal of this proposal is to ensure that future clients to not + become zombies at all; and that ancient clients become slow zombies + at worst. + + +2. Some ideas that don't work. + +2.1. Dropping connections based on link protocols. + + Tor versions before before 0.2.3.6-alpha use a renegotiation-based + handshake instead of our current handshake. We could detect these + handshakes and close the connection at the relay side if the client + attempts to renegotiate. + + I've tested these changes on versions maint-0.2.0 through + maint-0.2.2. They result in zombies with the following behavior: + + The client contact each authority it knows about, attempting to + make a one-hop directory connection. It fails, detects a failure, + then reconnects more and more slowly ... but one hour later, it + resets its connection schedule and starts again. + + In the steady state this appears to result in about two connections + per client per authority per hour. That is probably too many. + + (Most authorities would be affected: of the authorities that existed + in 0.2.2, gabelmoo has moved and turtles has shut down. The + authorities Faravahar and longclaw are new. The authorities moria1, + tor26, dizum, dannenberg, urras, maatuska and maatuska would all get + hit here.) + + (We could simply remove the renegotiation-detection code entirely, + and reply to all connections with an immediate VERSIONS cell. The + behavior would probably be the same, though.) + + If we throttled connections rather than closing them, we'd only get + one connnection per authority per hour, but authorities would have to + keep open a potentially huge number of sockets. + +2.2. Blocking circuit creation under certain circumstances + + In tor 0.2.5.1-alpha, we began ignoring the UseNTorHandshake option, + and always preferring the ntor handshake where available. + + Unfortunately, we can't simply drop all TAP handshakes, since clients + and relays can still use them in the hidden service protocol. But + we could detect these versions by: + + Looking for use of a TAP handshake from an IP not associated + with with any known relay, or on a connection where the client + did not authenticate. (This could be from a bridge, but clients + don't build circuits that go to an IntroPoint or RendPoint + directly after a bridge.) + + This would still result in clients not having directories, however, + and retrying once an hours. + +3. Ideas that might work + +3.1. Move all authorities to new ports + + We could have each authority known to older clients start listening + for connections at a new port P. We'd forward the old port to the new + port. Once sufficiently many clients were using the new ports, we + could disable the forwarding. + + This would result in the old clients turning into zombies as above, + but they would only be scrabbling at nonexistent ports, causing less + load on the authorities. + + [This proposal would probably be easiest to implement.] + +3.2. Start disabling old link protocols on relays + + We could have new relays start dropping support for the old link + protocols, while maintaining support on the authorities and older + relays. + + The result here would be a degradation of older client performance + over time. They'd still behave zombieishly if the authorities + dropped support, however. + +3.3. Changing the consensus format. + + We could allow 'f' (short for "flag") as a synonym for 's' in + consensus documents. Later, if we want to disable all Tor versions + before today, we can change the consensus algorithm so that the + consensus (or perhaps only the microdesc consensus) is spelled with + 'f' lines instead of 'f' lines. This will create a consensus which + older clients and relays parse as having all nodes down, which will + make them not connect to the network at all. + + We could similarly replace "r" with "n", or replace Running with + Online, or so on. + + In doing this, we could also rename fresh-until and valid-until, so + that new clients would have the real expiration date, and old clients + would see "this consensus never expires". This would prevent them + from downloading new consensuses. + + [This proposal would result in the quietest shutdown.]

1 0

[torspec/master] add proposal 265: Load Balancing with Overhead Parameters
by nickm＠torproject.org 14 Jan '16

14 Jan '16

commit bee44ba05fc37191353177e57b7f6f1d42d8468e Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Jan 14 11:21:40 2016 -0500 add proposal 265: Load Balancing with Overhead Parameters --- proposals/000-index.txt | 6 +- proposals/265-load-balancing-with-overhead.txt | 320 ++++++++++++++++++++++++ 2 files changed, 324 insertions(+), 2 deletions(-) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index 7979244..718dd31 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -183,8 +183,9 @@ Proposals by number: 260 Rendezvous Single Onion Services [DRAFT] 261 AEZ for relay cryptography [OPEN] 262 Re-keying live circuits with new cryptographic material [OPEN] -263 Request to change key exchange protocol for handshake [OPEN] +263 Request to change key exchange protocol for handshake v1.1 [OPEN] 264 Putting version numbers on the Tor subprotocols [OPEN] +265 Load Balancing with Overhead Parameters [DRAFT] Proposals by status: @@ -211,6 +212,7 @@ Proposals by status: 257 Refactoring authorities and taking parts offline 259 New Guard Selection Behaviour 260 Rendezvous Single Onion Services + 265 Load Balancing with Overhead Parameters NEEDS-REVISION: 190 Bridge Client Authorization Based on a Shared Secret OPEN: @@ -240,7 +242,7 @@ Proposals by status: 258 Denial-of-service resistance for directory authorities 261 AEZ for relay cryptography 262 Re-keying live circuits with new cryptographic material - 263 Request to change key exchange protocol for handshake + 263 Request to change key exchange protocol for handshake v1.1 264 Putting version numbers on the Tor subprotocols ACCEPTED: 140 Provide diffs between consensuses diff --git a/proposals/265-load-balancing-with-overhead.txt b/proposals/265-load-balancing-with-overhead.txt new file mode 100644 index 0000000..b1d5af6 --- /dev/null +++ b/proposals/265-load-balancing-with-overhead.txt @@ -0,0 +1,320 @@ +Filename: 265-load-balancing-with-overhead.txt +Title: Load Balancing with Overhead Parameters +Authors: Mike Perry +Created: 01 January 2016 +Status: Draft + + +0. Motivation + +In order to properly load balance in the presence of padding and +non-negligible amounts of directory and hidden service traffic, the load +balancing equations in Section 3.8.3 of dir-spec.txt are in need of some +modifications. + +In addition to supporting the idea of overhead, the load balancing +equations can also be simplified by treating Guard+Exit nodes as Exit +nodes in all cases. This causes the 9 sub-cases of the current load +balancing equations to consolidate into a single solution, which also +will greatly simplify the consensus process, and eliminate edge cases +such as #16255[1]. + + +1. Overview + +For padding overhead due to Proposals 251 and 254, and changes to hidden +service path selection in Proposal 247, it will be useful to be able to +specify a pair of parameters that represents the additional traffic +present on Guard and Middle nodes due to these changes. + +The current load balancing equations unfortunately make this excessively +complicated. With overhead factors included, each of the 9 subcases goes +from being a short solution to over a page of calculations for each +subcase. + +Moreover, out of 8751 hourly consensus documents produced in 2015[2], +only 78 of them had a non-zero weight for using Guard+Exit nodes in the +Guard position (weight Wgd), and most of those were well under 1%. The +highest weight for using Guard+Exits in the Guard position recorded in +2015 was 2.62% (on December 10th, 2015). This means clients that chose a +Guard node during that particular hour used only 2.62% of Guard+Exit +flagged nodes' bandwidth when performing a bandwidth-weighted Guard +selection. All clients that chose a Guard node during any other hour did +not consider Guard+Exit nodes at all as potential candidates for their +Guards. + +This indicates that we can greatly simplify these load balancing +equations with little to no change in diversity to the network. + + +2. Simplified Load Balancing Equations + +Recall that the point of the load balancing equations in section 3.8.3 +of dir-spec.txt is to ensure that an equal amount of client traffic is +distributed between Guards, Middles, Exits, and Guard+Exits, where each +flag type can occupy one or more positions in a path. This allocation is +accomplished by solving a system of equations for weights for flag +position selection to ensure equal allocation of client traffic for each +position in a circuit. + +If we ignore overhead for the moment and treat Guard+Exit nodes as Exit +nodes, then this allows the simplified system of equations to become: + + Wgg*G == M + Wme*E + Wmg*G # Guard position == middle position + Wgg*G == Wee*E # Guard position == equals exit position + Wmg*G + Wgg*G == G # Guard allocation weights sum to 1 + Wme*E + Wee*E == E # Exit allocation weights sum to 1 + +This system has four equations and four unknowns, and by transitivity we +ensure that allocated capacity for guard, middle, and exit positions are +all equal. Unlike the equations in 3.8.3 of dir-spec.txt, there are no +special cases to the solutions of these equations because there is no +shortage of constraints and no decision points for allocation based on +scarcity. Thus, there is only one solution. Using SymPy's symbolic +equation solver (see attached script) we obtain: + + E + G + M E + G + M 2*E - G - M 2*G - E - M + Wee: ---------, Wgg: ---------, Wme: -----------, Wmg: ------------ + 3*E 3*G 3*E 3*G + +For the rest of the flags weights, we will do the following: + + Dual-flagged (Guard+Exit) nodes should be treated as Exits: + Wgd = 0, Wmd = Wme, Wed = Wee + + Directory requests use middle weights: + Wbd=Wmd, Wbg=Wmg, Wbe=Wme, Wbm=Wmm + + Handle bridges and strange exit policies: + Wgm=Wgg, Wem=Wee, Weg=Wed + +2.1. Checking for underflow and overflow + +In the old load balancing equations, we required a case-by-case proof to +guard against overflow and underflow, and to decide what to do in the +event of various overflow and underflow conditions[3]. Even still, the +system proved fragile to changes, such as the implementation of Guard +uptime fractions[1]. + +Here, with the simplified equations, we can plainly see that the only +time that a negative weight can arise is in Wme and Wmg, when 2*E < G+M +or when 2*G < E+M. In other words, only when Exits or Guards are scarce. + +Similarly, the only time that a weight exceeding 1.0 can arise is in Wee +and Wgg, which also happens when 2*E < G+M or 2*G < E+M. This means that +parameters will always overflow in pairs (Wee and Wme, and/or Wgg and +Wmg). + +In both these cases, simply clipping the parameters at 1 and 0 provides +as close of a balancing condition as is possible, given the scarcity. + + +3. Load balancing with Overhead Parameters + +Intuitively, overhead due to padding and path selection changes can be +represented as missing capacity in the relevant position. This means +that in the presence of a Guard overhead fraction of G_o and a Middle +overhead fraction of M_o, the total fraction of actual client traffic +carried in those positions is (1-G_o) and (1-M_o), respectively. + +Then, to achieve a balanced allocation of traffic, we consider only the +actual client capacity carried in each position: + + # Guard position minus overhead matches middle position minus overhead: + (1-G_o)*(Wgg*G) == (1-M_o)*(M + Wme*E + Wmg*G) + # Guard position minus overhead matches exit position: + (1-G_o)*(Wgg*G) == 1*(Wee*E) + # Guard weights still sum to 1: + Wmg*G + Wgg*G == G + # Exit weights still sum to 1: + Wme*E + Wee*E == E + +Solving this system with SymPy unfortunately yields some unintuitively +simplified results. For each weight, we first show the SymPy solution, +and then factor that solution into a form analogous to Section 2: + + -(G_o - 1)*(M_o - 1)*(E + G + M) + Wee: --------------------------------------- + E*(G_o + M_o - (G_o - 1)*(M_o - 1) - 2) + + + (1 - G_o)*(1 - M_o)*(E + G + M) + Wee: --------------------------------------- + E*(2 - G_o - M_o + (1 - G_o)*(1 - M_o)) + + + + (M_o - 1)*(E + G + M) + Wgg: --------------------------------------- + G*(G_o + M_o - (G_o - 1)*(M_o - 1) - 2) + + (1 - M_o)*(E + G + M) + Wgg: --------------------------------------- + G*(2 - G_o - M_o + (1 - G_o)*(1- M_o)) + + + + -E*(M_o - 1) + G*(G_o - 1)*(-M_o + 2) - M*(M_o - 1) + Wmg: --------------------------------------------------- + G*(G_o + M_o - (G_o - 1)*(M_o - 1) - 2) + + (2 - M_o)*G*(1 - G_o) - M*(1 - M_o) - E*(1 - M_o) + Wmg: --------------------------------------------------- + G*(2 - G_o - M_o + (1 - G_o )*(1 - M_o)) + + + + E*(G_o + M_o - 2) + G*(G_o - 1)*(M_o - 1) + M*(G_o - 1)*(M_o - 1) + Wme: ----------------------------------------------------------------- + E*(G_o + M_o - (G_o - 1)*(M_o - 1) - 2) + + (2 - G_o - M_o)*E - G*(1 - G_o)*(1 - M_o) - M*(1 - G_o)*(1 - M_o) + Wme: ----------------------------------------------------------------- + E*(2 - G_o - M_o + (1 - G_o)*(1 - M_o)) + + +A simple spot check with G_o = M_o = 0 shows us that with zero overhead, +these solutions become identical to the solutions in Section 2 of this +proposal. + +The final condition that we need to ensure is that these weight values +never become negative or greater than 1.0[3]. + + +3.1. Ensuring against underflow and overflow + +Note that if M_o = G_o = 0, then the solutions and the overflow +conditions are the same as in Section 2. + +Unfortunately, SimPy is unable to solve multivariate inequalities, which +prevents us from directly deriving overflow conditions for each variable +independently (at least easily and without mistakes). Wolfram Alpha is +able to derive closed form solutions to some degree for this, but they +are more complicated than checking the weights for underflow and +overflow directly. + +However, for all overflow and underflow cases, simply warning in the +event of overflow or underflow in the weight variable solutions above is +equivalent anyway. Optimal load balancing given this scarcity should +still result if we clip the resulting solutions to [0, 1.0]. + +It will be wise in the implementation to test the overflow conditions +with M_o = G_o = 0, and with their actual values. This will allow us to +know if the overflow is a result of inherent unbalancing, or due to +input overhead values that are too large (and need to be reduced by, for +example, reducing padding). + + +4. Consensus integration + +4.1. Making use of the Overhead Factors + +In order to keep the consensus process simple on the Directory +Authorities, the overhead parameters represent the combined overhead +from many factors. + +The G_o variable is meant to account for sum of directory overhead, +netflow padding overhead, future two-hop padding overhead, and future +hidden service overhead (for cases where Guard->Middle->Exit circuits +are not used). + +The M_o variable is meant to account for multi-hop padding overhead, +hidden service overhead, as well as an overhead for any future two-hop +directory connections (so that we can consolidate Guards and Directory +guard functionality into a single Guard node). + +There is no need for an E_o variable, because even if there were +Exit-specific overhead, it could be represented by an equivalent +reductions in both G_o and M_o instead. + +Since all relevant padding and directory overhead information is +included in the extra-info documents for each relay, the M_o and G_o +variables could be computed automatically from these extra-info +documents during the consensus process. However, it is probably wiser to +keep humans in the loop and set them manually as consensus parameters +instead, especially since we have not previously had to deal with +serious adversarial consequences from malicious extra-info reporting. + +For clarity, though, it may be a good idea to separate all of the +components of M_o and G_o into separate consensus parameters, and +combine them (via addition) in the final equations. That way it will be +easier to pinpoint the source of any potential overflow issues. This +separation will also enable us to potentially govern padding's +contribution to the overhead via a single tunable value. + +4.2 Integration with Guardfraction + +The GuardFraction changes in Proposal 236 and #16255 should continue to +work with these new equations, so long as the total T, G, and M values +are counted after the GuardFraction multiplier has been applied. + +4.3. Guard flag assignment + +Ideally, the Guard flag assignment process would also not count +Exit-flagged nodes when determining the Guard flag uptime and bandwidth +cutoffs, since we will not be using Guard+Exit flagged nodes as Guard +nodes at all when this change is applied. This will result in more +accurate thresholds for Guard node status, as well as better control +over the true total amount of Guard bandwidth in the consensus. + + + +1. https://trac.torproject.org/projects/tor/ticket/16255 +2. https://collector.torproject.org/archive/relay-descriptors/consensuses/ +3. http://tor-dev.torproject.narkive.com/17H9FewJ/correctness-proof-for-new-ba… + + +Appendix A: SymPy Script for Balancing Equation Solutions +#!/usr/bin/python +from sympy.solvers import solve +from sympy import simplify, Symbol, init_printing, pprint + +# Sympy variable declarations +(G,M,E,D) = (Symbol('G'),Symbol('M'),Symbol('E'),Symbol('D')) +(Wgd,Wmd,Wed,Wme,Wmg,Wgg,Wee) = (Symbol('Wgd'),Symbol('Wmd'),Symbol('Wed'), + Symbol('Wme'),Symbol('Wmg'),Symbol('Wgg'), + Symbol('Wee')) +(G_o, M_o) = (Symbol('G_o'),Symbol('M_o')) + +print "Current Load Balancing Equation Solutions, Case 1:" +pprint(solve( + [Wgg*G + Wgd*D - (M + Wmd*D + Wme*E + Wmg*G), + Wgg*G + Wgd*D - (Wee*E + Wed*D), + Wed*D + Wmd*D + Wgd*D - D, + Wmg*G + Wgg*G - G, + Wme*E + Wee*E - E, + Wmg - Wmd, + 3*Wed - 1], + Wgd, Wmd, Wed, Wme, Wmg, Wgg, Wee)) + +print +print "Case 1 with guard and middle overhead: " +pprint(solve( + [(1-G_o)*(Wgg*G + Wgd*D) - (1-M_o)*(M + Wmd*D + Wme*E + Wmg*G), + (1-G_o)*(Wgg*G + Wgd*D) - (Wee*E + Wed*D), + Wed*D + Wmd*D + Wgd*D - D, + Wmg*G + Wgg*G - G, + Wme*E + Wee*E - E, + Wmg - Wmd, + 3*Wed - 1], + Wgd, Wmd, Wed, Wme, Wmg, Wgg, Wee)) + +print "\n\n" +print "Elimination of combined Guard+Exit flags (no overhead): " +pprint(solve( + [(Wgg*G) - (M + Wme*E + Wmg*G), + (Wgg*G) - 1*(Wee*E), + Wmg*G + Wgg*G - G, + Wme*E + Wee*E - E], + Wme, Wmg, Wgg, Wee)) + +print +print "Elimination of combined Guard+Exit flags (Guard+middle overhead): " +combined = solve( + [(1-G_o)*(Wgg*G) - (1-M_o)*(M + Wme*E + Wmg*G), + (1-G_o)*(Wgg*G) - 1*(Wee*E), + Wmg*G + Wgg*G - G, + Wme*E + Wee*E - E], + Wme, Wmg, Wgg, Wee) +pprint(combined) +

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-commits January 2016