Re: [tor-bugs] #29570 [Core Tor/Tor]: Enforce mutually exclusive logic for IPv6 ORPort flags

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#29570: Enforce mutually exclusive logic for IPv6 ORPort flags
-------------------------------------------------+-------------------------
 Reporter:  s7r                                  |          Owner:  (none)
     Type:  defect                               |         Status:  new
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  unspecified
Component:  Core Tor/Tor                         |        Version:  Tor:
                                                 |  unspecified
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-relay, ipv6, reachability,       |  Actual Points:
  needs-proposal                                 |
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by AVee):

 Replying to [comment:9 teor]:
 > Here are our goals:
 > 1. support IPv4 and IPv6
 > 2. encourage more IPv6 relays
 > 3. make the votes efficient for authorities to create
 > 4. make the consensus efficient for clients to download
 > 5. make relay connections efficient
 > 6. make Tor easy to maintain
 >
 > Allowing an IPv4 and an IPv6 advertised address to redirect to the same
 underlying port:
 > * makes 1 and 2 better for a few relays
 > * makes 3, 4, and 5 slightly worse, all over the network

 Can you explain to me how this makes 3 and 4 worse, compared to the same
 relay running a normal dual stack? Unless i'm missing something here about
 the internals of Tor (which could well be the case) any progress on 2 will
 have a negative impact on 3 and 4.

 Or are you just referring to the impact of potential misconfigurations?

 As for 5, setups like this add extra handling on the network level and
 will introduce some latency. However we can't know the reasons for
 operators to do this, it might still be better then the alternatives they
 have. You could take a stand here and say 'We only want proper no tricks
 IPv6', basically saying 5 is more important then 2. I'm inclined to say
 that some impact on 5 is fine if it helps 2, also because I'm assuming
 relay operator know to keep the impact on 5 within reasonable limits.

 > Rejecting this rare case:
 > * makes 1 and 2 worse for a few relays
 > * makes 3, 4, and 5 slightly better, all over the network
 > * makes 6 a tiny bit worse, because it requires a little bit of extra
 code and documentation

 The way I see it this is the original case being made by s7r, which boils
 down to this:
  A. There is a high probability of this specific configuration being
 incorrect.
  B. The impact of such an incorrect configuration (on 3 and 4) is high
 enough to block it altogether.

 I'm skeptical about A being true, but that's just gut feeling. I simply
 don't expect operators to use {{{NoListen}}} by mistake. (Note that there
 wasn't a misconfiguration in this case, just confusion because it seems to
 take days to test IPv6 reachability.)

 If there is a way to quantify how often this happens that would be really
 useful. (Although I suspect we can't tell the difference between faulty
 IPv6 connectivity, firewall issues and misconfigurations like this.)

 Regardless of me being skeptic here, if we fix A we fix the root cause. So
 something that makes it highly unlikely this is done by accident would be
 a better fix imho. This is why I think a loud but overridable warning
 would be a good solution.

 But that leads to a bigger picture, anything that makes it easier to
 detect common misconfigurations as early and loudly as possible would be
 useful. Would it be useful to discuss more generic solutions to this in a
 separate issue/proposal?
 To reduce the impact on 6 it might even be possible to come up with
 something which doesn't impact the main codebase at all. Would a proposal
 in that direction be useful?

 > Tor uses a proposals process to make design decisions like this.
 > Here is our proposals process:
 > https://gitweb.torproject.org/torspec.git/tree/proposals/001-process.txt

 I've skimmed it, if this goes any further I'll make sure I'll properly
 read it ;-)

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

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs