[tor-bugs] #33222 [Core Tor/Tor]: Prop 311: 4.2. Checking IPv6 ORPort Reachability

[Tor Bug Tracker & Wiki]

#33222: Prop 311: 4.2. Checking IPv6 ORPort Reachability
---------------------------+------------------------------------
 Reporter:  teor           |          Owner:  teor
     Type:  enhancement    |         Status:  assigned
 Priority:  Medium         |      Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor   |        Version:
 Severity:  Normal         |     Resolution:
 Keywords:  ipv6, prop311  |  Actual Points:
Parent ID:  #33221         |         Points:  6
 Reviewer:                 |        Sponsor:  Sponsor55-must
---------------------------+------------------------------------

Old description:

> 4.2. Checking IPv6 ORPort Reachability
>
> We propose that testing relays (and bridges) select some IPv6 extend-
> capable
> relays for their reachability circuits, and include their own IPv4 and
> IPv6
> ORPorts in the final extend cells on those circuits.
>
> The final extending relay will extend to the testing relay:
>   * using an existing authenticated connection to the testing relay
>     (which may be over IPv4 or IPv6), or
>   * over a new connection via the IPv4 or IPv6 ORPort in the extend cell.
>
> The testing relay will confirm that test circuits can extend to both its
> IPv4 and IPv6 ORPorts.
>
> 4.2.1. Selecting the Final Extending Relay
>
> IPv6 ORPort reachability checks require an IPv6 extend-capable relay as
> the second-last hop of reachability circuits. (The testing relay is the
> last hop.)
>
> IPv6-extend capable relays must have:
>   * Relay subprotocol version 3 (or later), and
>   * an IPv6 ORPort.
> (See section 5.1 for the definition of Relay subprotocol version 3.)
>
> The other relays in the path do not require any particular protocol
> versions.
>
> 4.2.2. Extending from the Second-Last Hop
>
> IPv6 ORPort reachability circuits should put the IPv4 and IPv6 ORPorts in
> the extend cell for the final extend in reachability circuits.
>
> Supplying both ORPorts makes these extend cells indistinguishable from
> future client extend cells.
>
> If reachability succeeds, the testing relay (or bridge) will accept the
> final extend on one of its ORPorts, selected at random by the extending
> relay (see section 3.2.1).
>
> 4.2.3. Separate IPv4 and IPv6 Reachability Flags
>
> Testing relays (and bridges) will record reachability separately for IPv4
> and IPv6 ORPorts, based on the ORPort that the test circuit was received
> on.
>
> From proposal 311, section 4.2:
> https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-
> ipv6-reachability.txt#n283

New description:

 4.2. Checking IPv6 ORPort Reachability

 We propose that testing relays (and bridges) select some IPv6 extend-
 capable
 relays for their reachability circuits, and include their own IPv4 and
 IPv6
 ORPorts in the final extend cells on those circuits.

 The final extending relay will extend to the testing relay:
   * using an existing authenticated connection to the testing relay
     (which may be over IPv4 or IPv6), or
   * over a new connection via the IPv4 or IPv6 ORPort in the extend cell.

 The testing relay will confirm that test circuits can extend to both its
 IPv4 and IPv6 ORPorts.

 4.2.1. Selecting the Final Extending Relay

 IPv6 ORPort reachability checks require an IPv6 extend-capable relay as
 the second-last hop of reachability circuits. (The testing relay is the
 last hop.)

 IPv6-extend capable relays must have:
   * Relay subprotocol version 3 (or later), and
   * an IPv6 ORPort.
 (See section 5.1 for the definition of Relay subprotocol version 3.)

 The other relays in the path do not require any particular protocol
 versions.

 4.2.2. Extending from the Second-Last Hop

 IPv6 ORPort reachability circuits should put the IPv4 and IPv6 ORPorts in
 the extend cell for the final extend in reachability circuits.

 Supplying both ORPorts makes these extend cells indistinguishable from
 future client extend cells.

 If reachability succeeds, the testing relay (or bridge) will accept the
 final extend on one of its ORPorts, selected at random by the extending
 relay (see section 3.2.1).

 4.2.3. Separate IPv4 and IPv6 Reachability Flags

 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
 * send and receive cells via outbound OR connections to other relays'
 ORPorts

 From proposal 311, section 4.2:
 https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-
 ipv6-reachability.txt#n283

--

Comment (by teor):

 Update the end of the description with a robust self-test design.

 Here are some additional notes:

 Once we validate the created cell, we have confirmed that the final remote
 relay has our private keys.

 If our relay was set up using a copy of another relay's keys, then we
 might have connected to that relay. We could test that the create cells we
 receive match create cells that we have actually sent. But that seems
 unnecessary, because duplicate keys are rare. (And authorities enforce key
 uniqueness in the consensus.)

 At best, it would provide a warning for operators who have accidentally
 duplicated their keys. (Operators can override these checks using
 AssumeReachable.)

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/33222#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online