Each node sends its information, like its name, public keys, etc via IPv6 link local multicast packets. I’ll call these packets advertisements. I choose IPv6 link local because no manual IP address configuration is required. The kernel automatically assigns IPv6 link local addresses for each network interface.
When another node (B) receives the multicast packets, it knows that it can receive packets from the former node (A), but what about the other way round? For that, node B then establishes a TCP connection to node A. If node B can connect to node A, we can conclude that a bidirectional communication is possible between node A and node B.
Let’s say that you have 3 nodes, A, B, and C.
What happens if Node C sends Node A an advertisement for Node B’s name with Node C’s public key?
When A tries to talk to to B’s name, it connects to C using C’s key. C connects to B using B’s public key, proxying the connection, and performing a man in the middle attack.
That advertisement would be interpreted as Node C’s advertisement.
The plan is to treat public keys as node’s identity and trust mechanism similar to OpenPGP (e.g. include any node key signed by a master key as a cluster member)
Right now, none of the encryption part is done and it is not a priority right now. I need to first implement transitive node detection, actually forward packets between nodes, some way to store and manage routes, and then trust and encryption mechanisms before I’d dare to test this stuff on a real network.
threaded - newest
Is this your blog? If so, can you sort out word wrap?
<img alt="" src="https://lemmy.world/pictrs/image/18f5f25b-0fdd-4402-9d1e-4adbdab5559c.png">
The UI is desktop only for now, I’ll make the mobile UI some day.
Let’s say that you have 3 nodes, A, B, and C.
What happens if Node C sends Node A an advertisement for Node B’s name with Node C’s public key?
When A tries to talk to to B’s name, it connects to C using C’s key. C connects to B using B’s public key, proxying the connection, and performing a man in the middle attack.
That advertisement would be interpreted as Node
C’s advertisement.The plan is to treat public keys as node’s identity and trust mechanism similar to OpenPGP (e.g. include any node key signed by a master key as a cluster member)
Right now, none of the encryption part is done and it is not a priority right now. I need to first implement transitive node detection, actually forward packets between nodes, some way to store and manage routes, and then trust and encryption mechanisms before I’d dare to test this stuff on a real network.