[tor-bugs] #24404 [Core Tor/Tor]: Propose a relay protover that allows IPv6 extends

[Tor Bug Tracker & Wiki]

#24404: Propose a relay protover that allows IPv6 extends
---------------------------------------------+-----------------------------
 Reporter:  teor                             |          Owner:  (none)
     Type:  enhancement                      |         Status:  new
 Priority:  Medium                           |      Milestone:  Tor:
                                             |  0.3.3.x-final
Component:  Core Tor/Tor                     |        Version:
 Severity:  Normal                           |     Resolution:
 Keywords:  needs-proposal, ipv6, tor-relay  |  Actual Points:
Parent ID:  #24403                           |         Points:  1
 Reviewer:                                   |        Sponsor:  SponsorV-
                                             |  can
---------------------------------------------+-----------------------------

Comment (by teor):

 Replying to [comment:4 Sebastian]:
 > Extend the notion of canonical to have a canonical v4 and a canonical v6
 connection. Only in the event of a reachability check with a "must v4" or
 "must v6" flag create a new connection of the other connection type. Treat
 this second connection as canonical for the purpose of deciding whether to
 close it etc, but not for actual traffic. Does that alleviate the DoS risk
 you're worried about? If not, why not?

 It mitigate it, but does not eliminate it, because it still doubles the
 number of open connections per relay (in a worst-case scenario where all
 relays have IPv6). However, a scheme like this would also substantially
 reduce the need for a fallback mechanism for reachability checking. To
 eliminate it, we could make a must-flagged EXTEND cell trigger a NETINFO
 cell along an existing connection.

 Here's a much nicer alternative fallback that avoids adding must flags:
 * relays with the latest protover respond to NETINFO cells on existing
 connections by sending a NETINFO cell, at most every N minutes per
 connection (N < 20 minutes, the current reachability warning threshold)

 Then the fallback becomes:
 * if there are no relays with the right protover or all relays with the
 right protover have an existing connection to this relay, try these steps
 in order
   1. Elicit a NETINFO cell by sending a relay with the right protover a
 NETINFO cell, where this relay is the server side of the TLS connection
   2. Elicit a NETINFO cell by sending a relay with the right protover a
 NETINFO cell, where this relay is the client side of the TLS connection
   3. Open a connection to a relay to elicit a NETINFO cell

 I think this is conceptually much simpler, uses the same mechanisms we
 would use anyway, and minimises the number of changes required.

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