[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #28812 [Core Tor/Tor]: Duplicates of nodes descriptors can be found in consensus files
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs