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:
Parent ID:                                 |         Points:
 Reviewer:                                 |        Sponsor:
-------------------------------------------+-------------------------------

Comment (by teor):

 Replying to [ticket:29570 s7r]:
 >
 > ...
 >
 > This is one rare and strange setup of using IPv6 in a way it is not
 intended, but we should still make sure that:
 >
 > - if ORPort [IPv6:address::x]:port '''NoListen''' was set in torrc, and
 there is no following ORPort [IPv6:address::y]:port '''NoAdvertise''' or
 [::]:port '''NoAdvertise''' (as in use all available IPv6 addresses) is
 set, warn in the log and '''do not build the descriptor using the NoListen
 address''', since the daemon is not listening on any address from the v6
 class.

 Here's another way of expressing that rule:
 * on a relay, for each IP family, the number of configured advertised
 addresses must be less than or equal to the number of configured listening
 addresses

 This will require a tor man page change. The spec only talks about
 advertised addresses, so there's no need for a spec change.

 > - check if the logic is applied for IPv4 also, even it's impossible to
 experience this in IPv4 since UnreachableIPv4 doesn't exist and can't
 possibly exist.

 UnreachableIPv4 does exist in the current Tor network. It's called "not
 Running", and it means that the relay is not in the consensus.

 Here are our current address rules:
 1. descriptors can have multiple advertised IPv4 and IPv6 addresses
   * but our tor implementation only puts the first configured address from
 each family in the descriptor
 2. there must be at least one advertised IPv4 addresses in a descriptor
 3. authorities take the first advertised address from each IP family on
 each relay, and test it for reachability
 4. if all of the tested addresses from a relay are reachable, authorities
 put the tested addresses in the consensus

 Rule 2 may change to require dual-stack or IPv6-only in the far future. So
 we shouldn't lock in IPv4 in any other rule.

 > Otherwise we fill the descriptor with useless data and also have the
 directory authorities chase green horses.

 You're right: there's no point in advertising two addresses that go to the
 same port. If we do want a configuration like that, the appropriate way to
 do it is with a (null) pluggable transport.

 > I think we have this since forever, but not marking this as a backport
 given the rare cases when it can occur and the state of current IPv6
 adoption.

 I agree, no backport on this one, it's too risky.

 Replying to [comment:2 s7r]:
 > Actually I am not sure if the correct action here is to just correct the
 descriptor and continue with a warning in logs (in cases of dual stack
 relays where v4 is correctly set-up, but just v6 is not configured
 properly) or better '''terminate and exit''' until everything is either
 corrected, either removed entirely from the config.
 >
 > Thinking on the really long term when IPv6 will take over or at least be
 mandatory in Tor, so we don't have to go back to this. After all, it's
 broken config / setup in terms of relay ports, it's not bad to exit on
 mistakes at such important config parameters.

 Our general policy with address config errors is to break as early and as
 severely as possible.

 We used to try to cope by gracefully degrading to IPv4. But relay
 operators asked us to send a stronger signal, so they know when their IPv6
 configs are broken.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/29570#comment:3>
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