tor-commits February 2020

tor-commits@lists.torproject.org

22 participants
1454 discussions

[torspec/master] Prop 311: Fix a typo in section 5
by teor＠torproject.org 05 Feb '20

05 Feb '20

commit 7f8a655017ccf9e529801ff0c5eecfc6c300ea0d Author: teor <teor(a)torproject.org> Date: Tue Jan 28 11:50:33 2020 +1000 Prop 311: Fix a typo in section 5 Part of 24404. --- proposals/311-relay-ipv6-reachability.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/311-relay-ipv6-reachability.txt b/proposals/311-relay-ipv6-reachability.txt index 73d4cb0..a6b7263 100644 --- a/proposals/311-relay-ipv6-reachability.txt +++ b/proposals/311-relay-ipv6-reachability.txt @@ -569,7 +569,7 @@ Ticket: #24404 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 + * Relays do 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.

1 0

[torspec/master] Prop 311: Make bridge mentions consistent
by teor＠torproject.org 05 Feb '20

05 Feb '20

commit 64745746f4feeacdba73b3bc3a3e418350ca44cd Author: teor <teor(a)torproject.org> Date: Tue Jan 28 12:08:50 2020 +1000 Prop 311: Make bridge mentions consistent Part of 24404. --- proposals/311-relay-ipv6-reachability.txt | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/proposals/311-relay-ipv6-reachability.txt b/proposals/311-relay-ipv6-reachability.txt index a6b7263..a5b5cd3 100644 --- a/proposals/311-relay-ipv6-reachability.txt +++ b/proposals/311-relay-ipv6-reachability.txt @@ -7,14 +7,14 @@ Ticket: #24404 0. Abstract - We propose that Tor relays and bridges should check the reachability of + 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 + 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. @@ -30,15 +30,15 @@ Ticket: #24404 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 + 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. + are a significant source of relay 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 + feedback to operators in the relay's logs. It also enables future work, + such as automatically discovering relay and bridge addresses for IPv6 ORPorts (see [Proposal 312: Relay Auto IPv6 Address]). 2. Scope @@ -74,8 +74,8 @@ Ticket: #24404 3.1. Current IPv6 ORPort Implementation - Currently, all relays and bridges must have an IPv4 ORPort. IPv6 ORPorts - are optional for relays and bridges. + Currently, all relays (and bridges) must have an IPv4 ORPort. IPv6 ORPorts + are optional. Tor supports making direct IPv6 OR connections: * from directory authorities to relay ORPorts,

1 0

[torspec/master] Prop 311: Make capitalisation consistent
by teor＠torproject.org 05 Feb '20

05 Feb '20

commit 3c19e051a61829fac34a7485285017f1f6730a4b Author: teor <teor(a)torproject.org> Date: Tue Jan 28 12:15:15 2020 +1000 Prop 311: Make capitalisation consistent Part of 24404. --- proposals/311-relay-ipv6-reachability.txt | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/proposals/311-relay-ipv6-reachability.txt b/proposals/311-relay-ipv6-reachability.txt index a5b5cd3..a93f286 100644 --- a/proposals/311-relay-ipv6-reachability.txt +++ b/proposals/311-relay-ipv6-reachability.txt @@ -18,10 +18,10 @@ Ticket: #24404 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 + 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 + 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 @@ -235,7 +235,7 @@ Ticket: #24404 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 + 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. @@ -621,10 +621,10 @@ Ticket: #24404 * IPv4 ORPort reachability checks We do not plan on modifying these existing features: - * Relay reachability retries + * relay reachability retries TODO: Do relays re-check their own reachability? How often? - * Relay canonical connections - * "Too many connections" warning logs + * 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.

1 0

[torspec/master] Prop 311: Support seamless upgrades
by teor＠torproject.org 05 Feb '20

05 Feb '20

commit 9966ad3f3f82c551ca26b52e4072447b31e5f413 Author: teor <teor(a)torproject.org> Date: Wed Jan 29 13:18:56 2020 +1000 Prop 311: Support seamless upgrades We want to support these two cases: * upgrade to working IPv6, * stay on IPv4-only, if a guessed IPv6 address isn't reachable. Part of 24404. --- proposals/311-relay-ipv6-reachability.txt | 48 ++++++++++++++++++++----------- 1 file changed, 31 insertions(+), 17 deletions(-) diff --git a/proposals/311-relay-ipv6-reachability.txt b/proposals/311-relay-ipv6-reachability.txt index a93f286..ba7a151 100644 --- a/proposals/311-relay-ipv6-reachability.txt +++ b/proposals/311-relay-ipv6-reachability.txt @@ -8,9 +8,9 @@ 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. + their IPv6 ORPort, before deciding whether to publish 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 @@ -214,15 +214,19 @@ Ticket: #24404 4. Check Relay and Bridge IPv6 ORPort Reachability - We propose that relays and bridges check their own 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 (but not other bridges), and back to their own IPv6 ORPort. - To check IPv6 ORPort reachability, relays and bridges extend circuits via - other relays, and back to their own IPv6 ORPort. + If IPv6 reachability checks fail, relays (and bridges) should refuse to + publish their descriptors, if they believe IPv6 reachability checks are + reliable, and their IPv6 address was explicitly configured. (See + [Proposal 312: Relay Auto IPv6 Address] for the ways relays can guess their + IPv6 addresses.) - 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.) + Directory authorities always publish their descriptors. 4.1. Current Reachability Implementation @@ -300,20 +304,30 @@ Ticket: #24404 * relay IPv6 DirPorts. Therefore, they are also out of scope for this proposal. -4.3. Refuse to Publish Descriptor if IPv6 ORPort is Unreachable +4.3. Refusing 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. + If IPv6 reachability checks fail, relays (and bridges) should refuse to + publish their descriptors, if they believe IPv6 reachability checks are + reliable, and their IPv6 address was explicitly configured. (See + [Proposal 312: Relay Auto IPv6 Address] for the ways relays can guess their + IPv6 addresses.) - Directory authorities should perform reachability checks, and warn if they - fail. But directory authorities should always publish their descriptors. + Directory authorities always publish their descriptors. 4.3.1. Refusing to Publish the Descriptor + If IPv6 reachability checks fail, relays (and bridges) should refuse to + publish their descriptors, if: + * enough existing relays support IPv6 extends, and + * the IPv6 address was explicitly configured by the operator + (rather than guessed using [Proposal 312: Relay Auto IPv6 Address]). + + Directory authorities may perform reachability checks, and warn if those + checks fail. But they always publish their descriptors. + 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, @@ -666,7 +680,7 @@ References: [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: Relay Auto IPv6 Address]: https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv… (TODO) +[Proposal 312: Relay Auto IPv6 Address]: https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv… [Proposal 313: Relay IPv6 Statistics]: https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-sta… (TODO)

1 0

[torspec/master] Prop 311: Add IPv6 ORPort to Extend Conditions
by teor＠torproject.org 05 Feb '20

05 Feb '20

commit b6a75a8a1433eceadeb9bb47cc24851adf26a15b Author: teor <teor(a)torproject.org> Date: Wed Jan 29 22:38:42 2020 +1000 Prop 311: Add IPv6 ORPort to Extend Conditions As suggested by Nick Mathewson. Part of 24404. --- proposals/311-relay-ipv6-reachability.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/proposals/311-relay-ipv6-reachability.txt b/proposals/311-relay-ipv6-reachability.txt index ba7a151..8bb71f4 100644 --- a/proposals/311-relay-ipv6-reachability.txt +++ b/proposals/311-relay-ipv6-reachability.txt @@ -1,6 +1,6 @@ Filename: 311-relay-ipv6-reachability.txt Title: Tor Relay IPv6 Reachability -Author: teor +Author: teor, Nick Mathewson Created: 22-January-2020 Status: Draft Ticket: #24404 @@ -111,7 +111,8 @@ Ticket: #24404 3.2.1. Making IPv6 ORPort Extend Connections - Relays can make a new connection over IPv6 when: + Relays may make a new connection over IPv6 when: + * they are configured with an IPv6 ORPort, * there is no existing authenticated connection to the requested relay, and * the extend cell contains an IPv6 ORPort.

1 0

[torspec/master] Prop 311: Allow Extends to Prefer IPv4 or IPv6
by teor＠torproject.org 05 Feb '20

05 Feb '20

commit 27936d046eb6678c0661b5657d83a6082d66033c Author: teor <teor(a)torproject.org> Date: Wed Jan 29 22:39:46 2020 +1000 Prop 311: Allow Extends to Prefer IPv4 or IPv6 Add an alternate design, suggested by Nick Mathewson. Part of 24404. --- proposals/311-relay-ipv6-reachability.txt | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/proposals/311-relay-ipv6-reachability.txt b/proposals/311-relay-ipv6-reachability.txt index 8bb71f4..f34d379 100644 --- a/proposals/311-relay-ipv6-reachability.txt +++ b/proposals/311-relay-ipv6-reachability.txt @@ -191,7 +191,29 @@ Ticket: #24404 default, bridges should also adopt this behaviour. (For example, see [Proposal 306: Client Auto IPv6 Connections].) -3.3.3. Rejected Extend Designs +3.3.3. Allowing Extends to Prefer IPv4 or IPv6 + + Here is an alternate design, which allows extending clients (or relays doing + reachability tests) to prefer either IPv4 or IPv6: + + Suppose that a relay's extend cell contains the IPv4 address and the + IPv6 address in their _preferred order_. So if the party generating + the extend cell would prefer an IPv4 connection, it puts the IPv4 + addess first; if it would prefer an IPv6 connection, it puts the IPv6 + address first. + + The relay that receives the extend cell could respond in several ways: + * One possibility (similar to section 3.2.1) is to choose at random, + with a higher probability given to the first option. + * One possibility (similar to section 3.3.1) is to try the first, and + then try the second if the first one fails. + + This scheme has some advantage, in that it lets the self-testing relay say + "please try IPv6 if you can" or "please try IPv4 if you can" in a reliable + way, and lets us migrate from the current behavior to the 3.3.1 behavior + down the road. + +3.4. Rejected Extend Designs Some designs may never be suitable for the Tor network.

1 0

[torspec/master] Prop 311: Improve Extra Reachability Checks
by teor＠torproject.org 05 Feb '20

05 Feb '20

commit a3e2f6cd613404ed74ea483dae8234af8a2b7c3e Author: teor <teor(a)torproject.org> Date: Wed Jan 29 22:40:31 2020 +1000 Prop 311: Improve Extra Reachability Checks And add extra logging when tor would have previously found itself reachable, but the new checks fail. As suggested by Nick Mathewson. Part of 24404. --- proposals/311-relay-ipv6-reachability.txt | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/proposals/311-relay-ipv6-reachability.txt b/proposals/311-relay-ipv6-reachability.txt index f34d379..40917f2 100644 --- a/proposals/311-relay-ipv6-reachability.txt +++ b/proposals/311-relay-ipv6-reachability.txt @@ -508,8 +508,15 @@ Ticket: #24404 (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. + Relays can efficiently match inbound create cells to test circuits by + storing a set of their test circuits' extend cells g^X values, and then + check incoming cells create cells against that set. + + If we make these changes, relays should track whether they are + "maybe reachable" (under the current definition of 'reachable') and + "definitely reachable" (based on the new definition). They should log + different messages depending on whether they are "maybe reachable" but these + new tests fail, or whether they are completely unreachable. 4.4.4. Allowing More Relay IPv6 Extends

1 0

[torspec/master] Prop 311: Improve Subprotocol Version
by teor＠torproject.org 05 Feb '20

05 Feb '20

commit 8e85047b651f6cb3317566b4c0b322cad5ea29e4 Author: teor <teor(a)torproject.org> Date: Wed Jan 29 22:43:00 2020 +1000 Prop 311: Improve Subprotocol Version * don't ban useful behaviours, just mention that they might not happen * don't talk about reachability, other tor instances don't care * specify random choice between IPv4 and IPv6 (and add a TODO) As suggested by Nick Mathewson. Part of 24404. --- proposals/311-relay-ipv6-reachability.txt | 39 ++++++++++++++++++++----------- 1 file changed, 25 insertions(+), 14 deletions(-) diff --git a/proposals/311-relay-ipv6-reachability.txt b/proposals/311-relay-ipv6-reachability.txt index 29c4f1a..4b9889b 100644 --- a/proposals/311-relay-ipv6-reachability.txt +++ b/proposals/311-relay-ipv6-reachability.txt @@ -592,10 +592,10 @@ Ticket: #24404 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. + We reserve Tor subprotocol "Relay=3" for tor versions where: + * relays may perform IPv6 extends, and + * bridges may not perform IPv6 extends, + if configured with an IPv6 ORPort, as described in this proposal. 5.1. Tor Specification Changes @@ -604,25 +604,31 @@ Ticket: #24404 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). + or require support for IPv6 extends on all relays. 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 initiate IPv6 connections in response to - EXTEND2 cells containing IPv6 ORPorts. + * Clients may not include IPv6 ORPorts in EXTEND2 cells. + * Relays (and bridges) may not initiate IPv6 connections in + response to EXTEND2 cells containing IPv6 ORPorts, even if they + are configured with an IPv6 ORPort. 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. + EXTEND2 cell containing an IPv6 ORPort. - 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. + Bridges may not extend over IPv6, because they try to imitate client + behaviour. + + Relays without an IPv6 ORPort, and tor instances running in other + roles, may: + * advertise support for "Relay=3", and + * react to consensuses recommending or requiring support for + "Relay=3". + But their other behaviour is similar to tor versions supporting + "Relay=2". A successful IPv6 extend requires: * Relay subprotocol version 3 (or later) and an IPv6 ORPort on the @@ -634,6 +640,11 @@ Ticket: #24404 Extending relays should only check local IPv6 information, before attempting the extend.) + When relays receive an EXTEND2 cell containing both an IPv4 and an + IPv6 ORPort, and there is no existing authenticated connection with + the target relay, the extending relay chooses between IPv4 and IPv6 + at random. (TODO: check final behaviour after code is merged.) + This subprotocol version is described in proposal 311, and implemented in Tor 0.4.4.1-alpha. (TODO: check version after code is merged).

1 0

[torspec/master] Prop 311: Improve RelaySendIPv6Extends option name
by teor＠torproject.org 05 Feb '20

05 Feb '20

commit 5c0aa29f810cf4a58ed2cc859d08b81ba49a1925 Author: teor <teor(a)torproject.org> Date: Wed Jan 29 22:41:59 2020 +1000 Prop 311: Improve RelaySendIPv6Extends option name As suggested by Nick Mathewson. Part of 24404. --- proposals/311-relay-ipv6-reachability.txt | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/proposals/311-relay-ipv6-reachability.txt b/proposals/311-relay-ipv6-reachability.txt index 40917f2..29c4f1a 100644 --- a/proposals/311-relay-ipv6-reachability.txt +++ b/proposals/311-relay-ipv6-reachability.txt @@ -536,14 +536,11 @@ Ticket: #24404 ongoing preemptive circuits. (Bridges can not change their behaviour, because they try to imitate clients.) - We propose a torrc option and consensus parameter SendIPv6CircuitExtends, + We propose a torrc option and consensus parameter RelaySendIPv6Extends, 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.

1 0

[torspec/master] Prop 311: Clarify "may not"
by teor＠torproject.org 05 Feb '20

05 Feb '20

commit 14906a6fd9755733dcea18937eccc1061a8eb923 Author: teor <teor(a)torproject.org> Date: Thu Jan 30 08:23:23 2020 +1000 Prop 311: Clarify "may not" Part of 24404. --- proposals/311-relay-ipv6-reachability.txt | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/proposals/311-relay-ipv6-reachability.txt b/proposals/311-relay-ipv6-reachability.txt index 4b9889b..d2f6b70 100644 --- a/proposals/311-relay-ipv6-reachability.txt +++ b/proposals/311-relay-ipv6-reachability.txt @@ -31,7 +31,7 @@ Ticket: #24404 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 + is unreachable. They might 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 operator support requests. @@ -594,7 +594,7 @@ Ticket: #24404 We reserve Tor subprotocol "Relay=3" for tor versions where: * relays may perform IPv6 extends, and - * bridges may not perform IPv6 extends, + * bridges might not perform IPv6 extends, if configured with an IPv6 ORPort, as described in this proposal. 5.1. Tor Specification Changes @@ -609,8 +609,8 @@ Ticket: #24404 Append to the Relay version 2 subprotocol specification: Relay=2 has limited IPv6 support: - * Clients may not include IPv6 ORPorts in EXTEND2 cells. - * Relays (and bridges) may not initiate IPv6 connections in + * Clients might not include IPv6 ORPorts in EXTEND2 cells. + * Relays (and bridges) might not initiate IPv6 connections in response to EXTEND2 cells containing IPv6 ORPorts, even if they are configured with an IPv6 ORPort. However, relays accept inbound connections to their IPv6 ORPorts, @@ -619,8 +619,8 @@ Ticket: #24404 "3" -- relays support extending over IPv6 connections in response to an EXTEND2 cell containing an IPv6 ORPort. - Bridges may not extend over IPv6, because they try to imitate client - behaviour. + Bridges might not extend over IPv6, because they try to imitate + client behaviour. Relays without an IPv6 ORPort, and tor instances running in other roles, may:

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-commits February 2020