[tor-bugs] #28812 [Core Tor/Tor]: Duplicates of nodes descriptors can be found in consensus files

[Tor Bug Tracker & Wiki]

#28812: Duplicates of nodes descriptors can be found in consensus files
--------------------------+----------------------------------
 Reporter:  wagon         |          Owner:  (none)
     Type:  defect        |         Status:  closed
 Priority:  Medium        |      Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |        Version:  Tor: 0.3.4.9
 Severity:  Normal        |     Resolution:  not a bug
 Keywords:  tor-client    |  Actual Points:
Parent ID:                |         Points:
 Reviewer:                |        Sponsor:
--------------------------+----------------------------------
Changes (by teor):

 * milestone:   => Tor: unspecified


Comment:

 Replying to [comment:2 wagon]:
 > Replying to [comment:1 nickm]:
 > > Probably not.  We consider two nodes to be different if they have
 different keys, and the same otherwise.
 > They cannot be different if they claim that they are using the same IP
 and the same ports. These two different tor instances cannot serve any
 useful purpose. Two different processes cannot listen on the same IP and
 port.

 Two different processes cannot listen on the same IP and port *at exactly
 the same time, on some operating systems*.

 And that's not even true: SSL multiplexing is a thing. Although SSL
 multiplexing probably isn't happening here, because the right way to load-
 balance tor relays is to make 2 tor relays on different ports, and let the
 network load-balance,

 > > As long as they don't stay up longterm or get assigned any important
 flags, it's not going to hurt anything.
 > How client can select which of them to use if both of them are on the
 same IP and port? Tor client doesn't know which of these duplicate keys
 the node in question is using in particular time moment.

 In both these cases, at least one of the duplicates has a 0 bandwidth. Tor
 clients will never select nodes with a 0 bandwidth for anything.

 > If you say that such nodes cannot work in network anyway, why they are
 included in consensus and distributed to clients? If you say that such
 nodes can work, we are in trouble again, because most probably they are
 unusable because of what I've said before.

 Relays with 0 bandwidths are measured by the bandwidth authorities. If the
 measurement fails with the wrong key, the bandwidth stays at 0.

 Relays are checked for reachability by the directory authorities. Relays
 that aren't reachable at a particular key, IP address, and port lose the
 Running flag, and are excluded from the consensus.

 But these checks take time, so inconsistencies can be present for a short
 time before being resolved.

 > How it can be not a bug?

 Because the Tor consensus doesn't provide any uniqueness guarantees. And
 any future uniqueness guarantees would need to be specified very
 carefully, because they are a denial of service risk.

 If you'd like to suggest some changes to Tor, we have a proposals process:
 https://gitweb.torproject.org/torspec.git/tree/proposals/001-process.txt

 > Meanwhile, I caught it again with another node (Tue Dec 11 03:59:04 UTC
 2018):
 >
 > {{{
 > r default Iw3aijlAo3wtwMPpS81P+jXWBXM 2018-12-11 02:07:48 218.221.211.72
 42958 0
 > m kP1vdWn7duAfwAsWDXy1WEQWMFYf0AHhw03vmCUepdM
 > s Running V2Dir Valid
 > v Tor 0.3.5.5-alpha
 > pr Cons=1-2 Desc=1-2 DirCache=1-2 HSDir=1-2 HSIntro=3-4 HSRend=1-2
 Link=1-5 LinkAuth=1,3 Microdesc=1-2 Relay=1-2
 > w Bandwidth=0 Unmeasured=1
 >
 > r default nvcZXCZwkee2bTJUZEBI9zpju40 2018-12-11 02:32:31 218.221.211.72
 42958 0
 > m PhWgGNtH2OHFrkO4YA18a9OqKm/491SwRwUYY+lCC/o
 > s Running V2Dir Valid
 > v Tor 0.3.5.5-alpha
 > pr Cons=1-2 Desc=1-2 DirCache=1-2 HSDir=1-2 HSIntro=3-4 HSRend=1-2
 Link=1-5 LinkAuth=1,3 Microdesc=1-2 Relay=1-2
 > w Bandwidth=0 Unmeasured=1
 > }}}

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