Implementing network authentication and segregation logic to the nodes domain

[tegefaulkes]

Description

This PR focuses on adding logic to the nodes domain to handle checking if a connection is part of a certain network. If the check passes then the connection is added to the usual connection map. If it fails the connection is rejected and forced to close.

During this authentication period, only certain RPC calls are allowed to be made. These are calls that...

1. Are part of the network authentication process.
2. Are used to negotiate joining a network.

Both sides of the connection need to authenticate each other before the connection can be used for normal RPC traffic.

Issues Fixed

• Fixes Prevent RPC calls for Unauthenticated NodeConnections (Segregated Network Connections) #782
• Related Network Segregation/Authentication Token Logic #779

Tasks

• 1. Add a new map that tracks connections that have not authenticated their network access yet. Add in the logic for negotiating authentication to the network. And only move the connection from this map to the usual connection map once the connection's network access has been checked in both directions. It may be simpler to only track this for the reverse direction.
• 2. Create a middleware utility that rejects RPC calls from being made in the forward and reverse direction unless the connection has passed the network authentication.
• 3. create tests showcasing this new functionality. both the normal case and connections being rejected. 3 types of rejection, forward rejected, reverse rejected and both.
• 4. Update existing tests to work with the logic change.

Final checklist

• Domain specific tests
• Full tests
• Updated inline-comment documentation
• Lint fixed
• Squash and rebased
• Sanity check the final build

[linear]

ENG-373 Prevent RPC calls for Unauthenticated `NodeConnection`s (Segregated Network Connections)

[tegefaulkes]

I'm refreshing my memory and digging through the code. It seems simple enough to add tracking the authentication to the NodeConnectionManager. The only real change is adding authenticatedForward and authenticatedReverse booleans to the newConnAndTimer object. On top of that, we should only update the activeConnection field of the ConnectionsEntry in the connections map once the authentication has been completed.

So.

1. Add booleans for tracking the authentication state for the forward and reverse direction.
2. Only add or switch out the primary connection when the network authentication of a connection has completed.

There is one stumbling block however. Current there is an assumption that a connection that has been added with addConnection is already available to be used. But these changes will create a period of time where a connection exists but can't be used.

So when we create a new connection we not only have to wait for the connection to be established but also wait for the network authentication to be completed before it can be used. So we need to update createConnection to wait for this condition before returning.

I'll need to think on this some more.

[CMCDragonkai]

Status of this @tegefaulkes?

[tegefaulkes]

Still no progress with me focusing on PKE.

[CMCDragonkai]

Reuqires rebase. And ETA on merging this?

[CMCDragonkai]

As a suggestion, don't go too deep in the technicalities of this, until we have a PKE prototype of the entire login process. I want to see polykey agent start --network matrixai.enterprise.polykey.com trigger a browser launch and a login process. It can be flaky, but we need to go through the entire LOOP. All the way to the bottom.

[tegefaulkes]

If I can focus solely on this? 2-3 days. The core of the implementation is done I just need to do some edge case logic and clean up. The main thing missing right now is the timeout for authenticating and testing.

Right now I'm focusing on prototyping the real time data for PKE and specing out work for Matthew.

[CMCDragonkai]

Should start squashing.

[tegefaulkes]

Pretty much done now. I've done a personal review and I just need to do the final checklist before merging.

With the network authentication, I've set it up so that it works with the public networks. So nodes will only connect to nodes within the same network identified by the network URL. This isn't verified in any way besides just checking what network a node claims to be in. This will be specified by the network parameter when starting a Polykey node. Which is set by the --network parameter in CLI.

[tegefaulkes]

Done and merging.

[CMCDragonkai]

Pretty much done now. I've done a personal review and I just need to do the final checklist before merging.

With the network authentication, I've set it up so that it works with the public networks. So nodes will only connect to nodes within the same network identified by the network URL. This isn't verified in any way besides just checking what network a node claims to be in. This will be specified by the network parameter when starting a Polykey node. Which is set by the --network parameter in CLI.

For the public networks this is all that is required since they are public. They are self-declared.

[CMCDragonkai]

@aryanjassal can we verify this is working by monitoring the node connections. Testnet and mainnet shouldn't be connecting to each other.

[CMCDragonkai]

Ideally they shouldn't even try to connect to each other as the node discovery algos should ignore telling the other node about them.