tor-commits January 2020

tor-commits@lists.torproject.org

19 participants
1596 discussions

[manual/develop] Change subsection title to h3
by emmapeel＠torproject.org 15 Jan '20

15 Jan '20

commit d3204996bb5118613cc8f28dc19449a27d2df91a Author: gus <gus(a)torproject.org> Date: Mon Oct 21 20:21:06 2019 -0400 Change subsection title to h3 --- content/circumvention/contents.lr | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/circumvention/contents.lr b/content/circumvention/contents.lr index 0079ff9..f4548bf 100644 --- a/content/circumvention/contents.lr +++ b/content/circumvention/contents.lr @@ -13,7 +13,7 @@ body: Direct access to the Tor network may sometimes be blocked by your Internet Service Provider or by a government. Tor Browser includes some circumvention tools for getting around these blocks. These tools are called “pluggable transports”. -## TYPES OF PLUGGABLE TRANSPORT +### TYPES OF PLUGGABLE TRANSPORT Currently there are three pluggable transports available, but more are being developed. @@ -47,7 +47,7 @@ meek </table> -## USING PLUGGABLE TRANSPORTS +### USING PLUGGABLE TRANSPORTS To use a pluggable transport, click 'Configure' when starting Tor Browser for the first time. In the window that appears, from the drop-down menu, select whichever pluggable transport you'd like to use.

1 0

[translation/support-portal] https://gitweb.torproject.org/translation.git/commit/?h=support-portal
by translation＠torproject.org 15 Jan '20

15 Jan '20

commit 14ea1519e2c071f833a3197dafe66cd51a99b4c2 Author: Translation commit bot <translation(a)torproject.org> Date: Wed Jan 15 12:54:00 2020 +0000 https://gitweb.torproject.org/translation.git/commit/?h=support-portal --- contents+ar.po | 12 ++++++++---- contents+es.po | 62 ++++++++++++++++++++++++++++++++-------------------------- contents+ru.po | 2 +- 3 files changed, 43 insertions(+), 33 deletions(-) diff --git a/contents+ar.po b/contents+ar.po index 94546fe236..04f317555e 100644 --- a/contents+ar.po +++ b/contents+ar.po @@ -6,9 +6,9 @@ # erinm, 2019 # Ahmed IB <mee.tbhole(a)gmail.com>, 2019 # ButterflyOfFire, 2019 -# Emma Peel, 2019 # Layla Taha <layla(a)asl19.org>, 2019 # Ahmed Essam, 2020 +# Emma Peel, 2020 # msgid "" msgstr "" @@ -16,7 +16,7 @@ msgstr "" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2020-01-15 13:12+CET\n" "PO-Revision-Date: 2018-10-02 22:41+0000\n" -"Last-Translator: Ahmed Essam, 2020\n" +"Last-Translator: Emma Peel, 2020\n" "Language-Team: Arabic (https://www.transifex.com/otf/teams/1519/ar/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -295,7 +295,7 @@ msgstr "" msgid "" "Tor Browser is specifically engineered to have a nearly identical (we're not" " perfect!) fingerprint across its users." -msgstr "" +msgstr "تمت هندسة متصفّح Tor ليعطي بصمة شبه متطابقة عبر متسخدميه المختلفين. " #: https//support.torproject.org/faq/faq-3/ #: (content/faq/faq-3/contents+en.lrquestion.description) @@ -357,6 +357,10 @@ msgid "" "[article](https://blog.torproject.org/browser-fingerprinting-introduction-" "and-challenges-ahead) on The Tor Blog all about it." msgstr "" +"هل تريديون أن تعرفون أكثر عن تبصيم المتصفّحات؟ هنا" +" " +"[مقال](https://blog.torproject.org/browser-fingerprinting-introduction-and-" +"challenges-ahead) على مدوّنة Tor يفسّره لكم. " #: https//support.torproject.org/faq/faq-4/ #: (content/faq/faq-4/contents+en.lrquestion.title) @@ -479,7 +483,7 @@ msgstr "" #: https//support.torproject.org/about/backdoor/ #: (content/about/backdoor/contents+en.lrquestion.description) msgid "Nobody would trust our software ever again - for excellent reasons!" -msgstr "" +msgstr "لن يثق أي أحد ببرنامجنا بعد ذلك - وسيكونون على حق في ذلك! " #: https//support.torproject.org/about/backdoor/ #: (content/about/backdoor/contents+en.lrquestion.description) diff --git a/contents+es.po b/contents+es.po index 5866303a7d..99c8b6acc8 100644 --- a/contents+es.po +++ b/contents+es.po @@ -6,7 +6,7 @@ # eulalio barbero espinosa <eulaliob(a)gmail.com>, 2019 # Nicolas Sera-Leyva <nseraleyva(a)internews.org>, 2019 # Joaquín Serna <bubuanabelas(a)cryptolab.net>, 2019 -# Emma Peel, 2019 +# Emma Peel, 2020 # msgid "" msgstr "" @@ -14,7 +14,7 @@ msgstr "" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2020-01-15 13:12+CET\n" "PO-Revision-Date: 2018-10-02 22:41+0000\n" -"Last-Translator: Emma Peel, 2019\n" +"Last-Translator: Emma Peel, 2020\n" "Language-Team: Spanish (https://www.transifex.com/otf/teams/1519/es/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -519,6 +519,8 @@ msgid "" "If we (or the distributors that gave you Tor) don't give you access to the " "source code, that's a sure sign something funny might be going on." msgstr "" +"Si nosotros (o los distribuidores que te dieron Tor) no te damos acceso al " +"código fuente, es una señal de que algo no va bien." #: https//support.torproject.org/about/backdoor/ #: (content/about/backdoor/contents+en.lrquestion.description) @@ -579,6 +581,7 @@ msgstr "" #: (content/about/can-i-use-tor-with/contents+en.lrquestion.description) msgid "Please add to this list and help us keep it accurate!" msgstr "" +"¡Por favor, contribuye a dicha lista y ayúdanos a mantenerla relevante!" #: https//support.torproject.org/about/can-i-use-tor-with/ #: (content/about/can-i-use-tor-with/contents+en.lrquestion.description) @@ -1033,7 +1036,7 @@ msgstr "¿Por qué se llama Tor?" #: https//support.torproject.org/about/why-is-it-called-tor/ #: (content/about/why-is-it-called-tor/contents+en.lrquestion.description) msgid "Tor is the onion routing network." -msgstr "" +msgstr "Tor es la red de enrutado en cebolla (the onion routing en inglés)." #: https//support.torproject.org/about/why-is-it-called-tor/ #: (content/about/why-is-it-called-tor/contents+en.lrquestion.description) @@ -1054,6 +1057,9 @@ msgid "" " of the actual [onion routing project](https://www.onion-router.net/) run by" " the Naval Research Lab." msgstr "" +"A pesar de que el enrutado en cebolla se ha convertido en un término de uso " +"interno, Tor nació del [proyecto de enrutado cebolla](https://www.onion-" +"router.net/) del laboratorio de investigación de la marina." #: https//support.torproject.org/about/why-is-it-called-tor/ #: (content/about/why-is-it-called-tor/contents+en.lrquestion.description) @@ -6751,8 +6757,8 @@ msgid "" " relays and periodically publishes a [consensus](#consensus) together with " "the other directory authorities." msgstr "" -"Un [repetidor](#relay) de propósito especial que mantiene una lista de los " -"repetidores actualmente en funcionamiento y publica periódicamente un " +"Un [repetidor](#relay) especial que mantiene una lista de los repetidores " +"actualmente en funcionamiento y publica periódicamente un " "[consenso](#consenso) junto con las otras autoridades del directorio." #: https//support.torproject.org/misc/glossary/ @@ -6808,9 +6814,9 @@ msgid "" "[IP address](#ip-address) of the exit." msgstr "" "El último [relay](#relay) en el [Tor circuit](#circuito) que envía " -"[traffic](#traffic) al Internet público. El servicio al que te estás " +"[tráfico](#traffic) al Internet público. El servicio al que te estás " "conectando (página web, servicio de chat, proveedor de correo electrónico, " -"etc.) verá la [IP address](#ip-address) de la salida." +"etc.) verá la [dirección IP](#ip-address) de la salida." #: https//support.torproject.org/misc/glossary/ #: (content/misc/glossary/contents+en.lrquestion.description) @@ -6844,8 +6850,8 @@ msgid "" "developed by the Mozilla Foundation and its subsidiary, the Mozilla " "Corporation." msgstr "" -"Mozilla Firefox es un [web browser](#navegador-web) libre y de código " -"abierto desarrollado por la Fundación Mozilla y su subsidiaria, Mozilla " +"Mozilla Firefox es un [navegador](#navegador-web) libre y de código abierto" +" desarrollado por la Fundación Mozilla y su subsidiaria, Mozilla " "Corporation." #: https//support.torproject.org/misc/glossary/ @@ -6854,7 +6860,7 @@ msgid "" "[Tor Browser](#tor-browser) is built from a modified version of Firefox ESR " "(Extended Support Release)." msgstr "" -"[Navegador Tor](#tor-browser) está construido a partir de una versión " +"El [Navegador Tor](#tor-browser) está construido a partir de una versión " "modificada de Firefox ESR (Extended Support Release)." #: https//support.torproject.org/misc/glossary/ @@ -6974,9 +6980,9 @@ msgid "" "[bridge](#bridge). When using a bridge, the bridge takes the place of the " "guard." msgstr "" -"El primer [relay](#relay) en el [Tor circuit](#circuito), a menos que se " -"utilice un [bridge](#bridge) Cuando se utiliza un puente, el puente toma el" -" lugar de guard." +"El primer [repetidor](#relay) en el [circuito de Tor](#circuito), a menos " +"que se utilice un [puente](#bridge) Cuando se utiliza un puente, el puente " +"toma el lugar de guard." #: https//support.torproject.org/misc/glossary/ #: (content/misc/glossary/contents+en.lrquestion.description) @@ -7086,7 +7092,7 @@ msgstr "" #: https//support.torproject.org/misc/glossary/ #: (content/misc/glossary/contents+en.lrquestion.description) msgid "HTTPS Everywhere is installed in [Tor Browser](#tor-browser)." -msgstr "HTTPS Everywhere está instalado en [Navegador Tor](#tor-browser)." +msgstr "HTTPS Everywhere está instalado en el [Navegador Tor](#tor-browser)." #: https//support.torproject.org/misc/glossary/ #: (content/misc/glossary/contents+en.lrquestion.description) @@ -7177,7 +7183,7 @@ msgid "" "Browser](#tor-browser) can be used to manage JavaScript on different " "websites." msgstr "" -"La [extensión](#add-on-extension-or-plugin) [NoScript](#noscript) en el " +"La [extensión](#add-on-extension-or-plugin) [NoScript](#noscript) en el " "[Navegador Tor](#tor-browser) se puede usar para gestionar JavaScript en los" " distintos sitios web." @@ -7241,8 +7247,8 @@ msgid "" "users." msgstr "" "La posición central en el [circuito de Tor](#circuito). Los repetidores no " -"de salida pueden funcionar como un \"middle\" o como un \"[guard](#guard)\"" -" para diferentes usuarios." +"de salida pueden funcionar como un \"middle\" o como un " +"\"[guarda](#guard)\" para diferentes usuarios." #: https//support.torproject.org/misc/glossary/ #: (content/misc/glossary/contents+en.lrquestion.description) @@ -7561,7 +7567,7 @@ msgid "" "The set of available [onion services](#onion-services). For example, you can" " say \"my site is in onionspace\" instead of \"my site is in the Dark Web.\"" msgstr "" -"El conjunto de [onion services](#onion-services) disponibles. Por ejemplo, " +"El conjunto de [servicios onion](#onion-services) disponibles. Por ejemplo, " "puedes decir \"mi sitio está en onionspace\" en lugar de \"mi sitio está en " "la Dark Web\"." @@ -7645,7 +7651,7 @@ msgid "" "[traffic](#traffic) it sends out." msgstr "" "Herramientas que [Tor](#tor-/-tor-network/-core-tor) puede usar para " -"disfrazar el [traffic](#traffic) que envía." +"disfrazar el [tráfico](#traffic) que envía." #: https//support.torproject.org/misc/glossary/ #: (content/misc/glossary/contents+en.lrquestion.description) @@ -7654,15 +7660,15 @@ msgid "" ")](#internet-service-provider-isp) or other authority is actively blocking " "connections to the [Tor network](#tor-/-tor-network/-core-tor)." msgstr "" -"Esto puede ser útil en situaciones donde un [Internet Service Provider (ISP" -")](#internet-service-provider-isp) u otra autoridad está bloqueando " +"Esto puede ser útil en situaciones donde un [proveedor de Internet (ISP" +")](#internet-service-provider-isp) u otra autoridad están bloqueando " "activamente las conexiones a la red [Tor](#tor-/-tor-network/-core-tore-" "tor)." #: https//support.torproject.org/misc/glossary/ #: (content/misc/glossary/contents+en.lrquestion.description) msgid "### private key" -msgstr "### private key" +msgstr "### clave privada" #: https//support.torproject.org/misc/glossary/ #: (content/misc/glossary/contents+en.lrquestion.description) @@ -7709,7 +7715,7 @@ msgstr "" #: https//support.torproject.org/misc/glossary/ #: (content/misc/glossary/contents+en.lrquestion.description) msgid "### public key" -msgstr "### public key" +msgstr "### clave pública" #: https//support.torproject.org/misc/glossary/ #: (content/misc/glossary/contents+en.lrquestion.description) @@ -7751,7 +7757,7 @@ msgid "" "receiver but only the receiver in possession of the private key is able to " "decrypt the message." msgstr "" -"Cualquier persona puede [encrypt](#encryption) un mensaje utilizando la " +"Cualquier persona puede [encriptar](#encryption) un mensaje utilizando la " "clave pública del receptor, pero sólo el receptor que posee la clave privada" " puede descifrar el mensaje." @@ -7766,7 +7772,7 @@ msgstr "" #: https//support.torproject.org/misc/glossary/ #: (content/misc/glossary/contents+en.lrquestion.description) msgid "This signature can be verified by the public key." -msgstr "Se puede verificar esta firma por la clave pública." +msgstr "Se puede verificar esta firma con la clave pública." #: https//support.torproject.org/misc/glossary/ #: (content/misc/glossary/contents+en.lrquestion.description) @@ -7857,7 +7863,7 @@ msgstr "" #: https//support.torproject.org/misc/glossary/ #: (content/misc/glossary/contents+en.lrquestion.description) msgid "### server" -msgstr "### server" +msgstr "### servidor" #: https//support.torproject.org/misc/glossary/ #: (content/misc/glossary/contents+en.lrquestion.description) @@ -7869,7 +7875,7 @@ msgstr "" #: https//support.torproject.org/misc/glossary/ #: (content/misc/glossary/contents+en.lrquestion.description) msgid "### session" -msgstr "### session" +msgstr "### sesión" #: https//support.torproject.org/misc/glossary/ #: (content/misc/glossary/contents+en.lrquestion.description) @@ -7921,7 +7927,7 @@ msgstr "" #: https//support.torproject.org/misc/glossary/ #: (content/misc/glossary/contents+en.lrquestion.description) msgid "### Sybil attack" -msgstr "### Sybil attack" +msgstr "### ataque Sybil" #: https//support.torproject.org/misc/glossary/ #: (content/misc/glossary/contents+en.lrquestion.description) diff --git a/contents+ru.po b/contents+ru.po index 213f7e405f..59a64c7f73 100644 --- a/contents+ru.po +++ b/contents+ru.po @@ -1052,7 +1052,7 @@ msgstr "" #: https//support.torproject.org/about/why-is-it-called-tor/ #: (content/about/why-is-it-called-tor/contents+en.lrquestion.description) msgid "(It's also got a fine meaning in German and Turkish.)" -msgstr "" +msgstr "(В немецком и турецком языках это слово имеет другие значения)." #: https//support.torproject.org/about/why-is-it-called-tor/ #: (content/about/why-is-it-called-tor/contents+en.lrquestion.description)

1 0

[torspec/master] Prop306: Add revisions suggested in Torspec PR #87
by teor＠torproject.org 15 Jan '20

15 Jan '20

commit 84c2af5931f5c4b24dfc473da860bc7aba0a7763 Author: Neel Chauhan <neel(a)neelc.org> Date: Thu Dec 5 13:26:49 2019 -0500 Prop306: Add revisions suggested in Torspec PR #87 --- proposals/306-ipv6-happy-eyeballs.txt | 240 ++++++++++++++-------------------- 1 file changed, 95 insertions(+), 145 deletions(-) diff --git a/proposals/306-ipv6-happy-eyeballs.txt b/proposals/306-ipv6-happy-eyeballs.txt index a096384..5055cc6 100644 --- a/proposals/306-ipv6-happy-eyeballs.txt +++ b/proposals/306-ipv6-happy-eyeballs.txt @@ -9,20 +9,20 @@ Ticket: https://trac.torproject.org/projects/tor/ticket/29801 1. Introduction As IPv4 address space becomes scarce, ISPs and organizations will deploy - IPv6 in their networks. Right now, Tor clients connect to guards using + IPv6 in their networks. Right now, Tor clients connect to entry nodes using IPv4 connectivity by default. When networks first transition to IPv6, both IPv4 and IPv6 will be enabled on most networks in a so-called "dual-stack" configuration. This is to not break existing IPv4-only applications while enabling IPv6 connectivity. However, IPv6 connectivity may be unreliable and clients should be able - to connect to the guard using the most reliable technology, whether IPv4 - or IPv6. + to connect to the entry node using the most reliable technology, whether + IPv4 or IPv6. In ticket #27490, we introduced the option ClientAutoIPv6ORPort which lets a client randomly choose between IPv4 or IPv6. However, this random decision does not take into account unreliable connectivity - or falling back to the competing IP version should one be unreliable + or falling back to the alternate IP version should one be unreliable or unavailable. One way to select between IPv4 and IPv6 on a dual-stack network is a @@ -48,135 +48,103 @@ Ticket: https://trac.torproject.org/projects/tor/ticket/29801 This section describes the necessary changes for address selection to implement Prop306. -2.1. Extend Info Structure Changes +2.1. Address Handling Changes To be able to handle Happy Eyeballs in Tor, we will need to modify the - data structures used for connections to guards, namely the extend info + data structures used for connections to entry nodes, namely the extend info structure. - The extend info structure should contain both an IPv4 and an IPv6 address. - This will allow us to try IPv4 and the IPv6 addresses should both be - available on a relay and the client is dual-stack. + Entry nodes are usually guards, but some clients don't use guards: - When parsing relay descriptors and filling in the extend info data - structure, we need to fill in both the IPv4 and IPv6 address if they both - are available. If only one family is available for a relay (IPv4 or IPv6), - we should fill in the address for preferred family and leave the alternate - family null. + * Bootstrapping clients can connect to fallback directory mirrors or + authorities -2.2. Relay Selection Changes - - In Proposal 283, we have allowed microdescriptor consensus documents to - contain IPv6 addresses. As clients download microdescriptors, Prop283 - makes it possible to implement Prop306. - - When we select candidates for the entry guard, we should select at least - one relay with an IPv6 address. This makes it possible for an IPv6-only - client to bootstrap. Otherwise we would have failures if all the selected - guard candidates only have IPv4 addresses. - -3. Relay Connections + * v3 single onion services can use IPv4 or IPv6 addresses to connect + to introduction and rendezvous points, and - If there is an existing authenticated connection, we should use it - similar to how we used it pre-Prop306. + * Clients can be configured to disable entry guards - If there is no existing authenticated connection for an extend info, - we should attempt to connect using the first available, allowed, and - preferred address. + Bridges are out of scope for this proposal, because Tor does not support + multiple IP addresses in a single bridge line. - We should also allow falling back to the alternate address. For this, - three alternate designs will be given. - -3.1. Proposed Designs - - This subsection will have three proposed designs for connecting to relays - via IPv4 and IPv6 in a Tor implementation of Happy Eyeballs. - - These proposed designs will have some tradeoffs, including: - - * Launching multiple TCP connections places up to 2x extra socket load on - dual-stack relays and authorities, because both connections may succeed. - - * Launching multiple TLS connections places up to 2x the CPU load on - dual-stack relays and authorities, because both connections may succeed. - - * Increasing the delay between connections mitigates the above issues, - but reduces perceived performance, particularly at bootstrap time - (pre-emptive circuits hide these delays after bootstrap). + The extend info structure should contain both an IPv4 and an IPv6 address. + This will allow us to try IPv4 and the IPv6 addresses should both be + available on a relay and the client is dual-stack. - The proposed designs are as listed as follows: + When parsing relay descriptors and filling in the extend info data + structure, we need to fill in both the IPv4 and IPv6 address if both are + available. If only one family is available for a relay (IPv4 or IPv6), we + should fill in the address for preferred family and leave the alternate + family null. - * Section 3.1.1: First Successful Authentication +2.2. Guard Selection Changes - * Section 3.1.2: TCP Connection to Preferred Address On First Authenticated - Connection + In Proposal 283, we have allowed microdescriptor consensus documents + to contain IPv6 addresses. As most clients download microdescriptor + consensuses, Prop283 makes it possible to implement Prop306. - * Section 3.1.3: TCP Connection to Preferred Address On First TCP Success + When we select candidates for the entry node, we should have an option + for the number of entry guards. The parameter is as follows: -3.1.1. First Successful Authentication + * NumIPv6Guards NUM - In this design, Tor will first connect to the preferred address and - attempt to authenticate. After a 1.5 second delay (based on Onionperf - data), Tor will connect to the alternate address and try to authenticate. - On the first successful authenticated connection, we close the other - connection. + If UseEntryGuards is set to 1, we will try to pick NUM routers that support + IPv6 for our primary guard list, which is the set of routers we strongly + prefer when connecting to the Tor network. If NUM is 0, we try to learn the + number from the guard-n-primary-guards-ipv6 consensus parameter, and default + to 1 if the consensus parameter isn’t set. - This design places the least connection load on the network, but might - add extra TLS load. + The default value for NumIPv6Guards should be 0. -3.1.2. TCP Connection to Preferred Address On First Authenticated Connection +3. Relay Connections - This design attempts a TCP connection to a preferred address. On a failure - or a 1.5 second delay, we try the alternative address. + If there is an existing authenticated connection, we must use it similar + to how we used it pre-Prop306. - On the first successful TCP connection Tor attempts to authenticate - immediately. On the first authentication success, Tor closes the other - connection. + If there is no existing authenticated connection for an entry node, we + must attempt to connect using the first available, allowed, and preferred + address. - This design is the most reliable for clients, but increases the connection - load on dual-stack guards and authorities. For instance, this can be used - to amplify a DoS attack on the Tor network. + We should also allow falling back to the alternate address. For this, + a design will be given in Section 3.1. -3.1.3. TCP Connection to Preferred Address On First TCP Success +3.1. TCP Connection to Preferred Address On First TCP Success - In this design, we will connect via TCP to the first preferred address. On - a failure or after a 1.5 second delay, we attempt to connect via TCP to the - alternate address. On a success, Tor attempts to authenticate and closes - the other connection. + In this design, we will connect via TCP to the first preferred address. + On a failure or after a 250 ms delay, we attempt to connect via TCP to + the alternate address. On a success, Tor attempts to authenticate and + closes the other connection. - This design is the closest to RFC 8305 and is similar to how Happy Eyeballs + This design is close to RFC 8305 and is similar to how Happy Eyeballs is implemented in a web browser. -3.2. Recommendations for Implementation of Section 3.1 Proposals - - We should start with implementing and testing the implementation as - described in Section 3.1.1 (First Successful Authentication), and then - doing the same for the implementations described in 3.1.2 and 3.1.3 if - desired or required. +3.2. Handling Connection Successes And Failures -3.3. Handling Connection Successes And Failures - - Should a connection to a guard succeed and is authenticated via TLS, we - can then use the connection. In this case, we should cancel all other + Should a connection to a entry node succeed and is authenticated via TLS, + we can then use the connection. In this case, we should cancel all other connection timers and in-progress connections. Cancelling the timers is necessary so we don't attempt new unnecessary connections when our existing connection is successful, preventing denial-of-service risks. However, if we fail all available and allowed connections, we should tell the rest of Tor that the connection has failed. This is so we can attempt - another guard relay. + another entry node. -3.4. Connection Attempt Delays +3.3. Connection Attempt Delays As mentioned in [TEOR-P306-REP], initially, clients should prefer IPv4 by default. The Connection Attempt Delay, or delay between IPv4 and IPv6 - connections should be 1.5 seconds. This is to avoid the overhead from - tunneled IPv6 connections. + connections should be 250 ms. This is to avoid the overhead from tunneled + IPv6 connections. The Minimum Connection Attempt Delay should not be dynamically adjusted as it adds privacy risks. This value should be fixed at 10 ms as per - RFC 8305 and could be adjusted using a proposed consensus parameter called - ConnectionAttemptDelay. ConnectionAttemptDelay should be in milliseconds. + RFC 8305 and could be adjusted using this proposed consensus parameter: + + * ConnectionAttemptDelay N msec + + Where N is the number of milliseconds for the network-wide Minimum + Connection Attempt Delay. The Maximum Connection Attempt Delay should also not be dynamically adjusted for privacy reasons, but the maximum should be higher than the RFC 8305 @@ -193,8 +161,6 @@ Ticket: https://trac.torproject.org/projects/tor/ticket/29801 adjust the default options to enable IPv6 while not breaking IPv4-only clients. -4.1. New Default Options for Prop306 - The new default options should be: * ClientUseIPv4 as 1 (to enable IPv4) @@ -204,6 +170,9 @@ Ticket: https://trac.torproject.org/projects/tor/ticket/29801 * ClientPreferIPv6ORPort as 0 (for load-balancing reasons so we don't overload IPv6-only guards) + * ConnectionAttemptDelay 10 (for 10 msec, the minimum delay between + IPv4 and IPv6) + One thing to note is that clients should be able to connect with the above options on IPv4-only, dual-stack, and IPv6-only networks, and they should also work if ClientPreferIPv6ORPort is 1. This means we shouldn't expect @@ -212,41 +181,26 @@ Ticket: https://trac.torproject.org/projects/tor/ticket/29801 When the majority of clients are IPv6-capable, we could set the default value of ClientPreferIPv6ORPort to 1 in order to take advantage of IPv6. -4.2. Prop306 Consensus Parameters - - We could have the following consensus parameters: +5. Relay Statistics - * ClientUseIPv6 + Entry nodes could measure the following statistics from clients for both + IPv4 and IPv6: - * ClientPreferIPv6ORPort (when most of the guards have IPv6 and it is fast) + * Number of successful connections - Should we have the consenus parameters, the values for these options should - be set to the values of the similarly-named options as described in Section - 4.1 including the consideration for ClientPreferIPv6ORPort. + * Number of failed connections -5. Statistics + * Number of timed out connections -5.1. Relay Statistics + Should we implement Section 5: - Relays could measure the number of successful IPv4 and IPv6 connections. - We could also send this information to directory authorities. + * We could send this information to directory authorities - However, should we implement Section 5.1, we should consider the privacy - implications of these statistics, and whether they should be public or not. + * We should consider the privacy implications of these statistics -5.2. Client Heartbeat Messages + * If submitted to dirauths, whether these should be public or not - In a Tor session, we should count the number of IPv4 and IPv6 connections - to ORPorts, and distinguish between authenticated (relay, authority - reachability) and unauthenticated (client, bridge) connections. These - statistics should be included in the Heartbeat logs. - -6. Deploying Prop306 - - This section describes the information necessary for deployment of Prop306 - on Tor clients and in Tor Browser. - -6.1. Initial Feasibility Testing +6. Initial Feasibility Testing We should test this proposal with the following scenarios: @@ -254,46 +208,42 @@ Ticket: https://trac.torproject.org/projects/tor/ticket/29801 ClientUseIPv6, and ClientPreferIPv6ORPort on IPv4-only, IPv6-only, and dual-stack connections - * Dual-stack connections of different technologies, including high-bandwidth - and low-latency (e.g. fiber), moderate-bandwidth and moderate-latency - (e.g. DSL, LTE), and high-latency and low-bandwidth (e.g. satellite, - dial-up) to see if Prop306 is reliable and feasible + * Dual-stack connections of different technologies, including + high-bandwidth and low-latency (e.g. FTTH), moderate-bandwidth and + moderate-latency (e.g. DSL, LTE), and high-latency and low-bandwidth + (e.g. satellite, dial-up) to see if Prop306 is reliable and feasible -6.2. Minimum Viable Prop306 Product +7. Minimum Viable Prop306 Product The mimumum viable product for Prop306 must include the following: - * Implementation of one of the algorithms in Section 3.1 along with the - changes described in Sections 2.1 and 2.2 + * Implementation of the algorithm in Section 3.1 along with the changes + described in Sections 2.1 and 2.2 - * The Connection Success/Failure mechanism in Section 3.3 and Connection - Delay mechanism in Section 3.4 (the consensus parameter is optional) + * The Connection Success/Failure mechanism in Section 3.2 and Connection + Delay mechanism in Section 3.3 (the consensus parameter is optional) * A default setup capable of both IPv4 and IPv6 connections with the options described in Section 4.1 -6.3. Optional Features +8. Optional Features Some features which are optional include: - * Consensus Parameter ConnectionAttemptDelay (Section 3.4) - We will need + * Consensus Parameter ConnectionAttemptDelay (Section 3.3) - We will need this if the Minimum Connection Attempt Delay needs to be dynamically - adjusted - - * Consensus Parameters ClientUseIPv6 (Section 4.2), and - ClientPreferIPv6ORPort (Section 4.2) - We will need this if we desire - the ability for clients to prefer IPv6 when the majority of clients - and relays are IPv6-capable without changing the configuration + adjusted, for instance, if clients often fail IPv6 connections - * Prop306 Statistics (Section 5) - While optional, this may be useful for - debugging and reliability testing, and metrics on IPv4 vs. IPv6 + * Prop306 Statistics (Section 5) - While optional, this may be useful + for debugging and reliability testing, and metrics on IPv4 vs IPv6 -7. Acknowledgments +9. Acknowledgments - Thank you so much to teor for the discussion of the happy eyeballs proposal. - I wouldn't have been able to do this has it not been for your help. + Thank you so much to teor for your discussion on this happy eyeballs + proposal. I wouldn't have been able to do this has it not been for + your help. -8. Refrences +10. Refrences [P299-TRAC]: https://trac.torproject.org/projects/tor/ticket/29801

1 0

[torspec/master] Prop 306: Minor fixes and tidying up
by teor＠torproject.org 15 Jan '20

15 Jan '20

commit a78e23a053415a2aa498ff611e4131762a264d53 Author: teor <teor(a)torproject.org> Date: Mon Jan 13 20:21:40 2020 +1000 Prop 306: Minor fixes and tidying up * modify design to match Tor's typical design patterns * add some missing info and special cases * improve formatting and consistency * fix some typos Part of 29801. --- proposals/306-ipv6-happy-eyeballs.txt | 109 ++++++++++++++++++++-------------- 1 file changed, 66 insertions(+), 43 deletions(-) diff --git a/proposals/306-ipv6-happy-eyeballs.txt b/proposals/306-ipv6-happy-eyeballs.txt index 5055cc6..25381ad 100644 --- a/proposals/306-ipv6-happy-eyeballs.txt +++ b/proposals/306-ipv6-happy-eyeballs.txt @@ -71,28 +71,35 @@ Ticket: https://trac.torproject.org/projects/tor/ticket/29801 This will allow us to try IPv4 and the IPv6 addresses should both be available on a relay and the client is dual-stack. - When parsing relay descriptors and filling in the extend info data - structure, we need to fill in both the IPv4 and IPv6 address if both are - available. If only one family is available for a relay (IPv4 or IPv6), we - should fill in the address for preferred family and leave the alternate - family null. + When processing: + * relay descriptors, + * hard-coded authority and fallback directory lists, + * onion service descriptors, or + * onion service introduce cells, + and filling in the extend info data structure, we need to fill in both the + IPv4 and IPv6 address if both are available. If only one family is + available for a relay (IPv4 or IPv6), we should leave the other family null. 2.2. Guard Selection Changes - In Proposal 283, we have allowed microdescriptor consensus documents - to contain IPv6 addresses. As most clients download microdescriptor - consensuses, Prop283 makes it possible to implement Prop306. - When we select candidates for the entry node, we should have an option - for the number of entry guards. The parameter is as follows: + When we select guard candidates, we should have an option for the number of + primary IPv6 entry guards. The parameter is as follows: * NumIPv6Guards NUM - If UseEntryGuards is set to 1, we will try to pick NUM routers that support - IPv6 for our primary guard list, which is the set of routers we strongly - prefer when connecting to the Tor network. If NUM is 0, we try to learn the - number from the guard-n-primary-guards-ipv6 consensus parameter, and default - to 1 if the consensus parameter isn’t set. + If UseEntryGuards is set to 1, we will try to pick NUM relays that support + IPv6 for our primary guard list, which is the set of relays we strongly + prefer when connecting to the Tor network. (This number should also apply + to all of Tor's other guard lists, scaled up based on the relative size of + the list.) + + If NUM is -1, we try to learn the number from the NumIPv6Guards + consensus parameter. If the consensus parameter isn't set, we should + default to 1. + + The default value for NumIPv6Guards should be -1. (Use the consensus + parameter, or the default value.) The default value for NumIPv6Guards should be 0. @@ -101,9 +108,10 @@ Ticket: https://trac.torproject.org/projects/tor/ticket/29801 If there is an existing authenticated connection, we must use it similar to how we used it pre-Prop306. - If there is no existing authenticated connection for an entry node, we - must attempt to connect using the first available, allowed, and preferred - address. + If there is no existing authenticated connection for an entry node, tor + currently attempts to connect using the first available, allowed, and + preferred address. (Determined using the existing Client IPv4 and IPv6 + options.) We should also allow falling back to the alternate address. For this, a design will be given in Section 3.1. @@ -111,7 +119,7 @@ Ticket: https://trac.torproject.org/projects/tor/ticket/29801 3.1. TCP Connection to Preferred Address On First TCP Success In this design, we will connect via TCP to the first preferred address. - On a failure or after a 250 ms delay, we attempt to connect via TCP to + On a failure or after a 250 msec delay, we attempt to connect via TCP to the alternate address. On a success, Tor attempts to authenticate and closes the other connection. @@ -134,7 +142,7 @@ Ticket: https://trac.torproject.org/projects/tor/ticket/29801 As mentioned in [TEOR-P306-REP], initially, clients should prefer IPv4 by default. The Connection Attempt Delay, or delay between IPv4 and IPv6 - connections should be 250 ms. This is to avoid the overhead from tunneled + connections should be 250 msec. This is to avoid the overhead from tunneled IPv6 connections. The Minimum Connection Attempt Delay should not be dynamically adjusted @@ -151,8 +159,8 @@ Ticket: https://trac.torproject.org/projects/tor/ticket/29801 recommendation of 2 seconds. For Tor, we should make this timeout value 30 seconds to match Tor's existing timeout. - We should also make it possible for users to set the Maximum Connection - Attempt value higher for slower and higher-latency networks such as dial-up + We need to make it possible for users to set the Maximum Connection Attempt + Delay value higher for slower and higher-latency networks such as dial-up and satellite. 4. Option Changes @@ -163,11 +171,11 @@ Ticket: https://trac.torproject.org/projects/tor/ticket/29801 The new default options should be: - * ClientUseIPv4 as 1 (to enable IPv4) + * ClientUseIPv4 1 (to enable IPv4) - * ClientUseIPv6 as 1 (to enable IPv6) + * ClientUseIPv6 1 (to enable IPv6) - * ClientPreferIPv6ORPort as 0 (for load-balancing reasons so we don't + * ClientPreferIPv6ORPort 0 (for load-balancing reasons so we don't overload IPv6-only guards) * ConnectionAttemptDelay 10 (for 10 msec, the minimum delay between @@ -175,30 +183,30 @@ Ticket: https://trac.torproject.org/projects/tor/ticket/29801 One thing to note is that clients should be able to connect with the above options on IPv4-only, dual-stack, and IPv6-only networks, and they should - also work if ClientPreferIPv6ORPort is 1. This means we shouldn't expect - IPv4 or IPv6 to work if ClientUseIPv4 or ClientUseIPv6 is set. + also work if ClientPreferIPv6ORPort is 1. But we shouldn't expect + IPv4 or IPv6 to work if ClientUseIPv4 or ClientUseIPv6 is set to 0. - When the majority of clients are IPv6-capable, we could set the default - value of ClientPreferIPv6ORPort to 1 in order to take advantage of IPv6. + When the majority of clients and relay are IPv6-capable, we could set the + default value of ClientPreferIPv6ORPort to 1, in order to take advantage + of IPv6. 5. Relay Statistics - Entry nodes could measure the following statistics from clients for both - IPv4 and IPv6: + Entry nodes could measure the following statistics for both IPv4 and IPv6: - * Number of successful connections + * Number of successful connections - * Number of failed connections - - * Number of timed out connections + * Number of unsuccessful or cancelled connections + * Client closes the connection before completing TLS + * Client closes the connection before sending any circuit or data cells Should we implement Section 5: - * We could send this information to directory authorities - - * We should consider the privacy implications of these statistics + * We can send this information to the directory authorities using relay + extra-info descriptors - * If submitted to dirauths, whether these should be public or not + * We should consider the privacy implications of these statistics, and + how much noise we need to add to them 6. Initial Feasibility Testing @@ -220,8 +228,11 @@ Ticket: https://trac.torproject.org/projects/tor/ticket/29801 * Implementation of the algorithm in Section 3.1 along with the changes described in Sections 2.1 and 2.2 - * The Connection Success/Failure mechanism in Section 3.2 and Connection - Delay mechanism in Section 3.3 (the consensus parameter is optional) + * The Connection Success/Failure mechanism in Section 3.2. + + * The Connection Delay mechanism in Section 3.3. (The + ConnectionAttemptDelay torrc option and consensus parameter are + optional.) * A default setup capable of both IPv4 and IPv6 connections with the options described in Section 4.1 @@ -230,12 +241,24 @@ Ticket: https://trac.torproject.org/projects/tor/ticket/29801 Some features which are optional include: + * Single Onion services: extend info address changes for onion service + descriptors and introduce cells. (Section 2.1.) + + * Bridge clients are out of scope: they would require bridge line format + changes, internal bridge data structure changes, and extend info address + changes. (Section 2.1.) + + * NumIPv6Guards torrc option and consensus parameter. We may need this + option if the proposed default doesn't work for some clients. + (Section 2.3.) + * Consensus Parameter ConnectionAttemptDelay (Section 3.3) - We will need this if the Minimum Connection Attempt Delay needs to be dynamically adjusted, for instance, if clients often fail IPv6 connections - * Prop306 Statistics (Section 5) - While optional, this may be useful - for debugging and reliability testing, and metrics on IPv4 vs IPv6 + * IPv4, IPv6, and Prop306 connection Statistics. While optional, this may + be useful for debugging and reliability testing, and metrics on IPv4 vs + IPv6. (Section 5.) 9. Acknowledgments

1 0

[torspec/master] Prop 306: Improve load-balancing for NumIPv6Guards
by teor＠torproject.org 15 Jan '20

15 Jan '20

commit f5c6f61cc9833d5de9d4c36e26a3e21ec701f7cf Author: teor <teor(a)torproject.org> Date: Mon Jan 13 20:29:14 2020 +1000 Prop 306: Improve load-balancing for NumIPv6Guards The previous design would have doubled the load on IPv6-supporting relays. Part of 29801. --- proposals/306-ipv6-happy-eyeballs.txt | 39 +++++++++++++++++++++++++++++------ 1 file changed, 33 insertions(+), 6 deletions(-) diff --git a/proposals/306-ipv6-happy-eyeballs.txt b/proposals/306-ipv6-happy-eyeballs.txt index d24fe63..a7faa3a 100644 --- a/proposals/306-ipv6-happy-eyeballs.txt +++ b/proposals/306-ipv6-happy-eyeballs.txt @@ -88,8 +88,8 @@ Ticket: https://trac.torproject.org/projects/tor/ticket/29801 * NumIPv6Guards NUM - If UseEntryGuards is set to 1, we will try to pick NUM relays that support - IPv6 for our primary guard list, which is the set of relays we strongly + If UseEntryGuards is set to 1, we will select exactly this number of IPv6 + relays for our primary guard list, which is the set of relays we strongly prefer when connecting to the Tor network. (This number should also apply to all of Tor's other guard lists, scaled up based on the relative size of the list.) @@ -99,9 +99,33 @@ Ticket: https://trac.torproject.org/projects/tor/ticket/29801 default to 1. The default value for NumIPv6Guards should be -1. (Use the consensus - parameter, or the default value.) + parameter, or the underlying default value of 1.) - The default value for NumIPv6Guards should be 0. + As of September 2019, approximately 20% of Tor's guards supported IPv6, + by consensus weight. (Excluding exits that are also guards, because + clients avoid choosing exits in their guard lists.) + + If all Tor clients implement NumIPv6Guards, then these 20% of guards will + handle approximately 33% of Tor's traffic. (Because the default value of + NumPrimaryGuards is 3.) This may have a significant impact on Tor's + load-balancing. Therefore, we should deploy this feature gradually, and try + to increase the number of relays that support IPv6 to at least 33%. + + To minimise the impact on load-balancing, IPv6 support should only be + required for exactly NumIPv6Guards during guard list selection. All other + guards should be IPv4-only guards. Once approximately 50% of guards support + IPv6, NumIPv6Guards can become a minimum requirement, rather than an exact + requirement. + + The minimum configurable value of NumIPv6Guards is -1. (Use the consensus + parameter, or the underlying default.) + + The minimum resulting value of NumIPv6Guards is 0. (Guards will be chosen + at random, regardless of their IPv6 ORPorts.) + + The maximum value of NumIPv6Guards should be the configured value of + NumPrimaryGuards. (Every guard must have an IPv6 ORPort. This setting is + equivalent to ClientPreferIPv6ORPort 1.) 3. Relay Connections @@ -224,8 +248,11 @@ Ticket: https://trac.torproject.org/projects/tor/ticket/29801 The mimumum viable product for Prop306 must include the following: - * Implementation of the algorithm in Section 3.1 along with the changes - described in Sections 2.1 and 2.2 + * The address handling and entry guard changes described in + Section 2. (Single Onion Services are optional, Bridge Clients are out + of scope. The consensus parameter and torrc options are optional.) + + * The alternative address retry algorithm in Section 3.1. * The Connection Success/Failure mechanism in Section 3.2.

1 0

[torspec/master] Prop 306: Improve ConnectionAttemptDelay design
by teor＠torproject.org 15 Jan '20

15 Jan '20

commit ed8452b9e85385579ea902777d19ec0252b4e4c5 Author: teor <teor(a)torproject.org> Date: Mon Jan 13 20:25:40 2020 +1000 Prop 306: Improve ConnectionAttemptDelay design Have a single ConnectionAttemptDelay option, with a default value of 250 msec based on RFC 8305. Part of 29801. --- proposals/306-ipv6-happy-eyeballs.txt | 27 +++++++++++++-------------- 1 file changed, 13 insertions(+), 14 deletions(-) diff --git a/proposals/306-ipv6-happy-eyeballs.txt b/proposals/306-ipv6-happy-eyeballs.txt index 25381ad..3d5c92c 100644 --- a/proposals/306-ipv6-happy-eyeballs.txt +++ b/proposals/306-ipv6-happy-eyeballs.txt @@ -145,17 +145,15 @@ Ticket: https://trac.torproject.org/projects/tor/ticket/29801 connections should be 250 msec. This is to avoid the overhead from tunneled IPv6 connections. - The Minimum Connection Attempt Delay should not be dynamically adjusted - as it adds privacy risks. This value should be fixed at 10 ms as per - RFC 8305 and could be adjusted using this proposed consensus parameter: + The Connection Attempt Delay should not be dynamically adjusted, as it adds + privacy risks. This value should be fixed, and could be manually adjusted + using this torrc option or consensus parameter: - * ConnectionAttemptDelay N msec + * ConnectionAttemptDelay N [msec|second] - Where N is the number of milliseconds for the network-wide Minimum - Connection Attempt Delay. - - The Maximum Connection Attempt Delay should also not be dynamically adjusted - for privacy reasons, but the maximum should be higher than the RFC 8305 + The Minimum and Maximum Connection Attempt Delays should also not be + dynamically adjusted for privacy reasons. The Minimum should be fixed at + 10 msec as per RFC 8305. But the maximum should be higher than the RFC 8305 recommendation of 2 seconds. For Tor, we should make this timeout value 30 seconds to match Tor's existing timeout. @@ -178,8 +176,8 @@ Ticket: https://trac.torproject.org/projects/tor/ticket/29801 * ClientPreferIPv6ORPort 0 (for load-balancing reasons so we don't overload IPv6-only guards) - * ConnectionAttemptDelay 10 (for 10 msec, the minimum delay between - IPv4 and IPv6) + * ConnectionAttemptDelay 250 msec (the recommended delay between IPv4 + and IPv6, as per RFC 8305) One thing to note is that clients should be able to connect with the above options on IPv4-only, dual-stack, and IPv6-only networks, and they should @@ -252,9 +250,10 @@ Ticket: https://trac.torproject.org/projects/tor/ticket/29801 option if the proposed default doesn't work for some clients. (Section 2.3.) - * Consensus Parameter ConnectionAttemptDelay (Section 3.3) - We will need - this if the Minimum Connection Attempt Delay needs to be dynamically - adjusted, for instance, if clients often fail IPv6 connections + * ConnectionAttemptDelay torrc option and consensus parameter. We will need + this option if the Connection Attempt Delay needs to be manually + adjusted, for instance, if clients often fail IPv6 connections. + (Section 3.3.) * IPv4, IPv6, and Prop306 connection Statistics. While optional, this may be useful for debugging and reliability testing, and metrics on IPv4 vs

1 0

[torspec/master] Prop 306: Add an optional ClientPreferIPv6ORPort consensus parameter
by teor＠torproject.org 15 Jan '20

15 Jan '20

commit 6664ed79ed4688209065e39a4eafb5e2bb59de66 Author: teor <teor(a)torproject.org> Date: Mon Jan 13 20:27:24 2020 +1000 Prop 306: Add an optional ClientPreferIPv6ORPort consensus parameter Part of 29801. --- proposals/306-ipv6-happy-eyeballs.txt | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/proposals/306-ipv6-happy-eyeballs.txt b/proposals/306-ipv6-happy-eyeballs.txt index 3d5c92c..d24fe63 100644 --- a/proposals/306-ipv6-happy-eyeballs.txt +++ b/proposals/306-ipv6-happy-eyeballs.txt @@ -186,7 +186,8 @@ Ticket: https://trac.torproject.org/projects/tor/ticket/29801 When the majority of clients and relay are IPv6-capable, we could set the default value of ClientPreferIPv6ORPort to 1, in order to take advantage - of IPv6. + of IPv6. We could add a ClientPreferIPv6ORPort consensus parameter, so we + can make this change network-wide. 5. Relay Statistics @@ -233,7 +234,8 @@ Ticket: https://trac.torproject.org/projects/tor/ticket/29801 optional.) * A default setup capable of both IPv4 and IPv6 connections with the - options described in Section 4.1 + options described in Section 4. (The ClientPreferIPv6ORPort consensus + parameter is optional.) 8. Optional Features @@ -255,6 +257,8 @@ Ticket: https://trac.torproject.org/projects/tor/ticket/29801 adjusted, for instance, if clients often fail IPv6 connections. (Section 3.3.) + * ClientPreferIPv6ORPort consensus parameter. (Section 4.) + * IPv4, IPv6, and Prop306 connection Statistics. While optional, this may be useful for debugging and reliability testing, and metrics on IPv4 vs IPv6. (Section 5.)

1 0

[torspec/master] Merge remote-tracking branch 'tor-github/pr/102'
by teor＠torproject.org 15 Jan '20

15 Jan '20

commit ff165e0f449d09ee3c872016e5abc35cf75e918c Merge: 36b3b2c e27cbca Author: teor <teor(a)torproject.org> Date: Wed Jan 15 22:50:10 2020 +1000 Merge remote-tracking branch 'tor-github/pr/102' proposals/306-ipv6-happy-eyeballs.txt | 340 +++++++++++++++++++--------------- 1 file changed, 193 insertions(+), 147 deletions(-)

1 0

[torspec/master] Prop 306: Add a bootstrap changes section
by teor＠torproject.org 15 Jan '20

15 Jan '20

commit 21aaad10e60b667a7de896ffcb42667567fbe53c Author: teor <teor(a)torproject.org> Date: Mon Jan 13 20:31:00 2020 +1000 Prop 306: Add a bootstrap changes section Clients need to change how they select fallback directory mirrors during bootstrap, or some IPv6-only clients will fail to bootstrap. Part of 29801. --- proposals/306-ipv6-happy-eyeballs.txt | 41 +++++++++++++++++++++++++++++++++-- 1 file changed, 39 insertions(+), 2 deletions(-) diff --git a/proposals/306-ipv6-happy-eyeballs.txt b/proposals/306-ipv6-happy-eyeballs.txt index a7faa3a..27a59f2 100644 --- a/proposals/306-ipv6-happy-eyeballs.txt +++ b/proposals/306-ipv6-happy-eyeballs.txt @@ -80,8 +80,42 @@ Ticket: https://trac.torproject.org/projects/tor/ticket/29801 IPv4 and IPv6 address if both are available. If only one family is available for a relay (IPv4 or IPv6), we should leave the other family null. -2.2. Guard Selection Changes +2.2 Bootstrap Changes + Tor's hard-coded authority and fallback directory mirror lists contain + some entries with IPv6 ORPorts. As of January 2020, 56% of authorities and + 47% of fallback directories have IPv6. + + During bootstrapping, we should have an option for the maximum number of + IPv4-only nodes, before the next node must have an IPv6 ORPort. The + parameter is as follows: + + * MaxNumIPv4BootstrapAttempts NUM + + During bootstrap, the minimum fraction of nodes with IPv6 ORPorts will be + 1/(1 + MaxNumIPv4BootstrapAttempts). And the average fraction will be + larger than both minimum fraction, and the actual proportion of IPv6 + ORPorts in the fallback directory list. (Clients mainly use fallback + directories for bootstrapping.) + + Since this option is used during bootstrapping, it can not have a + corresponding consensus parameter. + + The default value for MaxNumIPv4BootstrapAttempts should be 2. This + means that every third bootstrap node must have an IPv6 ORPort. And on + average, just over half of bootstrap nodes chosen by clients will have an + IPv6 ORPort. This change won't have much impact on load-balancing, because + almost half the fallback directory mirrors have IPv6 ORPorts. + + The minimum value of MaxNumIPv4BootstrapAttempts is 0. (Every bootstrap + node must have an IPv6 ORPort. This setting is equivalent to + ClientPreferIPv6ORPort 1.) + + The maximum value of MaxNumIPv4BootstrapAttempts should be 100. (Since + most clients only make a few bootstrap connections, bootstrap nodes will + be chosen at random, regardless of their IPv6 ORPorts.) + +2.3. Guard Selection Changes When we select guard candidates, we should have an option for the number of primary IPv6 entry guards. The parameter is as follows: @@ -248,7 +282,7 @@ Ticket: https://trac.torproject.org/projects/tor/ticket/29801 The mimumum viable product for Prop306 must include the following: - * The address handling and entry guard changes described in + * The address handling, bootstrap, and entry guard changes described in Section 2. (Single Onion Services are optional, Bridge Clients are out of scope. The consensus parameter and torrc options are optional.) @@ -275,6 +309,9 @@ Ticket: https://trac.torproject.org/projects/tor/ticket/29801 changes, internal bridge data structure changes, and extend info address changes. (Section 2.1.) + * MaxNumIPv4BootstrapAttempts torrc option. We may need this option if + the proposed default doesn't work for some clients. (Section 2.2.) + * NumIPv6Guards torrc option and consensus parameter. We may need this option if the proposed default doesn't work for some clients. (Section 2.3.)

1 0

[torspec/master] Prop 306: Restore some statistics from an earlier draft
by teor＠torproject.org 15 Jan '20

15 Jan '20

commit e27cbca30600faf9db14404ae87d9798c3f0e4b1 Author: teor <teor(a)torproject.org> Date: Wed Jan 15 22:40:44 2020 +1000 Prop 306: Restore some statistics from an earlier draft These statistics are optional, but they may be useful: * client and relay connections * statistics in the heartbeat logs Also improve the explanation of the "extra prop 306 connections" statistic. Part of 29801. --- proposals/306-ipv6-happy-eyeballs.txt | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/proposals/306-ipv6-happy-eyeballs.txt b/proposals/306-ipv6-happy-eyeballs.txt index 27a59f2..c5c9ddf 100644 --- a/proposals/306-ipv6-happy-eyeballs.txt +++ b/proposals/306-ipv6-happy-eyeballs.txt @@ -253,10 +253,14 @@ Ticket: https://trac.torproject.org/projects/tor/ticket/29801 * Number of successful connections - * Number of unsuccessful or cancelled connections + * Number of extra Prop306 connections (unsuccessful or cancelled) * Client closes the connection before completing TLS * Client closes the connection before sending any circuit or data cells + * Number of client and relay connections + * We can distinguish between authenticated (relay, authority + reachability) and unauthenticated (client, bridge) connections + Should we implement Section 5: * We can send this information to the directory authorities using relay @@ -265,6 +269,8 @@ Ticket: https://trac.torproject.org/projects/tor/ticket/29801 * We should consider the privacy implications of these statistics, and how much noise we need to add to them + * We can include these statistics in the Heartbeat logs + 6. Initial Feasibility Testing We should test this proposal with the following scenarios: @@ -323,9 +329,9 @@ Ticket: https://trac.torproject.org/projects/tor/ticket/29801 * ClientPreferIPv6ORPort consensus parameter. (Section 4.) - * IPv4, IPv6, and Prop306 connection Statistics. While optional, this may - be useful for debugging and reliability testing, and metrics on IPv4 vs - IPv6. (Section 5.) + * IPv4, IPv6, client, relay, and extra Prop306 connection statistics. + While optional, these statistics may be useful for debugging and + reliability testing, and metrics on IPv4 vs IPv6. (Section 5.) 9. Acknowledgments

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-commits January 2020