tor-commits February 2020

tor-commits@lists.torproject.org

22 participants
1454 discussions

[torspec/master] Prop 312: Add libevent DNS API
by teor＠torproject.org 05 Feb '20

05 Feb '20

commit 492549864e51fdc30195f1be467af6e463ba6fb2 Author: teor <teor(a)torproject.org> Date: Wed Feb 5 10:55:04 2020 +1000 Prop 312: Add libevent DNS API As suggested by Nick Mathewson. Part of 33073. --- proposals/312-relay-auto-ipv6-addr.txt | 32 ++++++++++++++++++++++++++++---- 1 file changed, 28 insertions(+), 4 deletions(-) diff --git a/proposals/312-relay-auto-ipv6-addr.txt b/proposals/312-relay-auto-ipv6-addr.txt index 31a5dd7..ed5ebac 100644 --- a/proposals/312-relay-auto-ipv6-addr.txt +++ b/proposals/312-relay-auto-ipv6-addr.txt @@ -1070,7 +1070,7 @@ Ticket: #33073 method will find the IP address of the default route, in most cases (see section 3.2.5). -3.5.9. Add IPv6 Support Using gethostbyname2() +3.5.9. Add IPv6 Support via Other DNS APIs We propose these optional changes, to add IPv6 support to hostname resolution on older OSes. These changes affect: @@ -1082,8 +1082,14 @@ Ticket: #33073 Directory authorities do not use this address detection method to discover their own addresses, for security reasons. - Use gethostbyname2() to add IPv6 support to hostname resolution on older - OSes, which don't support getaddrinfo(). + Tor currently uses getaddrinfo() on most systems, which supports IPv6 DNS. + But tor also supports the legacy gethostbyname() DNS API, which does not + support IPv6. + + There are two alternative APIs we could use for IPv6 DNS, if getaddrinfo() + is not available: + * libevent DNS API, and + * gethostbyname2(). But this change may be unnecessary, because: * Linux has used getaddrinfo() by default since glibc 2.20 (2014) @@ -1092,7 +1098,23 @@ Ticket: #33073 getaddrinfo() in a similar timeframe * Windows has supported getaddrinfo() since Windows Vista; tor's minimum supported Windows version is Vista. - See [Tor Supported Platforms] for more details. + See [Tor Supported Platforms] for more detai + + If a large number of systems do not support getaddrinfo(), we propose + implementing one of these alternatives: + + The libevent DNS API supports IPv6 DNS, and tor already has a dependency on + libevent. Therefore, we should prefer the libevent DNS API. (Unless we find + it difficult to implement.) + + We could also use gethostbyname2() to add IPv6 support to hostname + resolution on older OSes, which don't support getaddrinfo(). + + Handling multiple addresses: + + When looking up hostnames using libevent, the DNS callbacks provide a list + of all addresses received. Therefore, we should ignore any private + addresses, and then choose the first address in the list. When looking up hostnames using gethostbyname() or gethostbyname2(), if the first address is a private address, we may want to look at the entire list @@ -1105,6 +1127,8 @@ Ticket: #33073 (On OSes that support getaddrinfo(), tor searches the list of addresses for a publicly routable address.) + Alternative change: remove gethostbyname(): + As an alternative, if we believe that all supported OSes have getaddrinfo(), we could simply remove the gethostbyname() code, rather than trying to modify it to work with IPv6.

1 0

[community/master] Update GSoC Project descriptions
by pili＠torproject.org 05 Feb '20

05 Feb '20

commit 5e7203d4925992265aeb1b876c5df629b299e87f Author: Pili Guerra <pili(a)piliguerra.com> Date: Wed Feb 5 12:36:31 2020 +0100 Update GSoC Project descriptions --- content/gsoc/onion-toolbox/contents.lr | 34 ++++++++++++---------- .../gsoc/ooni-explorer-advanced-search/contents.lr | 18 ++++++++---- content/gsoc/ooni-probe-experiments/contents.lr | 16 ++++++---- 3 files changed, 42 insertions(+), 26 deletions(-) diff --git a/content/gsoc/onion-toolbox/contents.lr b/content/gsoc/onion-toolbox/contents.lr index bae15c0..1d52e87 100644 --- a/content/gsoc/onion-toolbox/contents.lr +++ b/content/gsoc/onion-toolbox/contents.lr @@ -29,24 +29,31 @@ title: Onion Tool Box --- subtitle: -Myonion is a developer tool box, providing a command line interface and a GUI to configure and deploy existing services via .onion. A minimal prototype for myonion already [exists](https://github.com/hiromipaw/myonion). - -Someone that may want to run an onion service can use the myonion wrapper app to start a .onion from their computer and sharea static website or a web application. - -Myonion can also be used to deploy the resulting configured app to a defined set of cloud providers. - +Myonion is a developer tool box, providing a command line interface and a GUI to configure and deploy existing services via .onion. The idea behind myonion is to make onion services accessible to developers that might be interested to innovate in the privacy space, building applications that are designed for privacy and security. --- body: -## Problem definition +# Problem It is not necessarily difficult to use onion services, but it might be tricky to configure a web service to be offered via .onion so that it doesn’t leak sensitive information. There are detailed [guides](https://riseup.net/en/security/network-security/tor/onionservices-b… available for users that would like to offer a web application via .onion and some tools have been developed to help service operators: discover known misconfiguration or [vulnerabilities](https://onionscan.org/) or deploy an [onion site](https://github.com/alecmuffett/eotk). -## Scope +Involving a wider developer community can help creating a better image of Tor and onion services, replacing the “dark net” narrative with the secure and private web one. + +Onion services can also be relevant to all those people interested in the “zero-trust” strategy. The concept behind zero-trust is to adopt strategies and tools to help prevent data breaches by eliminating the concept of trust from an organization’s network architecture, with the principle of never trust, always verify. -Myonion provides a way to build and deploy onion ready applications, allowing developers to build and test web applications and easily share them with others, bundling the code and configuration in a lightweight, portable Docker container application that runs thesame everywhere. +Ultimately myonion is about creating a better experience for onion services developers and operators and therefore fostering a more legitimate onion service ecosystem. + +# Proposal + +Myonion is a developer tool box, providing a command line interface and a GUI to configure and deploy existing services via .onion. A minimal prototype for myonion already [exists](https://github.com/hiromipaw/myonion). + +Someone that may want to run an onion service can use the myonion wrapper app to start a .onion from their computer and sharea static website or a web application. + +Myonion can also be used to deploy the resulting configured app to a defined set of cloud providers. + +Myonion provides a way to build and deploy onion ready applications, allowing developers to build and test web applications and easily share them with others, bundling the code and configuration in a lightweight, portable Docker container application that runs the same everywhere. The experience for developers will be similar to using other industry solutions, like the [Docker desktop app](https://www.docker.com/products/docker-desktop). @@ -54,12 +61,7 @@ Developers using myonion are provided with pre-defined and customizable applicat The resulting application is therefore deployable via a set of endpoint management tools to known providers. Providing a way to deploy onion services at scale. -## Impact +# Resources -The idea behind myonion is to make onion services accessible to developers that might be interested to innovate in the privacy space, building applications that are designed for privacy and security. +- Myonion repo on github: https://github.com/hiromipaw/myonion -Involving a wider developer community can help creating a better image of Tor and onion services, replacing the “dark net” narrative with the secure and private web one. - -Onion services can also be relevant to all those people interested in the “zero-trust” strategy. The concept behind zero-trust is to adopt strategies and tools to help prevent data breaches by eliminating the concept of trust from an organization’s network architecture, with the principle of never trust, always verify. - -Ultimately myonion is about creating a better experience for onion services developers and operators and therefore fostering a more legitimate onion service ecosystem. diff --git a/content/gsoc/ooni-explorer-advanced-search/contents.lr b/content/gsoc/ooni-explorer-advanced-search/contents.lr index b4d883c..cd3f5d6 100644 --- a/content/gsoc/ooni-explorer-advanced-search/contents.lr +++ b/content/gsoc/ooni-explorer-advanced-search/contents.lr @@ -28,11 +28,18 @@ title: OONI Explorer Advanced Search --- subtitle: -This project is about enriching the OONI Explorer search functionality with the ability to visualize an analysis of metadata pertaining to filtered measurements. - +OONI Explorer is an open data resource on internet censorship around the world. This project is about enriching the OONI Explorer search functionality with the ability to visualize an analysis of metadata pertaining to filtered measurements. --- body: +# Problem + + + +# Proposal + +This project is about enriching the OONI Explorer search functionality with the ability to visualize an analysis of metadata pertaining to filtered measurements. + This would involve adding the ability to filter on multiple axis: country, ASN, time range, anomaly, confirmed, failure, domain or input, citizenlab category code. The results would then be presented in an aggregate form, such as showing: @@ -46,8 +53,9 @@ These results could then be presented as a table or some other charts, such as a Some other more detailed, drill-down views could also be implemented. -A potential applicant should also have some prior design +A potential applicant should also have some prior design experience + +# Resources -- *Prerequisites:* API call to be implemented by Federico -- *Links/Resource:* https://github.com/ooni/explorer +- OONI Explorer repo on github: https://github.com/ooni/explorer diff --git a/content/gsoc/ooni-probe-experiments/contents.lr b/content/gsoc/ooni-probe-experiments/contents.lr index c6426ef..4d5d2f7 100644 --- a/content/gsoc/ooni-probe-experiments/contents.lr +++ b/content/gsoc/ooni-probe-experiments/contents.lr @@ -28,16 +28,22 @@ title: OONI Probe network experiments --- subtitle: -As part of this project you would be working on researching and developing new OONI Probe network experiments. +OONI Probe is a free software project that aims to uncover internet censorship around the world. As part of this project you would be working on researching and developing new OONI Probe network experiments. --- body: -These experiments would be integrated inside of probe-engine and could eventually make their way into the OONI Probe desktop client. +# Problem + +# Proposal + +*Prerequisites:* Knowledge of network programming + +As part of this project you would be working on researching and developing new OONI Probe network experiments. These experiments would be integrated inside of probe-engine and could eventually make their way into the OONI Probe desktop client. The GSoC project is only about researching and implementing a working test in probe-engine, not the UI and client integration of the test. -For some inspiration on some ideas for new experiments, see: https://github.com/ooni/probe-engine/issues?q=is%3Aopen+is%3Aissue+label%3A… +# Resources -Prerequisites: Knowledge of network programming -Links/Resources: https://github.com/ooni/probe-engine \ No newline at end of file +- OONI Probe repo on github: https://github.com/ooni/probe-engine +- [Ideas for new experiments](https://github.com/ooni/probe-engine/issues?q=is%3Aopen+is%3Ai… \ No newline at end of file

1 0

[community/master] Update content for OONI GSoC projects
by pili＠torproject.org 05 Feb '20

05 Feb '20

commit 3d86d5893b03a05ca8957ec2264d9b195c15fb35 Author: Pili Guerra <pili(a)piliguerra.com> Date: Wed Feb 5 13:05:30 2020 +0100 Update content for OONI GSoC projects --- content/gsoc/ooni-explorer-advanced-search/contents.lr | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/gsoc/ooni-explorer-advanced-search/contents.lr b/content/gsoc/ooni-explorer-advanced-search/contents.lr index cd3f5d6..be381fd 100644 --- a/content/gsoc/ooni-explorer-advanced-search/contents.lr +++ b/content/gsoc/ooni-explorer-advanced-search/contents.lr @@ -32,9 +32,9 @@ OONI Explorer is an open data resource on internet censorship around the world. --- body: -# Problem - +# Background +OONI Explorer is an open data resource on internet censorship around the world. This project is about enriching the OONI Explorer search functionality with the ability to visualize an analysis of metadata pertaining to filtered measurements. # Proposal

1 0

[community/master] Update content for OONI GSoC projects
by pili＠torproject.org 05 Feb '20

05 Feb '20

commit 36511588e98db38b9bdc0030e4ea9b4ed5358fdc Author: Pili Guerra <pili(a)piliguerra.com> Date: Wed Feb 5 13:04:39 2020 +0100 Update content for OONI GSoC projects --- content/gsoc/ooni-probe-experiments/contents.lr | 14 +++++++++++++- content/gsoc/privacy-aware-geo-lookup/contents.lr | 17 +++++++++++++---- 2 files changed, 26 insertions(+), 5 deletions(-) diff --git a/content/gsoc/ooni-probe-experiments/contents.lr b/content/gsoc/ooni-probe-experiments/contents.lr index 4d5d2f7..1eb568e 100644 --- a/content/gsoc/ooni-probe-experiments/contents.lr +++ b/content/gsoc/ooni-probe-experiments/contents.lr @@ -33,7 +33,19 @@ OONI Probe is a free software project that aims to uncover internet censorship a --- body: -# Problem +# Background + +The Open Observatory of Network Interference (OONI) is a free software project which aims to empower decentralized efforts in increasing transparency of internet censorship around the world. + +We develop free and open source software, called OONI Probe, that users can run to measure: + +- Blocking of websites; +- Blocking of instant messaging apps (WhatsApp, Facebook Messenger and Telegram); +- Blocking of censorship circumvention tools (such as Tor); +- Presence of systems (middleboxes) in your network that might be responsible for censorship and/or surveillance; +- Speed and performance of your network. + +By running OONI Probe, users can collect data that can potentially serve as evidence of internet censorship since it shows how, when, where, and by whom it is implemented. # Proposal diff --git a/content/gsoc/privacy-aware-geo-lookup/contents.lr b/content/gsoc/privacy-aware-geo-lookup/contents.lr index 1a58eb2..e170747 100644 --- a/content/gsoc/privacy-aware-geo-lookup/contents.lr +++ b/content/gsoc/privacy-aware-geo-lookup/contents.lr @@ -17,6 +17,7 @@ key: 6 languages: Golang Java +Android --- org: OONI --- @@ -26,7 +27,7 @@ Arturo Filastò --- difficulty: Medium --- -title: OONI Probe network experiments +title: Privacy aware geo lookup --- subtitle: @@ -35,13 +36,21 @@ The idea for this project is to research a way to do a GPS based location lookup --- body: +# Problem + When looking at OONI Probe measurements we often face a challenge in properly understanding what country (or more granular location) they are telling us things about. Often times the location information (since it's based on geoip) is inaccurate, because the underlying GeoIP database we used was old. On the other hand we also have a responsibility to protect user privacy to the extent that it's possible and therefore we don't collect IPs or store location information that is more granular than country level. -See: https://github.com/ooni/probe-engine/issues/249 +# Proposal +*Prerequisites:* familiarity with Android development and aptitude for research + +The idea for this project is to research a way to do a GPS based location lookup which resolves the location of the user to a granularity which is useful for qualifying measurements, but that doesn’t compromise users safety and privacy. + +# Resources + +- OONI Probe engine repo on github: https://github.com/ooni/probe-engine -Prerequisites: familiarity with Android development and aptitude for research -Links/Resource: https://github.com/ooni/probe-engine/issues/249 \ No newline at end of file +For the original ticket and discussion, please see ticket [249](https://github.com/ooni/probe-engine/issues/249) \ No newline at end of file

1 0

[torspec/master] Prop 311: IPv6 ORPort Reachability - Initial Draft
by teor＠torproject.org 05 Feb '20

05 Feb '20

commit d719ac402283b847b5f712a54ccdf118c7828fca Author: teor <teor(a)torproject.org> Date: Fri Jan 24 16:13:01 2020 +1000 Prop 311: IPv6 ORPort Reachability - Initial Draft Related tickets: 24404 (proposal), 24403 (implementation). --- proposals/311-relay-ipv6-reachability.txt | 645 ++++++++++++++++++++++++++++++ 1 file changed, 645 insertions(+) diff --git a/proposals/311-relay-ipv6-reachability.txt b/proposals/311-relay-ipv6-reachability.txt new file mode 100644 index 0000000..bb7062d --- /dev/null +++ b/proposals/311-relay-ipv6-reachability.txt @@ -0,0 +1,645 @@ +Filename: 311-relay-ipv6-reachability.txt +Title: Tor Relay IPv6 Reachability +Author: teor +Created: 22-January-2020 +Status: Draft +Ticket: #24404 + +0. Abstract + + We propose that Tor relays and bridges should check the reachability of + their IPv6 ORPort, before publishing their descriptor. To check IPv6 ORPort + reachability, relays and bridges need to be able to extend circuits via + other relays, and back to their own IPv6 ORPort. + +1. Introduction + + Tor relays and bridges currently check the reachability of their IPv4 + ORPort and DirPort before publishing them in their descriptor. But relays + and bridges do not test the reachability of their IPv6 ORPorts. + + However, Directory Authorities make direct connections to relay IPv4 and + IPv6 ORPorts, to test each relay's reachability. Once a relay has been + confirmed as reachable by a majority of authorities, it is included in the + consensus. (Currently, 6 out of 9 Directory Authorities perform IPv4 and + IPv6 reachability checks. The others just check IPv4.) + + The Bridge authority makes direct connections to bridge IPv4 ORPorts, to + test each bridge's reachability. Depending on its configuration, it may also + test IPv6 ORPorts. Once a bridge has been confirmed as reachable by the + bridge authority, it is included in the bridge networkstatus used by + BridgeDB. + + Many relay and bridge operators don't know when their relay's IPv6 ORPort is + unreachable. They may not find out until they check [Relay Search], or + their traffic may drop. For new operators, it might just look like Tor + simply isn't working, or it isn't using much traffic. IPv6 ORPort issues + are a significant source of relay and bridge operator support requests. + + Implementing IPv6 ORPort reachability checks will provide immediate, direct + feedback to operators in the relay or bridge's logs. It also enables future + work, such as automatically discovering relay and bridge addresses for IPv6 + ORPorts (see [Proposal 312]). + +2. Scope + + This proposal modifies Tor's behaviour as follows: + + Relays: + * circuit extension, + * OR connections for circuit extension, + * reachability testing. + + Bridges: + * reachability testing only. + + This proposal does not change client behaviour. + + When this proposal describes Tor's current behaviour, it covers all + supported Tor versions (0.3.5.7 to 0.4.2.5), as of January 2020. + +3. Allow Relay IPv6 Extends + + To check IPv6 ORPort reachability, relays and bridges need to be able to + extend circuits via other relays, and back to their own IPv6 ORPort. + + We propose that relays start to extend some circuits over IPv6 connections. + We do not propose any changes to bridge extend behaviour. + +3.1. Current IPv6 ORPort Implementation + + Currently, all relays and bridges must have an IPv4 ORPort. IPv6 ORPorts + are optional for relays and bridges. + + Tor supports making direct IPv6 OR connections: + * from directory authorities to relay ORPorts, + * from the bridge authority to bridge ORPorts, + * from clients to relay and bridge ORPorts. + + Tor relays and bridges accept IPv6 ORPort connections. But IPv6 ORPorts are + not currently included in extend requests to other relays. And even if an + extend cell contains an IPv6 ORPort, bridges and relays will not extend + via an IPv6 connection to another relay. + + Instead, relays will extend circuits: + * Using an existing authenticated connection to the requested relay + (which is typically over IPv4), or + * Over a new connection via the IPv4 ORPort in an extend cell. + + If a relay receives an extend cell that only contains an IPv6 ORPort, the + extend typically fails. + +3.2. Relays Extend to IPv6 ORPorts + + We propose that relays make some connections via the IPv6 ORPorts in + extend cells. + + Relays will extend circuits: + * using an existing authenticated connection to the requested relay + (which may be over IPv4 or IPv6), or + * over a new connection via the IPv4 or IPv6 ORPort in an extend cell. + + Since bridges try to imitate client behaviour, they will not adopt this new + behaviour, until clients begin routinely connecting via IPv6. (See + [Proposal 306].) + +3.2.1. Making IPv6 ORPort Extend Connections + + Relays can make a new connection over IPv6 when: + * there is no existing authenticated connection to the requested relay, + and + * the extend cell contains an IPv6 ORPort. + + If these conditions are satisfied, and the extend cell also contains an + IPv4 ORPort, we propose that the relay choose between an IPv4 and an IPv6 + connection at random. + + If the extend cell does not contain an IPv4 ORPort, we propose that the + relay connects over IPv6. (Relays should support IPv6-only extend cells, + even though they are not used to test relay reachability in this proposal.) + + A successful IPv6 connection also requires that: + * the requested relay has an IPv6 ORPort. + But extending relays must not check the consensus for other relays' IPv6 + information. Consensuses may be out of date, particularly when relays are + doing reachability checks for new IPv6 ORPorts. + + See section 3.3.2 for other situations where IPv6 information may be + incorrect or unavailable. + +3.2.2. No Tor Client Changes + + Tor clients currently include IPv4 ORPorts in their extend cells, but they + do not include IPv6 ORPorts. + + We do not propose any client IPv6 extend cell changes at this time. + + The Tor network needs more IPv6 relays, before clients can safely use + IPv6 extends. (Relays do not require anonymity, so they can safely use + IPv6 extends to test their own reachability.) + + We also recommend prioritising client to relay IPv6 connections + (see [Proposal 306]) over relay to relay IPv6 connections. Because client + IPv6 connections have a direct impact on users. + +3.3. Alternative Extend Designs + + We briefly mention some potential extend designs, and the reasons that + they were not used in this proposal. + + (Some designs may be proposed for future Tor versions, but are not necessary + at this time.) + +3.3.1. Future Relay IPv6 Extend Behaviour + + Random selection of extend ORPorts is a simple design, which supports IPv6 + ORPort reachability checks. + + However, it is not the most efficient design when: + * both relays meet the requirements for IPv4 and IPv6 extends, + * a new connection is required, + * the relays have either IPv4 or IPv6 connectivity, but not both. + + In this very specific case, this proposal results in an average of 1 + circuit extend failure per new connection. (Because relays do not try to + connect to the other ORPort when the first one fails.) + + If relays try both the IPv4 and IPv6 ORPorts, then the circuit would + succeed. For example, relays could try the alternative port after a 250ms + delay, as in [Proposal 306]. This design results in an average circuit delay + of up to 125ms per new connection, rather than failure. + + However, partial relay connectivity should be uncommon. And relays keep + connections open long-term, so new relay connections are a small proportion + of extend requests. + + Therefore, we defer implementing any more complex designs. Since we propose + to use IPv6 extends to test relay reachability, occasional circuit extend + failures have a very minor impact. + +3.3.2. Future Bridge IPv6 Extend Behaviour + + When clients automatically connect to relay IPv4 and IPv6 ORPorts by + default, bridges should also adopt this behaviour. (For example, + see [Proposal 306].) + +3.3.3. Rejected Extend Designs + + Some designs may never be suitable for the Tor network. + + We rejected designs where relays check the consensus to see if other + relays support IPv6, because: + * relays may have different consensuses, + * the extend cell may have been created using a version of the + [Onion Service Protocol] which supports IPv6, or + * the extend cell may be from a relay that has just added IPv6, and is + testing the reachability of its own ORPort (see Section 4). + + We avoided designs where relays try to learn if other relays support IPv6, + because these designs: + * are more complex than random selection, + * potentially leak information between different client circuits, + * may enable denial of service attacks, where a flood of incorrect extend + cells causes a relay to believe that another relay is unreachable on an + ORPort that actually works, and + * require careful tuning to match the typical interval at which network + connectivity is actually changing. + +4. Check Relay and Bridge IPv6 ORPort Reachability + + We propose that relays and bridges check their own IPv6 ORPort reachability. + + To check IPv6 ORPort reachability, relays and bridges extend circuits via + other relays, and back to their own IPv6 ORPort. + + IPv6 reachability failures may result in a relay or bridge refusing to + publish its descriptor, if enough existing relays support IPv6 extends. + +4.1. Current Reachability Implementation + + Relays and bridges check the reachability of their IPv4 ORPorts and + DirPorts, and refuse to publish their descriptor if either reachability + check fails. + + IPv4 ORPort reachability checks succeed when any create cell is received on + any inbound OR connection. The check succeeds, even if the cell is from an + IPv6 ORPort, or a circuit built by a client. + + Directory Authorities make direct connections to relay IPv4 and IPv6 + ORPorts, to test each relay's reachability. Relays that fail either + reachability test, on enough directory authorities, are excluded from the + consensus. + + The Bridge authority makes direct connections to bridge IPv4 ORPorts, to + test each bridge's reachability. Depending on its configuration, it may also + test IPv6 ORPorts. Bridges that fail either reachability test are excluded + from BridgeDB. + +4.2. Checking IPv6 ORPort Reachability + + We propose that testing relays (and bridges) select some IPv6 extend-capable + relays for their reachability circuits, and include their own IPv4 and IPv6 + ORPorts in the final extend cells on those circuits. + + The final extending relay will extend to the testing relay: + * using an existing authenticated connection to the testing relay + (which may be over IPv4 or IPv6), or + * over a new connection via the IPv4 or IPv6 ORPort in the extend cell. + + The testing relay will confirm that test circuits can extend to both its + IPv4 and IPv6 ORPorts. + +4.2.1. Selecting the Final Extending Relay + + IPv6 ORPort reachability checks require an IPv6 extend-capable relay as + the second-last hop of reachability circuits. (The testing relay is the + last hop.) + + IPv6-extend capable relays must have: + * Relay subprotocol version 3 (or later), and + * an IPv6 ORPort. + (See section 5.1 for the definition of Relay subprotocol version 3.) + + The other relays in the path do not require any particular protocol + versions. + +4.2.2. Extending from the Second-Last Hop + + IPv6 ORPort reachability circuits should put the IPv4 and IPv6 ORPorts in + the extend cell for the final extend in reachability circuits. + + Supplying both ORPorts makes these extend cells indistinguishable from + future client extend cells. + + If reachability succeeds, the testing relay (or bridge) will accept the + final extend on one of its ORPorts, selected at random by the extending + relay (see section 3.2.1). + +4.2.3. Separate IPv4 and IPv6 Reachability Flags + + Testing relays (and bridges) will record reachability separately for IPv4 + and IPv6 ORPorts, based on the ORPort that the test circuit was received on. + +4.2.4. No Changes to DirPort Reachability + + We do not propose any changes to relay IPv4 DirPort reachability checks at + this time. + + The following configurations are currently not supported: + * bridge DirPorts, and + * relay IPv6 DirPorts. + Therefore, they are also out of scope for this proposal. + +4.3. Refuse to Publish Descriptor if IPv6 ORPort is Unreachable + + If an IPv6 ORPort reachability check fails, relays (and bridges) should log + a warning. + + In addition, if IPv6ORPort reachability checks are reliable, based on the + number of relays in the network that support IPv6 extends, relays should + refuse to publish their descriptor. + +4.3.1. Refusing to Publish the Descriptor + + We set a threshold of consensus relays for reliable IPv6 ORPort checks: + * at least 30 relays, and + * at least 1% of the total consensus weight, + must support IPv6 extends. + + We chose these parameters so that the number of relays is triple the + number of directory authorities, and the consensus weight is high enough + to support occasional reachability circuits. + + In small networks with: + * less than 2000 relays, or + * a total consensus weight of zero, + the threshold should be the minimum tor network size to test reachability: + * at least 2 relays, excluding this relay. + (Note: we may increase this threshold to 3 or 4 relays if we discover a + higher minimum during testing.) + + If the current consensus satisfies this threshold, testing relays (and + bridges) that fail IPv6 ORPort reachability checks should refuse to publish + their descriptors. + + To ensure an accurate threshold, testing relays should exclude: + * the testing relay itself, and + * relays that they will not use in testing circuits, + from the: + * relay count, and + * the numerator of the threshold percentage. + + Typically, relays will be excluded if they are in the testing relay's: + * family, + * IPv4 address /16 network, + * IPv6 address /32 network (a requirement as of Tor 0.4.0.1-alpha), + unless EnforceDistinctSubnets is 0. + + As a useful side-effect, these different thresholds for each relay family + will reduce the likelihood of the network flapping around the threshold. + + If flapping has an impact on the network health, directory authorities + should set the AssumeIPv6Reachable consensus parameter. (See the next + section.) + +4.3.2. Add AssumeIPv6Reachable Option + + We add an AssumeIPv6Reachable torrc option and consensus parameter. + + If IPv6 ORPort checks have bugs that impact the health of the network, + they can be disabled by setting AssumeIPv6Reachable=1 in the consensus + parameters. + + If IPv6 ORPort checks have bugs that impact a particular relay (or bridge), + they can be disabled by setting "AssumeIPv6Reachable 1" in the relay's + torrc. + + This option disables IPv6 ORPort reachability checks, so relays publish + their descriptors if their IPv4 ORPort reachability checks succeed. + + The default for the torrc option is "auto", which checks the consensus + parameter. If the consensus parameter is not set, the default is "0". + + "AssumeReachable 1" overrides all values of "AssumeIPv6Reachable", + disabling both IPv4 and IPv6 ORPort reachability checks. + +4.4. Optional Efficiency and Reliability Changes + + We propose some optional changes for efficiency and reliability, and + describe their impact. + + Some of these changes may be more appropriate in future releases, or + along with other proposed features. + +4.4.1. Extend IPv6 From All Supported Second-Last Hops + + The testing relay (or bridge) puts both IPv4 and IPv6 ORPorts in its final + extend cell, and the receiving ORPort is selected at random by the + extending relay (see sections 3.2.1 and 4.2). Therefore, approximately half + of IPv6 ORPort reachability circuits will actually end up confirming IPv4 + ORPort reachability. + + We propose this optional change, to improve the rate of IPv6 ORPort + reachability checks: + + If the second-last hop of an IPv4 ORPort reachability circuit supports IPv6 + extends, testing relays may put the IPv4 and IPv6 ORPorts in the extend + cell for the final extend. + + As the number of relays that support IPv6 extends increases, this change + will increase the number of IPv6 reachability confirmations. In the ideal + case, where the entire network supports IPv4 and IPv6 extends, IPv4 and IPv6 + ORPort reachability checks would require a similar number of circuits. + +4.4.2. Close Existing Connections Before Testing Reachability + + When a busy relay is performing reachability checks, it may already have + established inbound or outbound connections to the second-last hop in its + reachability test circuits. The extending relay may use these connections + for the extend, rather than opening a connection to the target ORPort + (see sections 3.2 and 4.2.2). + + Bridges only establish outbound connections to other relays, and only over + IPv4 (except for reachability test circuits). So they are still potentially + affected by this issue. + + We propose these optional changes, to improve the efficiency of IPv4 and + IPv6 ORPort reachability checks: + + Testing relays (and bridges): + * close any outbound connections to the second-last hop of reachability + circuits, and + * close inbound connections to the second-last hop of reachability + circuits, if those connections are not using the target ORPort. + + Even though it is unlikely that bridges will have inbound connections to + a non-target ORPort, bridges should still do inbound connection checks, for + consistency. + + These changes are particularly important if a relay is connected to all + other relays in the network, but only over IPv4. (Or in the future, only + over IPv6.) + + We expect that these changes will slightly increase the number of relay + re-connections, but reduce the number of reachability test circuits + required to confirm reachability. + +4.4.3. Accurately Identifying Test Circuits + + The testing relay (or bridge) may confirm that the create cells it is + receiving are from its own test circuits, and that test circuits are + capable of returning create cells to the origin. + + Currently, relays confirm reachability if any create cell is received on + any inbound connection (see section 4.1). Relays do not check that the + circuit is a reachability test circuit, and they do not wait to receive the + return created cell. This behaviour has resulted in difficult to diagnose + bugs on some rare relay configurations. + + We propose these optional changes, to improve the efficiency of IPv4 and + IPv6 ORPort reachability checks: + + Testing relays may: + * check that the create cell is received from a test circuit + (by comparing the received cell to the cells sent by test circuits), + * check that the create cell is received on an inbound connection + (this is existing behaviour), + * if the create cell from a test circuit is received on an outbound + connection, destroy the circuit (rather than returning a created cell), + and + * check that the created cell is returned to the relay on a test circuit + (by comparing the remote address of the final hop on the circuit, to + the local IPv4 and IPv6 ORPort addresses). + + TODO: work out how to efficiently match inbound create cells to test + circuits. + +4.4.4. Allowing More Relay IPv6 Extends + + Currently, clients, relays, and bridges do not include IPv6 ORPorts in their + extend cells. + + In this proposal, we only make relays (and bridges) extend over IPv6 on + the final hop of test circuits. This limited use of IPv6 extends means that + IPv6 connections will still be uncommon. + + We propose these optional changes, to increase the number of IPv6 + connections between relays: + + To increase the number of IPv6 connections, relays that support IPv6 + extends may want to use them for all hops of their own circuits. Relays + make their own circuits for reachability tests, bandwidth tests, and + ongoing preemptive circuits. (Bridges can not change their behaviour, + because they try to imitate clients.) + + We propose a torrc option and consensus parameter SendIPv6CircuitExtends, + which is only supported on relays (and not bridges or clients). This option + makes relays send IPv4 and IPv6 ORPorts in all their extend cells, when + supported by the extending and receiving relay. (See section 3.2.1.) + + TODO: Is there a shorter name, that isn't easily confused with enabling + support for other nodes to perform IPv6 extends via this relay? + + The default value for this option is "auto", which checks the consensus + parameter. If the consensus parameter is not set, it defaults to "0" in + the initial release. + + Once IPv6 extends have had enough testing, we may enable + SendIPv6CircuitExtends on the network. The consensus parameter will be set + to 1. The default will be changed to "1" (if the consensus parameter is not + set). + + We defer any client (and bridge) changes to a separate proposal, to be + implemented when there are more IPv6 relays in the network. But we note + that relay IPv6 extends will provide some cover traffic when clients + eventually use IPv6 extends in their circuits. + + As a useful side effect, increasing the number of IPv6 connections in the + network makes it more likely that an existing connection can be used for + the final hop of a relay IPv6 ORPort reachability check. + +4.5. Alternate Reachability Designs + + We briefly mention some potential reachability designs, and the reasons that + they were not used in this proposal. + +4.5.1. Removing IPv4 ORPorts from Extend Cells + + We avoid designs that only include IPv6 ORPorts in extend cells, and remove + IPv4 ORPorts. + + Only including the IPv6 ORPort would provide slightly more specific + reachability check circuits. However, we don't need IPv6-only designs, + because relays continue trying different reachability circuits until they + confirm reachability. + + IPv6-only designs also make it easy to distinguish relay reachability extend + cells from other extend cells. This distinguisher will become more of an + issue as IPv6 extends become more common in the network (see sections 4.2.2 + and 4.4.4). + + Removing the IPv4 ORPort also provides no fallback, if the IPv6 ORPort is + actually unreachable. IPv6-only failures do not affect reachability checks, + but they will become important in the future, as other circuit types start + using IPv6 extends. + + IPv6-only reachability designs also increase the number of special cases in + the implementation. (And the likelihood of subtle bugs.) + + These designs may be appropriate in future, when there are IPv6-only bridges + or relays. + +5. New Relay Subprotocol Version + + We reserve Tor subprotocol "Relay=3" for: + * relays that support for IPv6 extends, and + * relays and bridges that support IPv6 ORPort reachability checks, + as described in this proposal. + +5.1. Tor Specification Changes + + We propose the following changes to the [Tor Specification], once this + proposal is implemented. + + Adding a new Relay subprotocol version lets testing relays identify other + relays that support IPv6 extends. It also allows us to eventually recommend + or require support for IPv6 extends on all relays (and bridges). + + Append to the Relay version 2 subprotocol specification: + + Relay=2 has limited IPv6 support: + * Clients do not include IPv6 ORPorts in EXTEND2 cells. + * Relays do not not initiate IPv6 connections in response to + EXTEND2 cells containing IPv6 ORPorts. + However, relays accept inbound connections to their IPv6 ORPorts, + and will extend circuits via those connections. + + "3" -- relays support extending over IPv6 connections in response to an + EXTEND2 cell containing an IPv6 ORPort. Relays and bridges perform + IPv6 ORPort reachability checks. Client behaviour does not change. + + This subprotocol is advertised by all relays and bridges, regardless + of their configured ORPorts. But relays without a configured IPv6 + ORPort may refuse to extend over IPv6. And bridges always refuse to + extend over IPv6, because they try to imitate client behaviour. + + A successful IPv6 extend requires: + * Relay subprotocol version 3 (or later) and an IPv6 ORPort on the + extending relay, + * an IPv6 ORPort in the EXTEND2 cell, and + * an IPv6 ORPort on the accepting relay. + (Because different tor instances can have different views of the + network, these checks should be done when the path is selected. + Extending relays should only check local IPv6 information, before + attempting the extend.) + + This subprotocol version is described in proposal 311, and + implemented in Tor 0.4.4.1-alpha. (TODO: check version after code is + merged). + +6. Test Plan + + We provide a quick summary of our testing plans. + +6.1. Test IPv6 ORPort Reachability and Extends + + We propose to test these changes using chutney networks with AssumeReachable + disabled. (Chutney currently enables AssumeReachable by default.) + + We also propose to test these changes on the public network with a small + number of relays and bridges. + + Once these changes are merged, volunteer relay and bridge operators will be + able to test them by: + * compiling from source, + * running nightly builds, or + * running alpha releases. + +6.2. Test Existing Features + + We will modify and test these existing features: + * IPv4 ORPort reachability checks + + We do not plan on modifying these existing features: + * Relay reachability retries + TODO: Do relays re-check their own reachability? How often? + * Relay canonical connections + * "Too many connections" warning logs + But we will test that they continue to function correctly, and fix any bugs + triggered by the modifications in this proposal. + +6.3. Test Legacy Relay Compatibility + + We will also test IPv6 extends from newer relays (which implement this + proposal) to older relays (which do not). Although this proposal does not + create these kinds of circuits, we need to check for bugs and excessive + logs in older tor versions. + +8. Ongoing Monitoring + + To monitor the impact of these changes, relays should collect basic IPv4 + and IPv6 connection and bandwidth statistics (see [Proposal 313]). + + We may also collect separate statistics on connections from: + * clients (and bridges, because they act like clients), and + * other relays (and authorities, because they act like relays). + + We do not propose to collect additional statistics on: + * bridges, + * circuit counts, or + * failure rates. + Collecting statistics like these could impact user privacy. + +References: + +[Onion Service Protocol]: In particular, Version 3 of the Onion Service Protocol supports IPv6: https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt + +[Proposal 306]: One possible design for automatic client IPv4 and IPv6 connections is at https://gitweb.torproject.org/torspec.git/tree/proposals/306-ipv6-happy-eye… (TODO: modify to include bridge changes with client changes) + +[Proposal 312]: https://gitweb.torproject.org/torspec.git/tree/proposals/312-auto-relay-ipv… (TODO) + +[Proposal 313]: https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-sta… (TODO) + +[Relay Search] https://metrics.torproject.org/rs.html + +[Tor Specification]: https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt

1 0

[torspec/master] Prop 311: Add exception for recent tor changes
by teor＠torproject.org 05 Feb '20

05 Feb '20

commit d175e08706863a35e18504368cac71c3370b9d8e Author: teor <teor(a)torproject.org> Date: Tue Jan 28 10:43:45 2020 +1000 Prop 311: Add exception for recent tor changes Some IPv6 behaviour has changed in recent tor versions, as noted in the proposal. Part of 24404. --- proposals/311-relay-ipv6-reachability.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/proposals/311-relay-ipv6-reachability.txt b/proposals/311-relay-ipv6-reachability.txt index 429b867..88204dd 100644 --- a/proposals/311-relay-ipv6-reachability.txt +++ b/proposals/311-relay-ipv6-reachability.txt @@ -61,7 +61,8 @@ Ticket: #24404 in each section should specifically exclude or include these other roles.) When this proposal describes Tor's current behaviour, it covers all - supported Tor versions (0.3.5.7 to 0.4.2.5), as of January 2020. + supported Tor versions (0.3.5.7 to 0.4.2.5), as of January 2020, except + where another version is specifically mentioned. 3. Allow Relay IPv6 Extends

1 0

[torspec/master] Prop 311: Explain Directory Authority behaviour
by teor＠torproject.org 05 Feb '20

05 Feb '20

commit 0348668dec74ca31fba84f1f9038072ef318e0d7 Author: teor <teor(a)torproject.org> Date: Tue Jan 28 10:42:42 2020 +1000 Prop 311: Explain Directory Authority behaviour Where it's different from relay behaviour. Part of ticket 24404. --- proposals/311-relay-ipv6-reachability.txt | 28 +++++++++++++++++++++++----- 1 file changed, 23 insertions(+), 5 deletions(-) diff --git a/proposals/311-relay-ipv6-reachability.txt b/proposals/311-relay-ipv6-reachability.txt index 309fe81..429b867 100644 --- a/proposals/311-relay-ipv6-reachability.txt +++ b/proposals/311-relay-ipv6-reachability.txt @@ -45,7 +45,7 @@ Ticket: #24404 This proposal modifies Tor's behaviour as follows: - Relays: + Relays (including directory authorities): * circuit extension, * OR connections for circuit extension, * reachability testing. @@ -55,6 +55,11 @@ Ticket: #24404 This proposal does not change client behaviour. + Throughout this proposal, "relays" includes directory authorities, except + where they are specifically excluded. "relays" does not include bridges, + except where they are specifically included. (The first mention of "relays" + in each section should specifically exclude or include these other roles.) + When this proposal describes Tor's current behaviour, it covers all supported Tor versions (0.3.5.7 to 0.4.2.5), as of January 2020. @@ -215,12 +220,15 @@ Ticket: #24404 IPv6 reachability failures may result in a relay or bridge refusing to publish its descriptor, if enough existing relays support IPv6 extends. + (Except for directory authorities: they perform reachability checks, and + warn if they fail. But they always publish their descriptors.) 4.1. Current Reachability Implementation Relays and bridges check the reachability of their IPv4 ORPorts and DirPorts, and refuse to publish their descriptor if either reachability - check fails. + check fails. (Directory authorities test their own reachability, but they + only warn, and publish their descriptor regardless of reachability.) IPv4 ORPort reachability checks succeed when any create cell is received on any inbound OR connection. The check succeeds, even if the cell is from an @@ -300,6 +308,9 @@ Ticket: #24404 number of relays in the network that support IPv6 extends, relays should refuse to publish their descriptor. + Directory authorities should perform reachability checks, and warn if they + fail. But directory authorities should always publish their descriptors. + 4.3.1. Refusing to Publish the Descriptor We set a threshold of consensus relays for reliable IPv6 ORPort checks: @@ -320,8 +331,8 @@ Ticket: #24404 higher minimum during testing.) If the current consensus satisfies this threshold, testing relays (and - bridges) that fail IPv6 ORPort reachability checks should refuse to publish - their descriptors. + bridges, but not directory authorities) that fail IPv6 ORPort reachability + checks should refuse to publish their descriptors. To ensure an accurate threshold, testing relays should exclude: * the testing relay itself, and @@ -357,12 +368,19 @@ Ticket: #24404 This option disables IPv6 ORPort reachability checks, so relays publish their descriptors if their IPv4 ORPort reachability checks succeed. + (Unlike AssumeReachable, AssumeIPv6Reachable has no effect on the existing + dirauth IPv6 reachability checks, which connect directly to relay ORPorts.) The default for the torrc option is "auto", which checks the consensus parameter. If the consensus parameter is not set, the default is "0". "AssumeReachable 1" overrides all values of "AssumeIPv6Reachable", - disabling both IPv4 and IPv6 ORPort reachability checks. + disabling both IPv4 and IPv6 ORPort reachability checks. Tor should warn if + AssumeReachable is 1, but AssumeIPv6Reachable is 0. (On directory + authorities, "AssumeReachable 1" also disables dirauth IPv4 and IPv6 + reachability checks, which connect directly to relay ORPorts. + AssumeIPv6Reachable does not disable directory authority to relay IPv6 + checks.) 4.4. Optional Efficiency and Reliability Changes

1 0

[torspec/master] Prop 311: Clarify prop 306 references
by teor＠torproject.org 05 Feb '20

05 Feb '20

commit f67267bc537db1de84675cf4bf8657f310e30291 Author: teor <teor(a)torproject.org> Date: Tue Jan 28 10:57:49 2020 +1000 Prop 311: Clarify prop 306 references Improve the explanations of some of the references to proposal 306: Client Auto IPv6 Connection. And add a section that specifically mentions modifying that proposal. Part of 24404. --- proposals/311-relay-ipv6-reachability.txt | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/proposals/311-relay-ipv6-reachability.txt b/proposals/311-relay-ipv6-reachability.txt index 88204dd..ea2f422 100644 --- a/proposals/311-relay-ipv6-reachability.txt +++ b/proposals/311-relay-ipv6-reachability.txt @@ -172,9 +172,9 @@ Ticket: #24404 If relays try both the IPv4 and IPv6 ORPorts, then the circuit would succeed. For example, relays could try the alternative port after a 250ms - delay, as in [Proposal 306: Client Auto IPv6 Connections]. This design - results in an average circuit delay of up to 125ms per new connection, - rather than failure. + delay, as in [Proposal 306: Client Auto IPv6 Connections]. The design in + this proposal results in an average circuit delay of up to 125ms + (250ms / 2) per new connection, rather than failure. However, partial relay connectivity should be uncommon. And relays keep connections open long-term, so new relay connections are a small proportion @@ -651,6 +651,12 @@ Ticket: #24404 * failure rates. Collecting statistics like these could impact user privacy. +9. Changes to Other Proposals + + [Proposal 306: Client Auto IPv6 Connections] needs to be modified to keep + bridge IPv6 behaviour in sync with client IPv6 behaviour. (See section + 3.3.2.) + References: [Onion Service Protocol]: In particular, Version 3 of the Onion Service Protocol supports IPv6: https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt

1 0

[torspec/master] Prop 311: Use shorter file names for future proposals
by teor＠torproject.org 05 Feb '20

05 Feb '20

commit a65f689482153cd29893ff957a00b1fb3f13b4c4 Author: teor <teor(a)torproject.org> Date: Fri Jan 24 16:28:18 2020 +1000 Prop 311: Use shorter file names for future proposals And use short proposal names in references. Part of 24404. --- proposals/311-relay-ipv6-reachability.txt | 24 +++++++++++++----------- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/proposals/311-relay-ipv6-reachability.txt b/proposals/311-relay-ipv6-reachability.txt index bb7062d..309fe81 100644 --- a/proposals/311-relay-ipv6-reachability.txt +++ b/proposals/311-relay-ipv6-reachability.txt @@ -39,7 +39,7 @@ Ticket: #24404 Implementing IPv6 ORPort reachability checks will provide immediate, direct feedback to operators in the relay or bridge's logs. It also enables future work, such as automatically discovering relay and bridge addresses for IPv6 - ORPorts (see [Proposal 312]). + ORPorts (see [Proposal 312: Relay Auto IPv6 Address]). 2. Scope @@ -101,7 +101,7 @@ Ticket: #24404 Since bridges try to imitate client behaviour, they will not adopt this new behaviour, until clients begin routinely connecting via IPv6. (See - [Proposal 306].) + [Proposal 306: Client Auto IPv6 Connections].) 3.2.1. Making IPv6 ORPort Extend Connections @@ -139,8 +139,8 @@ Ticket: #24404 IPv6 extends to test their own reachability.) We also recommend prioritising client to relay IPv6 connections - (see [Proposal 306]) over relay to relay IPv6 connections. Because client - IPv6 connections have a direct impact on users. + (see [Proposal 306: Client Auto IPv6 Connections]) over relay to relay IPv6 + connections. Because client IPv6 connections have a direct impact on users. 3.3. Alternative Extend Designs @@ -166,8 +166,9 @@ Ticket: #24404 If relays try both the IPv4 and IPv6 ORPorts, then the circuit would succeed. For example, relays could try the alternative port after a 250ms - delay, as in [Proposal 306]. This design results in an average circuit delay - of up to 125ms per new connection, rather than failure. + delay, as in [Proposal 306: Client Auto IPv6 Connections]. This design + results in an average circuit delay of up to 125ms per new connection, + rather than failure. However, partial relay connectivity should be uncommon. And relays keep connections open long-term, so new relay connections are a small proportion @@ -181,7 +182,7 @@ Ticket: #24404 When clients automatically connect to relay IPv4 and IPv6 ORPorts by default, bridges should also adopt this behaviour. (For example, - see [Proposal 306].) + see [Proposal 306: Client Auto IPv6 Connections].) 3.3.3. Rejected Extend Designs @@ -618,7 +619,8 @@ Ticket: #24404 8. Ongoing Monitoring To monitor the impact of these changes, relays should collect basic IPv4 - and IPv6 connection and bandwidth statistics (see [Proposal 313]). + and IPv6 connection and bandwidth statistics (see [Proposal 313: Relay IPv6 + Statistics]). We may also collect separate statistics on connections from: * clients (and bridges, because they act like clients), and @@ -634,11 +636,11 @@ References: [Onion Service Protocol]: In particular, Version 3 of the Onion Service Protocol supports IPv6: https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt -[Proposal 306]: One possible design for automatic client IPv4 and IPv6 connections is at https://gitweb.torproject.org/torspec.git/tree/proposals/306-ipv6-happy-eye… (TODO: modify to include bridge changes with client changes) +[Proposal 306: Client Auto IPv6 Connections]: One possible design for automatic client IPv4 and IPv6 connections is at https://gitweb.torproject.org/torspec.git/tree/proposals/306-ipv6-happy-eye… (TODO: modify to include bridge changes with client changes) -[Proposal 312]: https://gitweb.torproject.org/torspec.git/tree/proposals/312-auto-relay-ipv… (TODO) +[Proposal 312: Relay Auto IPv6 Address]: https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv… (TODO) -[Proposal 313]: https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-sta… (TODO) +[Proposal 313: Relay IPv6 Statistics]: https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-sta… (TODO) [Relay Search] https://metrics.torproject.org/rs.html

1 0

[torspec/master] Prop 311: Include heartbeat logs in monitoring
by teor＠torproject.org 05 Feb '20

05 Feb '20

commit e5aa0b341133ae0998ddc9407b79e755a7993c03 Author: teor <teor(a)torproject.org> Date: Tue Jan 28 10:59:18 2020 +1000 Prop 311: Include heartbeat logs in monitoring Some of the statistics may also be available in relay heartbeat logs. Part of 24404. --- proposals/311-relay-ipv6-reachability.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/proposals/311-relay-ipv6-reachability.txt b/proposals/311-relay-ipv6-reachability.txt index ea2f422..73d4cb0 100644 --- a/proposals/311-relay-ipv6-reachability.txt +++ b/proposals/311-relay-ipv6-reachability.txt @@ -645,6 +645,9 @@ Ticket: #24404 * clients (and bridges, because they act like clients), and * other relays (and authorities, because they act like relays). + Some of these statistics may be included in tor's heartbeat logs, making + them accessible to relay operators. + We do not propose to collect additional statistics on: * bridges, * circuit counts, or

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-commits February 2020