February 2020 - tor-commits - lists.torproject.org

[torspec/master] Prop 312: Add an early extends section
by teor＠torproject.org 05 Feb '20

05 Feb '20

commit 66d08ba3580cd0f900e9d4a8d1e52a89d918fdab Author: teor <teor(a)torproject.org> Date: Mon Feb 3 22:00:47 2020 +1000 Prop 312: Add an early extends section Add an optional change to support clients extending as soon as possible, after a relay restarts. Part of 33073. --- proposals/312-relay-auto-ipv6-addr.txt | 50 ++++++++++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) diff --git a/proposals/312-relay-auto-ipv6-addr.txt b/proposals/312-relay-auto-ipv6-addr.txt index 47a7d6d..da75812 100644 --- a/proposals/312-relay-auto-ipv6-addr.txt +++ b/proposals/312-relay-auto-ipv6-addr.txt @@ -870,6 +870,56 @@ Ticket: #33073 IPv6 addresses change. (See [Ticket 28725: Reset relay bandwidths when their IPv6 address changes].) +3.5.11. Quick Extends After Relay Restarts + + We propose this optional change, to reduce client circuit failures, after a + relay restarts. + + We propose that relays (and bridges) should open their ORPorts, and support + client extends, as soon as possible after they start up. (Clients may + already have the relay's addresses from a previous consensus.) + + Automatically enabling an IPv6 ORPort creates a race condition with IPv6 + extends (see section 3.2.8 of this proposal, and + [Proposal 311: Relay IPv6 Reachability]). + + This race condition has the most impact when: + 1. a relay has outbound IPv6 connectivity, + 2. the relay detects a publicly routable IPv6 address, + 3. the relay opens an IPv6 ORPort, + 4. but the IPv6 ORPort is not reachable. + + Between steps 3 and 4, the relay could successfully extend over IPv6, even + though its IPv6 ORPort is unreachable. However, we expect this case to be + rare. + + A far more common case is that a working relay has just restarted, and + clients still have its addresses, therefore they continue to try to extend + through it. If the relay refused to extend, all these clients would have to + retry their circuits. + + To support this case, tor relays should open IPv4 and IPv6 ORPorts, and + perform extends, as soon as they can after startup. Relays can extend to + other relays, as soon as they have validated the directory documents + containing other relays' public keys. + + In particular, relays which automatically detect their IPv6 address, should + support IPv6 extends as soon as they detect an IPv6 address. (Relays may + also attempt to bind to all IPv6 addresses on all interfaces. If that bind + is successful, they may choose to extend over IPv6, even before they know + their own IPv6 address.) + + Relays should not wait for reachable IPv4 or IPv6 ORPorts before they start + performing client extends. + + DirPort requests are less critical, because relays and clients will retry + directory fetches using multiple mirrors. However, DirPorts may also open + as early as possible, for consistency. (And for simpler code.) + + Tor's existing code handles this use case, so the code changes required to + support IPv6 may be quite small. But we should still test this use case for + clients connecting over IPv4 and IPv6, and extending over IPv4 and IPv6. + 4. Directory Protocol Specification Changes We propose explicitly supporting IPv6 X-Your-Address-Is HTTP headers in the

1 0

[torspec/master] Prop 312: Fix a heading
by teor＠torproject.org 05 Feb '20

05 Feb '20

commit 77da452bd6eaf3d7326e1b61e469a0341a1b5375 Author: teor <teor(a)torproject.org> Date: Mon Feb 3 19:03:53 2020 +1000 Prop 312: Fix a heading Part of 33073. --- proposals/312-relay-auto-ipv6-addr.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/312-relay-auto-ipv6-addr.txt b/proposals/312-relay-auto-ipv6-addr.txt index e90f465..4842d1b 100644 --- a/proposals/312-relay-auto-ipv6-addr.txt +++ b/proposals/312-relay-auto-ipv6-addr.txt @@ -890,7 +890,7 @@ Ticket: #33073 We provide a quick summary of our testing plans. -5.1. Test Find Relay IPv6 Addresses +5.1. Testing Relay IPv6 Addresses Discovery We propose to test these changes using chutney networks. However, chutney creates a limited number of configurations, so we also need to test these

1 0

[torspec/master] Prop 312: Explain public IPv6 addresses
by teor＠torproject.org 05 Feb '20

05 Feb '20

commit 8a9ea6f2245ce3c60938bdb74a1a862b3d403fb4 Author: teor <teor(a)torproject.org> Date: Tue Feb 4 11:35:58 2020 +1000 Prop 312: Explain public IPv6 addresses Since relays put the discovered IPv6 address in their descriptor, it needs to be publicly routable. (If the relay is on the public network.) As suggested by Nick Mathewson. Also fix inconsistent use of directory authority, directory server, and directory mirror. Part of 33073. --- proposals/312-relay-auto-ipv6-addr.txt | 40 ++++++++++++++++++++++++---------- 1 file changed, 29 insertions(+), 11 deletions(-) diff --git a/proposals/312-relay-auto-ipv6-addr.txt b/proposals/312-relay-auto-ipv6-addr.txt index da75812..05ff9de 100644 --- a/proposals/312-relay-auto-ipv6-addr.txt +++ b/proposals/312-relay-auto-ipv6-addr.txt @@ -8,10 +8,17 @@ Ticket: #33073 0. Abstract We propose that Tor relays (and bridges) should automatically find their - IPv6 address, and use it to publish an IPv6 ORPort. For some relays to find - their IPv6 address, they may need to fetch some directory documents from - directory authorities over IPv6. (For anonymity reasons, bridges are unable - to fetch directory documents over IPv6, until clients start to do so.) + IPv6 address. + + Like tor's existing IPv4 address auto-detection, the chosen IPv6 address + will be published as an IPv6 ORPort in the relay's descriptor. Clients, + relays, and authorities connect to relay descriptor IP addresses. + Therefore, IP addresses in descriptors need to be publicly routable. (If + the relay is running on the public tor network.) + + To discover their IPv6 address, some relays may fetch directory documents + over IPv6. (For anonymity reasons, bridges are unable to fetch directory + documents over IPv6, until clients start to do so.) 1. Introduction @@ -66,13 +73,24 @@ Ticket: #33073 3. Finding Relay IPv6 Addresses - We propose that tor relays (and bridges) automatically find their IPv6 - address, and use it to publish an IPv6 ORPort. + We propose that Tor relays (and bridges) should automatically find their + IPv6 address. + + Like tor's existing IPv4 address auto-detection, the chosen IPv6 address + will be published as an IPv6 ORPort in the relay's descriptor. Clients, + relays, and authorities connect to relay descriptor IP addresses. + Therefore, IP addresses in descriptors need to be publicly routable. (If + the relay is running on the public tor network.) + + Relays should ignore any addresses that are reserved for private networks, + and check the reachability of addresses that appear to be public (see + [Proposal 311: Relay IPv6 Reachability]). Relays should only publish IP + addresses in their descriptor, if they are public and reachable. (If the + relay is not running on the public tor network, it may use any IP address.) - For some relays to find their IPv6 address, they may need to fetch some - directory documents from directory authorities over IPv6. (For anonymity - reasons, bridges are unable to fetch directory documents over IPv6, until - clients start to do so.) + To discover their IPv6 address, some relays may fetch directory documents + over IPv6. (For anonymity reasons, bridges are unable to fetch directory + documents over IPv6, until clients start to do so.) 3.1. Current Relay IPv4 Address Implementation @@ -315,7 +333,7 @@ Ticket: #33073 section 3.4.1 and [Proposal 306: Client Auto IPv6 Connections].) We propose that directory authorities should ignore addresses in directory - headers. Allowing other authorities (or relays?) to change a directory + headers. Allowing other authorities (or relays) to change a directory authority's published IP address may lead to security issues. Instead, if interface and hostname lookups fail, tor should stop address resolution, and return a permanent error. (And issue a log to the operator, see below.)

1 0

[torspec/master] Prop 312: Explain how to choose addresses
by teor＠torproject.org 05 Feb '20

05 Feb '20

commit f12ddad6bffd118c4759304d69f879e9829a52ca Author: teor <teor(a)torproject.org> Date: Tue Feb 4 12:18:56 2020 +1000 Prop 312: Explain how to choose addresses Explain how we choose between multiple addresses, in a list, and over time. Part of 33073. --- proposals/312-relay-auto-ipv6-addr.txt | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/proposals/312-relay-auto-ipv6-addr.txt b/proposals/312-relay-auto-ipv6-addr.txt index ecea79b..752a0be 100644 --- a/proposals/312-relay-auto-ipv6-addr.txt +++ b/proposals/312-relay-auto-ipv6-addr.txt @@ -114,8 +114,9 @@ Ticket: #33073 If there are multiple valid addresses, tor chooses: * the first address returned by the resolver, - * the first address returned by the local interface API, or - * the latest address returned by a directory server. + * the first address returned by the local interface API, and + * the latest address(es) returned by a directory server, DNS, or the + local interface API. 3.2. Finding Relay IPv6 Addresses @@ -157,8 +158,10 @@ Ticket: #33073 While making these changes, we want to preserve tor's existing behaviour: * resolve Address using the local resolver, if needed, * ignore private addresses on public tor networks, and - * when there are multiple valid addresses, choose the first or latest - address, as appropriate. + * when there are multiple valid addresses: + * if a list of addresses is received, choose the first address, and + * if different addresses are received over time, choose the most recent + address. 3.2.1. Make the Address torrc Option Support IPv6

1 0

[torspec/master] Prop 312: Explain why untrusted addresses are bad
by teor＠torproject.org 05 Feb '20

05 Feb '20

commit 7a55bf166248a5ff210691cb219df1ec8e40ea29 Author: teor <teor(a)torproject.org> Date: Tue Feb 4 12:10:18 2020 +1000 Prop 312: Explain why untrusted addresses are bad And describe a potential attack that gives a relay the wrong address, then monitors its traffic. As suggested by Nick Mathewson. Part of 33073. --- proposals/312-relay-auto-ipv6-addr.txt | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/proposals/312-relay-auto-ipv6-addr.txt b/proposals/312-relay-auto-ipv6-addr.txt index 05ff9de..ecea79b 100644 --- a/proposals/312-relay-auto-ipv6-addr.txt +++ b/proposals/312-relay-auto-ipv6-addr.txt @@ -1,6 +1,6 @@ Filename: 312-relay-auto-ipv6-addr.txt Title: Tor Relays Automatically Find Their IPv6 Address -Author: teor +Author: teor, Nick Mathewson Created: 28-January-2020 Status: Draft Ticket: #33073 @@ -131,8 +131,18 @@ Ticket: #33073 * Reliable is better than Unreliable. Within these constraints, we try to find the simplest working design. - Therefore, we propose that tor tries to find relay IPv4 and IPv6 addresses - in this order: + If a relay is given the wrong address by an attacker, the attacker can + direct all inbound relay traffic to their own address. They can't decrypt + the traffic without the relay's private keys, but they can monitor traffic + patterns. + + Therefore, we only use untrusted address discovery methods, if every other + method has failed. Any method that uses DNS is potentially untrusted, + because DNS is often a remote, unauthenticated service. And addresses + provided by other directory servers are also untrusted. + + Based on these principles, we propose that tor tries to find relay IPv4 and + IPv6 addresses in this order: 1. the Address torrc option 2. the advertised ORPort address 3. the advertised DirPort address (IPv4 only; relays, not bridges)

1 0

[torspec/master] Prop 312: Improve interface address method
by teor＠torproject.org 05 Feb '20

05 Feb '20

commit fd4716f1ce976c41662046f1022c2546d993c8a2 Author: teor <teor(a)torproject.org> Date: Tue Feb 4 12:46:47 2020 +1000 Prop 312: Improve interface address method Explain why some relays may not have any publicly routable interface addresses. Part of 33073. --- proposals/312-relay-auto-ipv6-addr.txt | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/proposals/312-relay-auto-ipv6-addr.txt b/proposals/312-relay-auto-ipv6-addr.txt index 29a45f6..98306c7 100644 --- a/proposals/312-relay-auto-ipv6-addr.txt +++ b/proposals/312-relay-auto-ipv6-addr.txt @@ -280,11 +280,19 @@ Ticket: #33073 packets. Instead, it uses the socket APIs to discover the interface address for the socket. - Tor already ignores private IPv4 interface addresses on public relays. - (Binding to private DirPort addresses is supported, for networks that use - NAT.) We propose to also ignore private IPv6 interface addresses. If all - IPv4 or IPv6 interface addresses are private, address resolution should go - to the next step. + Relays that use NAT to reach the Internet may have no publicly routable + local interface addresses, even on the public tor network. The NAT box has + the publicly routable addresses, and it may be a separate machine. + + Relays may also be unable to detect any local interface addresses. The + required APIs may be unavailable, due to: + * missing OS or library features, or + * local security policies. + + Tor already ignores private IPv4 interface addresses on public relays. We + propose to also ignore private IPv6 interface addresses. If all IPv4 or + IPv6 interface addresses are private, address resolution should go to the + next step. 3.2.4. Use Own Hostname IPv6 Addresses

1 0

[torspec/master] Prop 312: Explain address resolution using sockets
by teor＠torproject.org 05 Feb '20

05 Feb '20

commit f090a2233c9180df6b606c1b598fe72a1ae5441c Author: teor <teor(a)torproject.org> Date: Tue Feb 4 14:16:17 2020 +1000 Prop 312: Explain address resolution using sockets As suggested by Nick Mathewson. Part of 33073. --- proposals/312-relay-auto-ipv6-addr.txt | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/proposals/312-relay-auto-ipv6-addr.txt b/proposals/312-relay-auto-ipv6-addr.txt index 98306c7..3209e0b 100644 --- a/proposals/312-relay-auto-ipv6-addr.txt +++ b/proposals/312-relay-auto-ipv6-addr.txt @@ -101,7 +101,7 @@ Ticket: #33073 1. the Address torrc option 2. the address of the hostname (resolved using DNS, if needed) 3. a local interface address - (by making a self-connected socket, if needed) + (by making an unused socket, if needed) 4. an address reported by a directory server (using X-Your-Address-Is) When using the Address option, or the hostname, tor supports: @@ -147,7 +147,7 @@ Ticket: #33073 1. the Address torrc option 2. the advertised ORPort address 3. a local interface address - (by making a self-connected socket, if needed) + (by making an unused socket, if needed) 4. the address of the host's own hostname (resolved using DNS, if needed) 5. an address reported by a directory server (using X-Your-Address-Is) @@ -275,10 +275,11 @@ Ticket: #33073 online, except for short quotes (see [getaddrinfo man page] for the relevant quote). - If the local interface addresses are unavailable, tor opens a self-connected - UDP socket to a publicly routable address, but doesn't actually send any - packets. Instead, it uses the socket APIs to discover the interface address - for the socket. + If the local interface addresses are unavailable, tor opens a UDP socket to + a publicly routable address, but doesn't actually send any packets. + Instead, it uses the socket APIs to discover the interface address for the + socket. (UDP is used because it is stateless, so the OS will not send any + packets to open a connection.) Relays that use NAT to reach the Internet may have no publicly routable local interface addresses, even on the public tor network. The NAT box has

1 0

[torspec/master] Prop 312: Remove the DirPort method
by teor＠torproject.org 05 Feb '20

05 Feb '20

commit 0159850437236d0ff8bcd1089ca3aa95e02c07d2 Author: teor <teor(a)torproject.org> Date: Tue Feb 4 12:45:52 2020 +1000 Prop 312: Remove the DirPort method It's unlikely to be useful for most configurations. As suggested by Nick Mathewson. Part of 33073. --- proposals/312-relay-auto-ipv6-addr.txt | 81 ++++++++++++---------------------- 1 file changed, 28 insertions(+), 53 deletions(-) diff --git a/proposals/312-relay-auto-ipv6-addr.txt b/proposals/312-relay-auto-ipv6-addr.txt index 752a0be..29a45f6 100644 --- a/proposals/312-relay-auto-ipv6-addr.txt +++ b/proposals/312-relay-auto-ipv6-addr.txt @@ -47,7 +47,7 @@ Ticket: #33073 Relays, bridges, and directory authorities: * automatically find their IPv6 address, and * for consistency between IPv4 and IPv6 detection: - * start using IPv4 ORPort and DirPort for IPv4 address detection, and + * start using IPv4 ORPort for IPv4 address detection, and * re-order IPv4 address detection methods. Relays and directory authorities (but not bridges): @@ -60,7 +60,7 @@ Ticket: #33073 * clients also check IPv6 addresses when rotating TLS keys for new networks. In addition to the changes to IPv4 address resolution, most of which won't - affect clients. (Because they do not set Address, ORPort, or DirPort.) + affect clients. (Because they do not set Address or ORPort.) Throughout this proposal, "relays" includes directory authorities, except where they are specifically excluded. "relays" does not include bridges, @@ -146,14 +146,20 @@ Ticket: #33073 IPv6 addresses in this order: 1. the Address torrc option 2. the advertised ORPort address - 3. the advertised DirPort address (IPv4 only; relays, not bridges) - 4. a local interface address + 3. a local interface address (by making a self-connected socket, if needed) - 5. the address of the host's own hostname (resolved using DNS, if needed) - 6. an address reported by a directory server (using X-Your-Address-Is) + 4. the address of the host's own hostname (resolved using DNS, if needed) + 5. an address reported by a directory server (using X-Your-Address-Is) + + Each of these address resolution steps is described in more detail, in its + own subsection. - (Each of these address resolution steps is described in more detail, in its - own subsection.) + We avoid using advertised DirPorts for address resolution, because: + * they are not supported on bridges, + * they are not supported on IPv6, + * they may not be configured on a relay, and + * it is unlikely that a relay operator would configure an ORPort without + an IPv4 address, but configure a DirPort with an IPv4 address. While making these changes, we want to preserve tor's existing behaviour: * resolve Address using the local resolver, if needed, @@ -246,37 +252,7 @@ Ticket: #33073 use NAT to reach the Internet.) If an ORPort address is private, address resolution should go to the next step. -3.2.3. Use the Advertised DirPort IPv4 Address - - Next, we propose that relays use the first advertised DirPort IPv4 address, - as configured in their torrc. - - The following DirPort configurations can not be used for address - resolution, because they are not supported: - * bridge DirPorts, and - * advertised IPv6 DirPorts. - - The DirPort address may be a hostname. If it is, tor should try to use it to - resolve an IPv4 address, and open a DirPort on the first available IPv4 - address. Tor should only look for IPv6 addresses if the IPv6Only port flag - is specified. (Since advertised IPv6 DirPorts are not supported, a - working configuration may also require the NoAdvertise flag.) - - Relays currently use the first advertised ORPort IPv6 address as their IPv6 - address. We propose to use the first advertised IPv4 DirPort address in a - similar way, for consistency. - - Therefore, this change may affect existing relay IPv4 addressses. We expect - that a very small number of relays may change IPv4 address, from a guessed - IPv4 address, to their first advertised IPv4 DirPort address. (But we expect - that most relays that change will be using their ORPort address.) - - For the purposes of address resolution, tor should also ignore private - configured DirPort addresses on public tor networks. (See the previous - section for details.) If a DirPort address is private, address resolution - should go to the next step. - -3.2.4. Use Local Interface IPv6 Address +3.2.3. Use Local Interface IPv6 Address Next, we propose that relays (and bridges) use publicly routable addresses from the OS interface addresses or routing table, as their IPv4 and IPv6 @@ -310,7 +286,7 @@ Ticket: #33073 IPv4 or IPv6 interface addresses are private, address resolution should go to the next step. -3.2.5. Use Own Hostname IPv6 Addresses +3.2.4. Use Own Hostname IPv6 Addresses Next, we propose that relays (and bridges) get their local hostname, look up its addresses, and use them as its IPv4 and IPv6 addresses. @@ -331,7 +307,7 @@ Ticket: #33073 each family should be used. If all IPv4 or IPv6 hostname addresses are private, address resolution should go to the next step. -3.2.6. Use Directory Header IPv6 Addresses +3.2.5. Use Directory Header IPv6 Addresses Finally, we propose that relays get their IPv4 and IPv6 addresses from the X-Your-Address-Is HTTP header in tor directory documents. To support this @@ -392,7 +368,7 @@ Ticket: #33073 Address resolution should continue the next time tor receives a directory header containing a public IPv4 or IPv6 address. -3.2.7. Disabling IPv6 Address Resolution +3.2.6. Disabling IPv6 Address Resolution Relays (and bridges) that have a reachable IPv6 address, but that address is unsuitable for the relay, need to be able to disable IPv6 address @@ -418,7 +394,7 @@ Ticket: #33073 resolution, IPv6 ORPorts, IPv6 reachability checks, and publishing an IPv6 ORPort in its descriptor. -3.2.7.1. Disabling IPv6 Address Resolution: Alternative Design +3.2.6.1. Disabling IPv6 Address Resolution: Alternative Design As an alternative design, tor could change its interpretation of the IPv4Only flag, so that the following configuration lines disable IPv6: @@ -433,7 +409,7 @@ Ticket: #33073 Therefore, we avoid this design, becuase it changes the meaning of existing flags and options. -3.2.8. Automatically Enabling an IPv6 ORPort +3.2.7. Automatically Enabling an IPv6 ORPort We propose that relays (and bridges) that discover their IPv6 address, should open an ORPort on that address, and test its reachability (see @@ -474,8 +450,7 @@ Ticket: #33073 Clients should skip address resolution steps that don't apply to them, such as: - * the ORPort option, - * the DirPort option, and + * the ORPort option, and * the Address option, if it becomes a relay module option. 3.4. Alternative Address Resolution Designs @@ -493,7 +468,7 @@ Ticket: #33073 behaviour. (For example, see [Proposal 306: Client Auto IPv6 Connections].) When bridges fetch directory documents via IPv6, they will be able to find - their IPv6 address using directory headers (see 3.2.6). + their IPv6 address using directory headers (see 3.2.5). 3.4.2. Guessing Muliple IPv4 or IPv6 Addresses @@ -521,7 +496,7 @@ Ticket: #33073 (and bridge) addresses are fixed, or change occasionally. And most relays can reliably discover their address using directory headers, if all other methods fail. (Bridges won't discover their IPv6 address from directory - headers, see section 3.2.6.) + headers, see section 3.2.5.) If complex address resolution is required, it can be configured using a dynamic DNS name in the Address torrc option, or via the control port. @@ -776,7 +751,7 @@ Ticket: #33073 3.5.7. 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.4). + IPv4 and IPv6 address detection (see section 3.2.3). Rewrite the get_interface_address*() functions to choose an interface address on the default route, or to sort default route addresses first in @@ -788,7 +763,7 @@ Ticket: #33073 This change might not be necessary, because the directory header IP address method will find the IP address of the default route, in most cases - (see section 3.2.6). + (see section 3.2.5). 3.5.8. Add IPv6 Support Using gethostbyname2() @@ -796,7 +771,7 @@ Ticket: #33073 resolution on older OSes. These changes affect: * the Address torrc option, when it is a hostname (see section 3.2.1), and - * automatic hostname resolution (see section 3.2.5). + * automatic hostname resolution (see section 3.2.4). Use gethostbyname2() to add IPv6 support to hostname resolution on older OSes, which don't support getaddrinfo(). @@ -911,7 +886,7 @@ Ticket: #33073 already have the relay's addresses from a previous consensus.) Automatically enabling an IPv6 ORPort creates a race condition with IPv6 - extends (see section 3.2.8 of this proposal, and + extends (see section 3.2.7 of this proposal, and [Proposal 311: Relay IPv6 Reachability]). This race condition has the most impact when: @@ -1031,7 +1006,7 @@ Ticket: #33073 [Proposal 306: Client Auto IPv6 Connections] needs to be modified to keep bridge IPv6 behaviour in sync with client IPv6 behaviour. (See section - 3.2.6.) + 3.2.5.) References:

1 0

[torspec/master] Prop 312: Define an IPv6 sybil block
by teor＠torproject.org 05 Feb '20

05 Feb '20

commit 13e8c8c231d51483d4fcd835ac6f833804c73025 Author: teor <teor(a)torproject.org> Date: Tue Feb 4 23:15:45 2020 +1000 Prop 312: Define an IPv6 sybil block As suggested by Nick Mathewson and s7r. Part of 33073. --- proposals/312-relay-auto-ipv6-addr.txt | 33 +++++++++++++++++++++++++++++++-- 1 file changed, 31 insertions(+), 2 deletions(-) diff --git a/proposals/312-relay-auto-ipv6-addr.txt b/proposals/312-relay-auto-ipv6-addr.txt index e434267..7724afd 100644 --- a/proposals/312-relay-auto-ipv6-addr.txt +++ b/proposals/312-relay-auto-ipv6-addr.txt @@ -972,6 +972,7 @@ Ticket: #33073 * IPv4 /8 and IPv6 /16 for port summaries, * IPv4 /16 and IPv6 /32 for path selection (avoiding relays in the same network block). + See also the next section, which uses IPv6 /64 for sybils. 3.5.6. Add IPv6 Support to AuthDirMaxServersPerAddr @@ -982,8 +983,36 @@ Ticket: #33073 and returns a list of IPv4 or IPv6 sybils. Use the modified get_possible_sybil_list() to exclude relays from the - authority's vote, if there are more than AuthDirMaxServersPerAddr on the - same IPv4 or IPv6 address. + authority's vote, if there are more than: + * AuthDirMaxServersPerAddr on the same IPv4 address, or + * AuthDirMaxServersPerIPv6Site in the same IPv6 /64. + + We choose IPv6 /64 as the IPv6 site size, because: + * provider site allocations range between /48 and /64 + (with a recommendation of /56), + * /64 is the typical host allocation + (see [RFC 6177: IPv6 End Site Address Assignment]), + * we don't want to discourage IPv6 address adoption on the tor network. + + Tor currently uses: + * IPv4 /8 and IPv6 /16 for port summaries, + * IPv4 /16 and IPv6 /32 for path selection (avoiding relays in the same + network block). + See also the previous section, which uses IPv6 /48 for the local network. + + This change allows: + * up to AuthDirMaxServersPerIPv6Site relays on the smallest IPv6 site + (/64, which is also the typical IPv6 host), and + * thousands of relays on the recommended IPv6 site size of /56. + The number of relays in an IPv6 block was previously unlimited, and sybils + were only limited by the scarcity of IPv4 addresses. + + We propose choosing a default value for AuthDirMaxServersPerIPv6Site by + analysing the current IPv6 addresses on the tor network. Reasonable + default values are likely in the range 4 to 50. + + If tor every allows IPv6-only relays, we should review the default value + of AuthDirMaxServersPerIPv6Site. Since these relay exclusions happen at voting time, they do not require a new consensus method.

1 0

[torspec/master] Prop 312: Avoid some address detection state
by teor＠torproject.org 05 Feb '20

05 Feb '20

commit e1815226f1199ee4d6caba9e8897c20ac8d92269 Author: teor <teor(a)torproject.org> Date: Tue Feb 4 19:23:53 2020 +1000 Prop 312: Avoid some address detection state As suggested by Nick Mathewson. Part of 33073. --- proposals/312-relay-auto-ipv6-addr.txt | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/proposals/312-relay-auto-ipv6-addr.txt b/proposals/312-relay-auto-ipv6-addr.txt index a6d89e4..9fbd64d 100644 --- a/proposals/312-relay-auto-ipv6-addr.txt +++ b/proposals/312-relay-auto-ipv6-addr.txt @@ -368,14 +368,16 @@ Ticket: #33073 Tor already ignores private IPv4 addresses in directory headers. We propose to also ignore private IPv6 addresses in directory headers. If all IPv4 and IPv6 addresses in directory headers are private, address resolution should - pause, and return a temporary error. + return a temporary error. Whenever address resolution fails, tor should warn the operator to set the Address torrc option for IPv4 and IPv6. (If IPv4 is available, and only - IPv6 is missing, the log should be at notice level.) + IPv6 is missing, the log should be at notice level.) These logs may need to + be rate-limited. - Address resolution should continue the next time tor receives a directory - header containing a public IPv4 or IPv6 address. + The next time tor receives a directory header containing a public IPv4 or + IPv6 address, tor should use that address for reachability checks. If the + reachability checks succeed, tor should use that address in its descriptor. 3.2.6. Disabling IPv6 Address Resolution

1 0