commit 1f9f3986d188c9d530fd1edc7294978273796385 Author: teor teor@torproject.org Date: Wed Feb 5 10:44:43 2020 +1000

Prop 312: Add Ignore Addresses on Inbound Conns

Add an optional change.

Part of 33073. --- proposals/312-relay-auto-ipv6-addr.txt | 86 +++++++++++++++++++++++----------- 1 file changed, 59 insertions(+), 27 deletions(-)

diff --git a/proposals/312-relay-auto-ipv6-addr.txt b/proposals/312-relay-auto-ipv6-addr.txt index 7724afd..31a5dd7 100644 --- a/proposals/312-relay-auto-ipv6-addr.txt +++ b/proposals/312-relay-auto-ipv6-addr.txt @@ -399,7 +399,7 @@ Ticket: #33073 prefer designs where all relays behave in a similar way, regardless of their internal state.)

- For some more complex directory load-balancing schemes, see section 3.5.3. + For some more complex directory load-balancing schemes, see section 3.5.4.

Tor already ignores private IPv4 addresses in directory headers. We propose to also ignore private IPv6 addresses in directory headers. If all IPv4 and @@ -602,8 +602,7 @@ Ticket: #33073 * authenticated NETINFO cells. See the following sections for more details.

- See also sections 3.5.2 (for preferring addresses from directory - authorities) and 3.5.3 (for load-balancing). + See also sections 3.5.2 to 3.5.4.

3.5.1.1. Authenticated Directory Connections

@@ -760,10 +759,33 @@ Ticket: #33073 IPv6, until clients start to do so. (See [Proposal 306: Client Auto IPv6 Connections].)

- See also sections 3.5.1 (for only using addresses from authenticated - connections) and 3.5.3 (for load-balancing). + See also sections 3.5.1 to 3.5.4.

-3.5.3. Load Balancing +3.5.3. Ignoring Addresses on Inbound Connections + + We propose this optional change, to improve relay (and bridge) address + accuracy and reliability. + + Relays ignore IPv4 and IPv6 address suggestions received on inbound + connections. + + We make this change, because we want to detect the IP addresses of the + relay's outbound routes, rather than the addresses that that other relays + believe they are connecting to for inbound connections. + + If we make this change, relays may need to close some inbound connections, + before doing address detection. If we also make the changes in sections + 3.5.1 and 3.5.2, busy relays could have persistent, inbound OR connections + from all directory authorities. (Currently, there are 9 directory + authorities with IPv4 addresses, and 6 directory authorities with IPv6 + addresses.) + + Directory authorities do not use these address detection methods to + discover their own addresses, for security reasons. + + See also sections 3.5.1 to 3.5.4. + +3.5.4. Load Balancing

We propose some optional changes to improve relay (and bridge) load-balancing across directory authorities. @@ -771,15 +793,20 @@ Ticket: #33073 Directory authorities do not use these address detection methods to discover their own addresses, for security reasons.

-3.5.3.1. Directory Authority Load Balancing + See also sections 3.5.1 to 3.5.3. + +3.5.4.1. Directory Authority Load Balancing

Relays may prefer: * authenticated connections (section 3.5.1).

Relays and bridges may prefer: - * connecting to Directory Authorities (section 3.5.2). + * connecting to Directory Authorities (section 3.5.2), or + * ignoring addresses on inbound connections (section 3.5.3) + (and therefore, they may close some inbound connections, + leading to extra connection re-establishment load).

- Both these changes are optional, so they might not be implemented. + All these changes are optional, so they might not be implemented.

Directory authorities do not use these address detection methods to discover their own addresses, for security reasons. @@ -839,7 +866,7 @@ Ticket: #33073 (Relays may use NETINFO cells for address detection, see section 3.5.1.2.)

- See also section 3.5.3.3, for some general load balancing criteria, that + See also section 3.5.4.3, for some general load balancing criteria, that may help when tuning the address detection interval.

We propose a related change, which is also optional: @@ -850,11 +877,9 @@ Ticket: #33073 ORPort directory requests. (And the most expensive cryptography happens when the ORPort connection is opened.)

- See also sections 3.5.1 (for only using addresses from authenticated - connections) and 3.5.2 (for preferring addresses from directory - authorities). + See also sections 3.5.1 to 3.5.3.

-3.5.3.2. Load Balancing Between IPv4 and IPv6 Directories +3.5.4.2. Load Balancing Between IPv4 and IPv6 Directories

We propose this optional change, to improve the load-balancing between IPv4 and IPv6 directories, when used by relays to find their IPv4 and IPv6 @@ -869,9 +894,11 @@ Ticket: #33073

This change may only be necessary if the following changes result in poor load-balancing, or other relay issues: - * randomly selecting IPv4 or IPv6 directories (see section 3.2.5), or + * randomly selecting IPv4 or IPv6 directories (see section 3.2.5), * preferring addresses from directory authorities, via an authenticated - connection (see sections 3.5.1 and 3.5.2). + connection (see sections 3.5.1 and 3.5.2), or + * ignoring addresses on inbound connections, and therefore closing and + re-opening some connections (see section 3.5.3).

We propose that the RelayMaxIntervalWithoutAddressDetection option is counted separately for IPv4 and IPv6 (see the previous section for details). @@ -887,14 +914,16 @@ Ticket: #33073 If both intervals have elapsed at the same time, the relay should choose between IPv4 and IPv6 at random.

- See also section 3.5.3.3, for some general load balancing criteria, that + See also section 3.5.4.3, for some general load balancing criteria, that may help when tuning the address detection interval.

Alternately, we could wait until [Proposal 306: Client Auto IPv6 Connections] is implemented, and use the directory fetch design from that proposal.

-3.5.3.3. General Load Balancing Criteria + See also sections 3.5.1 to 3.5.3. + +3.5.4.3. General Load Balancing Criteria

We propose the following criteria for choosing load-balancing intervals:

@@ -909,6 +938,7 @@ Ticket: #33073 tor cryptography, so it is more expensive for authorities than a DirPort fetch (and it can not be cached by a HTTP cache) (see section 3.5.1), + * closing and re-opening some OR connections (see section 3.5.3), * minimising wasted CPU (and bandwidth) for IPv6 connection attempts on IPv4-only relays, and * other potential changes to relay directory fetches (see @@ -932,7 +962,9 @@ Ticket: #33073 at random (see section 3.2.5 for more detail). But if this change causes issues on IPv4-only relays, we may have to try IPv6 less often.

-3.5.4. Detailed Address Resolution Logs + See also sections 3.5.1 to 3.5.3. + +3.5.5. Detailed Address Resolution Logs

We propose this optional change, to help diagnose relay address resolution issues. @@ -948,7 +980,7 @@ Ticket: #33073 The logs should tell operators to set the Address torrc option for IPv4 and IPv6 (if available).

-3.5.5. Add IPv6 Support to is_local_addr() +3.5.6. Add IPv6 Support to is_local_addr()

We propose this optional change, to improve the accuracy of IPv6 address detection from directory documents. @@ -974,7 +1006,7 @@ Ticket: #33073 network block). See also the next section, which uses IPv6 /64 for sybils.

-3.5.6. Add IPv6 Support to AuthDirMaxServersPerAddr +3.5.7. Add IPv6 Support to AuthDirMaxServersPerAddr

We propose this optional change, to improve the health of the network, by rejecting too many relays on the same IPv6 address. @@ -1017,7 +1049,7 @@ Ticket: #33073 Since these relay exclusions happen at voting time, they do not require a new consensus method.

-3.5.7. Use a Local Interface Address on the Default Route +3.5.8. Use a Local Interface Address on the Default Route

We propose this optional change, to improve the accuracy of local interface IPv4 and IPv6 address detection (see section 3.2.3), on relays @@ -1038,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.8. Add IPv6 Support Using gethostbyname2() +3.5.9. Add IPv6 Support Using gethostbyname2()

We propose these optional changes, to add IPv6 support to hostname resolution on older OSes. These changes affect: @@ -1081,7 +1113,7 @@ Ticket: #33073 if all other methods fail. Or operators can set the Address torrc option to an IPv4 or IPv6 literal.

-3.5.9. Change Relay OutboundBindAddress Defaults +3.5.10. Change Relay OutboundBindAddress Defaults

We propose this optional change, to improve the reliability of IP address-based filters in tor. These filters typically affect relays and @@ -1107,7 +1139,7 @@ Ticket: #33073 the outbound address comes from the chosen route for each TCP connection or UDP packet (usually the default route).

-3.5.10. IPv6 Address Privacy Extensions +3.5.11. IPv6 Address Privacy Extensions

We propose this optional change, to improve the reliability of relays (and bridges) that use IPv6 address privacy extensions (see section 3.5 of @@ -1161,7 +1193,7 @@ Ticket: #33073 IPv6 addresses change. (See [Ticket 28725: Reset relay bandwidths when their IPv6 address changes].)

-3.5.11. Quick Extends After Relay Restarts +3.5.12. Quick Extends After Relay Restarts

We propose this optional change, to reduce client circuit failures, after a relay restarts. @@ -1215,7 +1247,7 @@ Ticket: #33073 should be able to perform extends (and serve cached directory documents) shortly after startup.

-3.5.12. Using Authority Addresses for Socket-Based Address Detection +3.5.13. Using Authority Addresses for Socket-Based Address Detection

We propose this optional change, to avoid issues with firewalls during relay (and bridge) address detection. (And to reduce user confusion about