From 1f9f3986d188c9d530fd1edc7294978273796385 Mon Sep 17 00:00:00 2001 From: teor Date: Wed, 5 Feb 2020 10:44:43 +1000 Subject: 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(-) (limited to 'proposals/312-relay-auto-ipv6-addr.txt') 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 -- cgit v1.2.3-54-g00ecf