aboutsummaryrefslogtreecommitdiff
path: root/proposals/311-relay-ipv6-reachability.txt
diff options
context:
space:
mode:
authorteor <teor@torproject.org>2020-04-28 13:40:30 +1000
committerteor <teor@torproject.org>2020-04-28 13:40:30 +1000
commitf12126bd8ab9a8068aacc015edc085286dd587a9 (patch)
treea100221314f7e0cfc02bca952a2c332bb013deb9 /proposals/311-relay-ipv6-reachability.txt
parent2e67ae1c70436b949f5d23a67ba24a03b845defc (diff)
downloadtorspec-f12126bd8ab9a8068aacc015edc085286dd587a9.tar.gz
torspec-f12126bd8ab9a8068aacc015edc085286dd587a9.zip
Prop 311: Add design for reachability circuits
Update 4.2.3. Separate IPv4 and IPv6 Reachability Flags. Add a detailed design for checking cells on reachability self-test circuits.
Diffstat (limited to 'proposals/311-relay-ipv6-reachability.txt')
-rw-r--r--proposals/311-relay-ipv6-reachability.txt44
1 files changed, 44 insertions, 0 deletions
diff --git a/proposals/311-relay-ipv6-reachability.txt b/proposals/311-relay-ipv6-reachability.txt
index fd131e1..c23703e 100644
--- a/proposals/311-relay-ipv6-reachability.txt
+++ b/proposals/311-relay-ipv6-reachability.txt
@@ -331,6 +331,50 @@ Ticket: #24404
Testing relays (and bridges) will record reachability separately for IPv4
and IPv6 ORPorts, based on the ORPort that the test circuit was received on.
+ Here is a reliable way to do reachability self-tests for each ORPort:
+
+ 1. Check for create cells on inbound ORPort connections
+
+ Check for a cell on any IPv4 and any IPv6 ORPort. (We can't know which
+ listener(s) correspond to the advertised ORPorts, particularly when using
+ NAT.) Make sure the cell was received on an inbound OR connection.
+
+ 2. Check for created cells from testing circuits on outbound OR connections
+
+ Check for a returned created cell on our IPv4 and IPv6 self-test circuits.
+ Make sure those circuits were on outbound OR connections.
+
+ By combining these tests, we confirm that we can:
+ * reach our own ORPorts with testing circuits,
+ * send and receive cells via inbound OR connections to our own ORPorts,
+ and
+ * send and receive cells via outbound OR connections to other relays'
+ ORPorts.
+
+ 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.
+
+ There is one exception: when another relay on the network is using the same
+ 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.
+ Directory authorities ensure that only one relay with each key is included
+ in the consensus.
+
+ If a relay was set up using a copy of another relay's keys, then its
+ reachability self-tests might connect to that other relay. (If the second
+ hop in a testing circuit has an existing OR connection to the other relay.)
+
+ Relays could test if the inbound create cells they receive, match the
+ create cells that they have sent on self-test circuits.
+
+ But this seems like unnecessary complexity, because duplicate keys are
+ rare. At best, it would provide a warning for some operators who have
+ accidentally duplicated their keys. (But it doesn't provide any extra
+ security, because operators can disable self-tests using AssumeReachable.)
+
4.2.4. No Changes to DirPort Reachability
We do not propose any changes to relay IPv4 DirPort reachability checks at