commit 043ac7d7aa9e0b48ef7f80e8cfb1b6b2f5ce2f39 Author: teor teor@torproject.org Date: Tue Feb 4 19:19:12 2020 +1000
Prop 312: Rewrite authenticated address detection
All these changes are optional in the proposal: * Add the NETINFO cell address detection method (as suggested by Nick Mathewson) * Defer decisions about ignoring some addresses, or using those addresses as the lowest priority method * Simplify the load-balancing design
Part of 33073. --- proposals/312-relay-auto-ipv6-addr.txt | 359 ++++++++++++++++++++++++--------- 1 file changed, 263 insertions(+), 96 deletions(-)
diff --git a/proposals/312-relay-auto-ipv6-addr.txt b/proposals/312-relay-auto-ipv6-addr.txt index c167329..a6d89e4 100644 --- a/proposals/312-relay-auto-ipv6-addr.txt +++ b/proposals/312-relay-auto-ipv6-addr.txt @@ -519,6 +519,7 @@ Ticket: #33073 (also minimise consensus size) * store a list of previous addresses in the state file, and use the most recently used address that's currently available. + Operators who want to avoid address flipping should set the Address option in the torrc. Operators who want to minimise the size of the consensus should use all-zero IPv6 host identifiers. @@ -531,13 +532,46 @@ Ticket: #33073 Some of these changes may be more appropriate in future releases, or along with other proposed features.
-3.5.1. Only Use Authenticated Directory Header IPv4 and IPv6 Addresses + Some of these changes make tor ignore some potential IP addresses. + + Ignoring addresses risks relays having no available ORPort addresses, and + refusing to publish their descriptor. So before we ignore any addresses, we + should make sure that: + * tor's other address detection methods are robust and reliable, and + * we would prefer relays to shut down, rather than use the ignored + address. + + As a less severe alternative, low-quality methods can be put last in the + address resolution order. (See section 3.2.) + + If relays prefer addresses from particular sources (for example: ORPorts), + they should try these sources regularly, so that their addresses do not + become too old. + + If relays ignore addresses from some sources (for example: DirPorts), they + must regularly try other sources (for example: ORPorts). + +3.5.1. Using Authenticated IPv4 and IPv6 Addresses
We propose this optional change, to improve relay (and bridge) address accuracy and reliability.
- Relays should only use authenticated directory fetches to discover their - own IPv4 and IPv6 addresses. + Relays should try to use authenticated connections to discover their own + IPv4 and IPv6 addresses. + + Tor supports two kinds of authenticated address information: + * authenticated directory connections, and + * 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). + +3.5.1.1. Authenticated Directory Connections + + We propose this optional change, to improve relay address accuracy and + reliability. (Bridges are not affected, because they already use + authenticated directory connections, just like clients.)
Tor supports authenticated, encrypted directory fetches using BEGINDIR over ORPorts (see the [Tor Specification] for details). @@ -548,82 +582,216 @@ Ticket: #33073 authenticated directory fetches.)
Using authenticated directory headers for relay addresses: - * avoids caches (or other machines) mangling X-Your-Address-Is headers in - transit, and - * avoids attacks where directories are deliberately given an incorrect IP - address. + * provides authenticated address information, + * reduces the number of attackers that can deliberately give a relay an + incorrect IP address, and + * avoids caches (or other machines) accidentally mangling, deleting, or + repeating X-Your-Address-Is headers.
- To make this change, we need to modify two different parts of tor: + To make this change, we need to modify tor's directory connection code: * when making directory requests, relays should fetch some directory - documents using BEGINDIR over ORPorts, and - * when using the X-Your-Address-Is HTTP header to guess their own IPv4 or - IPv6 addresses, relays ignore directory documents that were not fetched - using BEGINDIR over ORPorts. + documents using BEGINDIR over ORPorts.
- See also sections 3.5.2 (for preferring addresses from directory - authorities) and 3.5.3 (for load-balancing). + Once tor regularly gets authenticated X-Your-Address-Is headers, relays can + change how they handle unauthenticated addresses. When they receive an + unauthenticated address suggestion, relays can: + * ignore the address, or + * use the address as the lowest priority address method. + See section 3.5 for some factors to consider when making this design + decision.
-3.5.2. Preferring IPv4 and IPv6 Addresses from Directory Authorities + For anonymity reasons, bridges are unable to fetch directory documents over + IPv6, until clients start to do so. (See + [Proposal 306: Client Auto IPv6 Connections].) + + Bridges currently use authenticated IPv4 connections for all their + directory fetches, to imitate default client behaviour. + + We describe a related change, which is also optional: + + We can increase the number of ORPort directory fetches: + * if tor has an existing ORPort connection to a relay that it has selected + for a directory fetch, it should use an ORPort fetch, rather than + opening an additional DirPort connection. + + Using an existing ORPort connection: + * saves one DirPort connection and file descriptor, + * but slightly increases the cryptographic processing done by the relay, + and by the directory server it is connecting to. + However, the most expensive cryptographic operations have already happened, + when the ORPort connection was opened. + + This change does not increase the number of NETINFO cells, because it + re-uses existing OR connections. See the next section for more details. + +3.5.1.2. Authenticated NETINFO Cells
We propose this optional change, to improve relay (and bridge) address + accuracy and reliability. (Bridge IPv6 addresses are not affected, because + bridges only make OR connections over IPv4, to imitate default client + behaviour.) + + Tor supports authenticated IPv4 and IPv6 address information, using the + NETINFO cells exchanged at the beginning of each ORPort connection (see the + [Tor Specification] for details). + + Relays do not currently use any address information from NETINFO cells. + + Using authenticated NETINFO cells for relay addresses: + * provides authenticated address information, + * reduces the number of attackers that can deliberately give a relay an + incorrect IP address, and + * does not require a directory fetch (NETINFO cells are sent during + connection setup). + + To make this change, we need to modify tor's cell processing: + * when processing NETINFO cells, tor should store the OTHERADDR field, + like it currently does for X-Your-Address-Is HTTP headers, and + * IPv4 and IPv6 addresses should be stored separately. + See the previous section, and section 3.2.5 for more details about the + X-Your-Address-Is HTTP header. + + Once tor uses NETINFO cell addresses, relays can change how they handle + unauthenticated X-Your-Address-Is headers. When they receive an + unauthenticated address suggestion, relays can: + * ignore the address, or + * use the address as the lowest priority address method. + See section 3.5 for some factors to consider when making this design + decision. + + We propose that tor continues to use the X-Your-Address-Is header, and adds + support for addresses in NETINFO cells. X-Your-Address-Is headers are sent + once per directory document fetch, but NETINFO cells are only sent once per + OR connection. + + If a relay: + * only gets addresses from NETINFO cells from authorities, and + * has an existing, long-term connection to every authority, + then it may struggle to detect address changes. + + Once all supported tor versions use NETINFO cells for address detection, we + should review this design decision. If we are confident that almost all + relays will be forced to make new connections when their address changes, + then tor may be able to stop using X-Your-Address-Is HTTP headers. + + Bridges only make OR connections, and those OR connections are only over + IPv4, to imitate default client behaviour. + + For anonymity reasons, bridges are unable to make regular connections over + IPv4 and IPv6, until clients start to do so. (See + [Proposal 306: Client Auto IPv6 Connections].) + + As an alternative design, if tor's addresses are stale, it could close some + of its open directory authority connections. (Similar to section 4.4.2 + in [Proposal 311: Relay IPv6 Reachability], where relays close existing OR + connections, before testing their own reachability.) However, this design is + more complicated, because it involves tracking address age, as well as the + address itself. + +3.5.2. Preferring IPv4 and IPv6 Addresses from Directory Authorities + + We propose this optional change, to improve relay (but not bridge) address accuracy and reliability.
- Relays store the latest IPv4 and IPv6 addresses received from: - * a directory authority, and - * a directory mirror, - and prefer the address from a directory authority, as long as it is not - too old. - - Relays should also store a timestamp for each address, and ignore addresses - where: - * the timestamp is too old, or - * the timestamp for the preferred address (from a directory authority) - is much older than the timestamp for the other address (from a directory - mirror). - - Relays should try directory authorities often enough, that their addresses - usually do not become too old. (And if the addresses do become too old, - relays should try directory authorities more often.) - - As an alternative, relays could ignore addresses from other relays: - * when using the X-Your-Address-Is HTTP header to guess their own IPv4 or - IPv6 addresses, relays ignore directory documents that were not fetched - from directory authorities. - However, this implementation is not ideal, because it is better for a relay - to use an address from a directory mirror, than have no address at all. + Relays prefer IPv4 and IPv6 address suggestions received from Directory + Authorities. + + When they receive an address suggestion from a directory mirror, relays can: + * ignore the address, or + * use the address as the lowest priority address method. + See section 3.5 for some factors to consider when making this design + decision. + + Bridges only make OR connections, and those OR connections are only over + IPv4, to imitate default client behaviour. + + For anonymity reasons, bridges are unable to make regular connections over + 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).
3.5.3. Load Balancing
- We propose some optional changes to improve load-balancing. + We propose some optional changes to improve relay (and bridge) + load-balancing across directory authorities.
3.5.3.1. Directory Authority Load Balancing
- Ideally, we would like all relays (and bridges) to do frequent directory - fetches: + Relays may prefer: + * authenticated connections (section 3.5.1). + + Relays and bridges may prefer: + * connecting to Directory Authorities (section 3.5.2). + + Both these changes are optional, so they might not be implemented. + + If both changes are implemented, we would like all relays (and bridges) to + do frequent directory fetches: * using BEGINDIR over ORPorts, * to directory authorities. - However, this change may be unsustainable during high network load - (see [Ticket 33018: Dir auths using an unsustainable 400+ mbit/s]). + However, this extra load from relays may be unsustainable during high + network load (see + [Ticket 33018: Dir auths using an unsustainable 400+ mbit/s]). + + For anonymity reasons, bridges should avoid connecting to directory + authorities too frequently, to imitate default client behaviour.
Therefore, we propose a simple load-balancing scheme between address resolution and non-address resolution requests: - * when relays do not know their own IP addresses, they should make as many - directory authority ORPort directory fetches as is sustainable, and - * when relays know their own IP addresses, they should make an occasional - directory authority ORPort directory fetch, to learn if their address - has changed. + * when relays first start up, they should make two directory authority + ORPort fetch attempts, one on IPv4, and one on IPv6, + * relays should also make occasional directory authority ORPort directory + fetch attempts, on IPv4 and IPv6, to learn if their addresses have + changed.
- We use the load-balancing criteria in section 3.5.3.3, to select the ratio - between: - * ORPort connections to directory authorities, and - * ORPort or DirPort connections to directory mirrors. + We propose a new torrc option and consensus parameter:
- It should be possible for relays to choose between ORPort and DirPort - connections to directory mirrors at random: they typically have enough spare - CPU and bandwidth. + RelayMaxIntervalWithoutAddressDetectionRequest N seconds|minutes|hours + + Relays make most of their directory requests via directory mirror DirPorts, + to reduce the load on directory authorities. + + When this amount of time has passed since a relay last connected to a + directory authority ORPort, the relay makes its next directory request via + a directory authority ORPort. (Default: 15 minutes) + + The final name and description for this option will depend on which optional + changes are actually implemented in tor. In particular, this option should + only consider requests that tor may use to discover its IP addresses. + For example: + * if tor uses NETINFO cells for addresses (section 3.5.1.2), then all + OR connections to an authority should be considered, + * if tor does not use NETINFO cells for addresses, and only uses + X-Your-Address-Is headers, then only directory fetches from authorities + should be considered. + + We set the default value of this option to 15 minutes, because: + * tor's reachability tests fail if the ORPort is unreachable after 20 + minutes. So we want to do at least two address detection requests in + the first 20 minutes; + * the minimum consensus period is 30 minutes, and we want to do at least + one address detection per consensus period. (Consensuses are usually + created every hour. But if there is no fresh consensus, directory + authorities will try to create a consensus every 30 minutes); and + * the default value for TestingAuthDirTimeToLearnReachability is 30 + minutes. So directory authorities will make reachability test OR + connections to each relay, at least every 30 minutes. Therefore, relays + will see NETINFO cells from directory authorities about this often. + (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 + may help when tuning the address detection interval. + + We propose a related change, which is also optional: + + If relays use address suggestions from directory mirrors, they may choose + between ORPort and DirPort connections to directory mirrors at random. + Directory mirrors typically have enough spare CPU and bandwidth to handle + 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 @@ -633,36 +801,34 @@ Ticket: #33073
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 - addresses (see section 3.2.6). + addresses (see section 3.2.5). + + For anonymity reasons, bridges are unable to make regular connections over + IPv6, until clients start to do so. (See + [Proposal 306: Client Auto IPv6 Connections].)
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.6), or - * preferring directory header addresses, from directory authorities, - via an authenticated connection (see sections 3.5.1 and 3.5.2). + * randomly selecting IPv4 or IPv6 directories (see section 3.2.5), or + * preferring addresses from directory authorities, via an authenticated + connection (see sections 3.5.1 and 3.5.2).
- We propose a new torrc option and consensus parameter: - MaxNumIPv4DirectoryAttempts. This option limits the number of IPv4 directory - requests, before the relay makes an IPv6 directory request. It should only - apply to attempts that are expected to provide a usable IPv4 or IPv6 - address in their directory header. (Based on sections 3.2.6, 3.5.1, and - 3.5.2.) - - The design is similar to MaxNumIPv4BootstrapAttempts in - [Proposal 306: Client Auto IPv6 Connections]. - - Here is a quick sketch of the design: - * when MaxNumIPv4DirectoryAttempts is reached, select an IPv6-capable - directory, and make an IPv6 connection attempt, - * use a directory authority, or an ORPort, if required (see sections - 3.5.1 and 3.5.2), - * use a default value between 2 and 4: - * the ideal value for load-balancing is >= 2 - (because 6/9 directory authorities are already on IPv6) - * the ideal value for minimising failures is ~4 - (because relays won't waste too much CPU or bandwidth) - * choose the default value based on the load-balancing criteria in section - 3.5.3.3. + We propose that the RelayMaxIntervalWithoutAddressDetection option is + counted separately for IPv4 and IPv6 (see the previous section for details). + + For example: + * if 30 minutes has elapsed since the last IPv4 address detection request, + then the next directory request should be an IPv4 address detection + request, and + * if 30 minutes has elapsed since the last IPv6 address detection request, + then the next directory request should be an IPv6 address detection + request. + + 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 + may help when tuning the address detection interval.
Alternately, we could wait until [Proposal 306: Client Auto IPv6 Connections] is implemented, and use the @@ -670,20 +836,15 @@ Ticket: #33073
3.5.3.3. General Load Balancing Criteria
- We propose the following criteria for choosing load-balancing ratios: + We propose the following criteria for choosing load-balancing intervals:
- The selected ratios should be chosen based on the following factors: - * the current number of directory fetches that a relay makes: - * when bootstrapping with an empty cache directory, and - * in a steady state (per hour, or per new consensus), - (these numbers aren't currently collected by tor, so we may need to - write some extra code to include them in the heartbeat logs), + The selected interval should be chosen based on the following factors: * relays need to discover their IPv4 and IPv6 addresses to publish their descriptors, * it only takes one successful directory fetch from one authority for a relay to discover its IP address (see section 3.5.2), - * relays will fall back to addresses from directory mirrors, if directory - authorities are unavailable (see section 3.5.2), + * if relays fall back to addresses discovered from directory mirrors, + when directory authorities are unavailable (see section 3.5.2), * BEGINDIR over ORPort requires and TLS connection, and some additional tor cryptography, so it is more expensive for authorities than a DirPort fetch (and it can not be cached by a HTTP cache) @@ -693,14 +854,20 @@ Ticket: #33073 * other potential changes to relay directory fetches (see [Ticket 33018: Dir auths using an unsustainable 400+ mbit/s])
- The selected ratios should allow almost all relays to update both their IPv4 - and IPv6 addresses: - * at least twice when they bootstrap (to allow for fetch failures), - * at least once per directory fetch (or per hour), and - * from a directory authority (if available). + The selected interval should allow almost all relays to update both their + IPv4 and IPv6 addresses: + * at least twice when they bootstrap and test reachability (to allow for + fetch failures), + * at least once per consensus interval (that is, every 30 minutes), and + * from a directory authority (if required). + + For anonymity reasons, bridges are unable to make regular connections over + IPv6, until clients start to do so. (See + [Proposal 306: Client Auto IPv6 Connections].)
In this proposal, relays choose between IPv4 and IPv6 directory fetches - at random (see section 3.2.6 for more detail). + 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