Investigate means of authenticating a node ID when adding to `NodeGraph`

[joshuakarp]

Specification

With #344 more or less solved we need a way of authenticating when adding forward connections. this includes authenticating the old connections when a bucket fills up. In both cases we can so a pingNode to check if a node is alive. However the current implementation of pingNode is insufficient for the job as it only checks if a node is alive.

NodeManager.pingNode needs to be updated to match the following criteria;

1. It needs to establish a proxy connection to the target. if a connection can be established then the target is considered alive. if the connection is established then we can consider it authenticated as well.
2. It needs to take an optional address information for checking if direct connections without the nat bashing proceedure can be done. This will be useful for ICE

The NodeManager.setNode needs to be updated to do the following.

1. when a bucket is full the oldest node needs to be verified with pingNode. This is already done, just need to update ping for this. This will need to concurrently check alpha of the oldest connections.
2. Needs an optional force parameter to garentee adding the node.

NodeConnectionManager needs to be updated to;

1. takes NodeManager as part of start.
2. establishing a connection should trigger NM.qeueSetNode

NodeManager needs to be updated to;

1. startStop asyinc init pattern.
2. implement a async queue for adding nodes to the nodeGraph.

After that we need to make sure all instance where we need to add a node just calls NodeManager.setNode. Where this is done still needs to be speced out but this may be outside the scope of this issue. Create a new issue for this?

Additional context

• another very relevant issue: Expunge any added "invalid" nodes from k-buckets #226
• Related Seed node not adding details of connecting node to its NodeGraph #344
• Related Testnet Deployment #326
• Related Authenticate the sender of a hole-punching signalling message #148

Tasks

• update NodeManager.pingNode to match the above specification.
• update NodeManager.setNode to match the above specification.
• implement setnode queue. this is similar to the queue used by discovery.
• seperate pingNode out of setNode
• concurrently check alpha old nodes if a bucket is full when setting node.
• convert NCM and NM to startstop, they rely on each other now with NCM calling NM.qeueSetNode.
• establishing a NodeConnection should trigger setting a node in the nodeGraph by callong NM.qeueSetNode.
• Creating a new connection should not be blocked by setting node.
• Integrate into pk nodes set (with --no-ping and --force) and pk nodes ping

[tegefaulkes]

There are 4 cases where we add a node to the node graph.

1. manually
2. ping a node
3. connect to a node in any way
4. receive a connection from a node

Manually adding a node should ping the node before adding it to the NodeGraph. In fact I think this is functionally identical to pinging a node in outcome except that manually adding the node should guarantee that the node is added to the graph by dropping an older node.

Pinging a node will add the node to the graph but this should be done in the CLI ping command's GRPC handler. having the NodeManager.pingNode is called to verify a node's 'aliveness' during an setNode so we can't have that attempting to set a node.

Adding a node after connecting to it can be handled by the nodeConnectionManager in the with context functions? or possible triggered by the forward proxy? need to explore this more. it would be nice to have this handled neatly in one place.

receiving the connection will be verified by the reverse proxy and then added to the nodeGraph. this is addressed in #344

[tegefaulkes]

WIth the changes in commit 7cc74d0 I added a check for if a node was alive with pingNode. currently this is blocking and will timeout based on the proxies timeout which is usually 20 seconds. This will need to be fixed by letting us set a time out in the ping command. I think there was an issue planed for this? #353? but that's for the node connections, we will need a similar solution for the proxies stuff. New issue?

In any case we ill need to connect to a node and check it's nodeId and certificates data. maybe we can create a new agent-agent RPC for getting a remote node's certificates and nodeId? isn't this already what GRPCClientAgent.nodesChainDataGet does? we can verify the node id and MTLS on the client side as well.

[CMCDragonkai]

Yea the closest issue is #353, by creating a timeout for NodeConnectionManager.

I think however the proxies openConnectionForward and openConnectionReverse should also have timeouts that override the default timeout. This is already supported with the timer parameter.

Also relevant is #297 as background theory into the future.

[CMCDragonkai]

Furthermore solving #353 would just reduce the amount of time waiting for a ping. To really solve the problem of blocking, is to remove blocking entirely. That is we wouldn't want to block a request to contact a Node or do operations against another Node due to pinging old nodes in order to maintain bucket limit.

I suggest that this logic should be non-blocking, and to do so, we can either do non-blocking in-memory by queuing up a job using JS's own event loop, or by queuing it up into the DB and run this as part of a background work as suggested by the longer-kademlia trie paper at the end.

[CMCDragonkai]

Suggest creating a new issue for this non-blocking problem as it relates to #353.

[tegefaulkes]

Ah I just remembered that the feature added in 7cc74d0 just checks that the old node is still alive. as mentioned above authenticating it still needs to be done at this stage and that's only really needed to make sure that the node hasn't changed identities. it should've been authenticated before it was added to the graph.

For adding a new node I think the expectation is that the authentication is done when connecting to it just before adding it to the nodeGraph. We could use the same method we use to authenticate the old nodes but we would be doubling up the action of connecting to the node since the action of adding a node is triggered by a connection to a node in the first place.

As to how the node is authenticated we would need to obtain the connection info from the newly combined Proxy class. Based on this comment #344 (comment) we will add a callback to the Proxy class that will cause a connection event in the EventBus system. This will trigger adding the node to the node graph. Assuming that the proxy authenticates the connection before triggering the event then the only information the event needs is a tuple of (remoteNodeId, remoteHost, remotePort).

[tegefaulkes]

Ignore this, moved old spec back.

[CMCDragonkai]

I think the proxy open connection already does authentication by checking the certificate. Therefore the needing to authenticate a node would only be when one is explicitly adding a node to the node graph.

Any authentication would need to be done prior to adding the node to the node graph.

One question is whether we should allow users to explicitly add nodes to the node manager/graph straight from the command line and therefore not have to be authenticated ahead of time. I think we should allow this as this is would primarily be used for special situations and debugging.

The node manager's add node method can schedule an authentication by scheduling a ping node.

I think the ping node should not just establish a proxy connection but also check the certificates which I believe the proxy does already. But you should check @tegefaulkes