I’m reading through the manual with a mobile workers scenario in mind, these mobile workers may join the network every day but they may not join for 6 months in rare scenarios.
Section 2.1.2 talks about identities expiring after 60-days.
I assume that this expiry means that within the 60-days, if a new member attempts to join and just so happens to create an identity collision then the root will tell it to generate another key pair as that identity is “in use”?
If a new member were to generate an identity which collided after the 60-day timeout then this would presumably be accepted, this new member wouldn’t inherit Managed IP’s, Tags and/or Capabilities from the original user with the same identity would it? I assume that even though the VL1 identity matches, the private/public key pair is even less likely to match so the new member would start from fresh? What does the network settings page do if two users have a VL1 identity collision, do they both display or does the old member get replaced by the new user?
I understand that these possibilities are extremely unlikely but I’m just trying to understand the underlying behaviour of the system in this event. As a side note, is it known just how likely this is, how many public key values can converge into a single 40-bit identity?
No it wouldn’t. What networks a machine is joined to is configured on a per machine basis. That information is not shared between nodes. The controller knows what nodes are authorized to use a network, but not whether or not a node is actually joined to it.
What the 60-day expiry means is that after 60 days of abcdef1234 being offline, roots will not retain nor return any path information requests form other peers about abcdef1234. Networks operate at VL2 (see the manual). Nothing about a member on a network is forgotten unless explicitly deleted by the owner of the network. VL2 manages networks, access to networks, and who can talk to who. Peers communicate via VL1.
There can be 2^40 unique node IDs, hence a 40-bit identity. There would need to be roughly 1 trillion identities in use and generated before there’s a 50% probability of a collision (see Birthday Problem ). There’s room in the ZeroTier protocol to expand to a higher number of bits as we grow. Being near 1 trillion addresses in use would be a nice problem to have for us The current probability of a VL1 address collision is extraordinarily low. For a node ID collision to go undetected, the original node would have to be offline for > 60 days. The probability of this happening is even lower.
Now, if a node does happen to collide and go undetected, this doesn’t mean the node is magically connected to your networks already. That’s state on an individual node. So an attacker would have to do the following to do what you’re describing:
Your node has to be offline for 60 days
Has to generate an address collision for a specific node.
Has to also know a specific network ID in order to join and access it.
Without all 3, the worst scenario that will happen when the offline for 60 days node comes back online is that other peers will have difficulty communicating with it because the roots think it’s in 2 places at once.
Thanks for the explanation, I’ve clearly got this wrong in my head though.
Please forgive my ignorance, you’re the experts but I just want to bend my head around this!
Is the largest possible 40-bit number not 1,099,511,627,776? (circa. 1.1 trillion)
From my very very limited hash research it seems a rule of thumb that you have a 50% chance of a collision with a 40-bit number at sqr(1,099,511,627,776) = 1,048,576.
Where am I going wrong with this?
Finally, just so I completely understand the concept…
If someone were to end up with an identical identity to a previously approved identity, which had been offline for 61 days and then attempted to join the specific network… they would have the same tags and capabilities from the flow rules as the original identity?
If they join the same network then yes that would be the case. The likelihood of this is infinitesimally small.
–
This is incorrect. There needs to be roughly 1,000,000,000,000 to reach a 50% chance of a collision. Taking the square root of the total is not how you calculate that.
That table shows the probability of a single collision happening in a data set. That’s not the same as the probability generating an identity collision with an existing identity. So given a 40 bit identity, there’s a 50% chance of a single collision occurring by the time 1.2x10^6 identities have been generated. On identity generation when a node first starts up, there needs to be about 1,000,000,000,000 identities in use for there to be a 50% chance of it colliding with any existing identity. That’s approximately 12 devices running ZeroTier per person on Earth. Again, we’d love to have that problem!
Now, to make things even more difficult, there’s also a proof-of-work component of ZeroTier identity generation. You can’t just generate a random 40 bits and have it be a valid identity. This proof-of-work requires time and thus slows down identity generation. So to purposely collide with a specific identity, you’d need about 1,743 CPU years of computation for a 50% chance of generating a collision for that identity. Additionally, you’d have to hack our roots & expunge the identities/public keys. It’d be far more cost effective to break into your location and steal your machine to get your existing identity.
The current probability of a VL1 address collision is extraordinarily low. For a node ID collision to go undetected, the original node would have to be offline for > 60 days. The probability of this happening is even lower.