commit 40486e0b5eed4006b9895f85424c0ad9c0d33eb8 Author: teor teor@torproject.org Date: Fri May 1 17:14:37 2020 +1000
Prop 311: Another reachability edge case
Part of 33222. --- proposals/311-relay-ipv6-reachability.txt | 20 +++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/proposals/311-relay-ipv6-reachability.txt b/proposals/311-relay-ipv6-reachability.txt index c23703e..e3fe81a 100644 --- a/proposals/311-relay-ipv6-reachability.txt +++ b/proposals/311-relay-ipv6-reachability.txt @@ -353,10 +353,11 @@ Ticket: #24404
Once we validate the created cell, we have confirmed that the final remote relay has our private keys. Therefore, this test reliably detects ORPort - reachability. + reachability, in most cases. + + There are a few exceptions:
- There is one exception: when another relay on the network is using the same - keys. + A. Duplicate Relay Keys
Duplicate keys are only possible if a relay's private keys have been copied to another relay. That's either a misconfiguration, or a security issue. @@ -375,6 +376,19 @@ Ticket: #24404 accidentally duplicated their keys. (But it doesn't provide any extra security, because operators can disable self-tests using AssumeReachable.)
+ B. Multiple ORPorts in an Address Family + + Some relays have multiple IPv4 ORPorts, or multiple IPv6 ORPorts. In some + cases, only some ports are reachable. (This configuration is uncommon, but + multiple ORPorts are supported.) + + Here is how these tests can pass, even if the advertised ORPort is + unreachable: + * the final extend cell contains the advertised IPv6 address of the + self-testing relay, + * if the extending relay already has a connection to a working NoAdvertise + ORPort, it may use that connection instead. + 4.2.4. No Changes to DirPort Reachability
We do not propose any changes to relay IPv4 DirPort reachability checks at