[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:  Tor: unspecified
Component:  Core Tor/Tor   |        Version:
 Severity:  Normal         |     Resolution:
 Keywords:  ipv6, prop299  |  Actual Points:
Parent ID:  #27491         |         Points:
 Reviewer:  nickm          |        Sponsor:
---------------------------+-----------------------------------

Comment (by neel):

 Sorry for the delay in responding.

 Replying to [comment:11 teor]:
 > 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.)

 Makes sense.

 > 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.

 Sounds good.

 I am happy to write a proposal if nobody else is willing to volunteer for
 that role. Whether or not I write the new proposal, I still plan to
 implement it and write the code for the new proposal.

 > 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

 Sounds good.

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