commit 40486e0b5eed4006b9895f85424c0ad9c0d33eb8
Author: teor <teor(a)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