[tor-bugs] #20916 [Core Tor/Tor]: Inconsistent IPv6 address between consensus and microdescriptor

[Tor Bug Tracker & Wiki]

#20916: Inconsistent IPv6 address between consensus and microdescriptor
------------------------------+------------------------------------
 Reporter:  teor              |          Owner:
     Type:  defect            |         Status:  new
 Priority:  Medium            |      Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor      |        Version:
 Severity:  Normal            |     Resolution:
 Keywords:  ipv6, regression  |  Actual Points:
Parent ID:                    |         Points:  1
 Reviewer:                    |        Sponsor:
------------------------------+------------------------------------

Comment (by teor):

 Here is the relevant microdesc consensus:
 https://collector.torproject.org/recent/relay-descriptors/microdescs
 /consensus-microdesc/2016-12-07-11-00-00-consensus-microdesc

 I really do think we should have put the 'a' line in the microdesc
 consensus instead of the microdescriptor. But it's too late for that now.

 '''A Diversion'''

 My branch bug20916 contains exactly the wrong solution to this problem: I
 made the microdescriptor change based on the authority's reachability for
 the IPv6 address.

 '''A Complex Solution'''

 One way to fix this issue is to:
 * define a flag UnreachableIPv6,
 * have authorities vote for it if AuthDirHasIPv6Connectivity is set and
 they are sure the relay is unreachable,
 * produce a consensus based on the majority view from authorities that
 know the UnreachableIPv6 flag, and then
 * have clients ignore the IPv6 address in the 'a' line if UnreachableIPv6
 is present.

 There are 3 possible states for authorities with
 AuthDirHasIPv6Connectivity set:
 * reachable: put the IPv6 address in the vote,
 * unknown: the authority hasn't been up for enough time to determine
 reachability: no address, no flag in the vote,
 * unreachable: put the UnreachableIPv6 in the vote.

 There is 1 possible state for authorities without
 AuthDirHasIPv6Connectivity set:
 * unknown: the authority doesn't have IPv6: no address, no flag.

 So the consensus rules become rather complicated.
 Let's try something simpler.

 '''A Simpler Solution'''

 Another way to fix this issue is to:
 * define a flag NoIPv6Consensus,
 * have authorities vote for IPv6 addresses as normal,
 * have authorities know the NoIPv6Consensus flag when they have been up
 for long enough to determine IPv6 reachability,
 * produce a consensus on NoIPv6Consensus based on a majority IPv6 address
 votes from authorities that know the NoIPv6Consensus flag, and then
 * have clients ignore the IPv6 address in the 'a' line if NoIPv6Consensus
 is present.

 There are 2 possible states for authorities with
 AuthDirHasIPv6Connectivity set:
 * reachable: know the NoIPv6Consensus flag in the vote,
 * unreachable: the authority hasn't been up for enough time to determine
 reachability: don't know the NoIPv6Consensus flag in the vote,
 and in any case, vote for IPv6 addresses as normal,

 There is 1 possible state for authorities without
 AuthDirHasIPv6Connectivity set:
 * unknown: the authority doesn't have IPv6: don't know the NoIPv6Consensus
 flag in the vote,
 and don't vote for any IPv6 addresses.

 The consensus for IPv6 votes becomes:
 * if a majority of authorities that know the NoIPv6Consensus flag agree on
 the IPv6 address, put the IPv6 address in the full consensus,
 * otherwise, put the NoIPv6Consensus flag in all consensus flavours, leave
 the IPv6 address out of the full consensus, and clients should ignore the
 IPv6 address in descriptors and microdescriptors.

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