[tor-bugs] #29801 [Core Tor/Tor]: Add teor's suggestions for Prop#299 (referring IPv4 or IPv6 based on IP Version Failure Count)

[Tor Bug Tracker & Wiki]

#29801: Add teor's suggestions for Prop#299 (referring IPv4 or IPv6 based on IP
Version Failure Count)
---------------------------+-----------------------------------
 Reporter:  neel           |          Owner:  neel
     Type:  enhancement    |         Status:  needs_information
 Priority:  Medium         |      Milestone:
Component:  Core Tor/Tor   |        Version:
 Severity:  Normal         |     Resolution:
 Keywords:  ipv6, prop299  |  Actual Points:
Parent ID:  #27491         |         Points:
 Reviewer:  nickm          |        Sponsor:
---------------------------+-----------------------------------
Changes (by teor):

 * status:  needs_review => needs_information


Comment:

 Here is my review:

 I am not sure if we should implement this proposal.

 I think this proposal is really complex. It risks destabilising Tor's
 network code. It uses a lot of randomness, which has led to hard-to-
 diagnose network bugs in the past. (I suggested many of the ideas in the
 proposal, so this complexity and risk is my fault.)

 The proposal is also non-standard: it claims to be "Happy Eyeballs", but
 it does not implement [https://tools.ietf.org/html/rfc8305 RFC 8305]. (The
 simplest version of RFC 8305 uses IPv4 and IPv6 addresses for the same
 machine. It tries IPv6, waits 250ms, then tries IPv4.)

 I'd like to see an alternative proposal for implementing Happy Eyeballs in
 Tor. (Neel, you don't have to write that proposal.) Then we can decide
 which alternative to accept.

 Here's a quick sketch of what a minimal Happy Eyeballs proposal would look
 like:

 When selecting addresses:
 1. Modify extend_info_t so it contains an IPv4 and an IPv6 address
 2. When a bridge or relay has multiple addresses, add them both to the
 extend_info_t.

 When connecting using an extend_info_t:
 1. If there is an existing authenticated connection, use it.
 2. If not, connect using the first available, allowed, and preferred
 address. (IPv4 by default.)
 3. Then, schedule a timer for connecting using the other address, if it is
 available and allowed. We should choose a timer value that is higher than
 most clients successful TLS authentication time.

 When a connection successfully authenticates using TLS:
 1. Cancel any other connection timers
 2. Cancel any other in-progress connections

 When all available and allowed connection attempts fail:
 1. Tell the rest of Tor that the connection has failed

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