Extend RPC to unban peers

[ilblackdragon]

If some peers got banned, it's really hard to unban them right now.
Given it sometimes happens due to issues with network, it would be good to be able to restore them back.
Ideally this tool should be inside neard to not require another binary.

• neard peers lists all peers in the database with information if they were banned
• neard unban <peerid>,<peerid> unbans list of peers

[mfornet]

To unban peers in this way nodes will need to restart to apply the changes. Another option is adding this function to our RPC, however it needs to be protected, for example, to make an unban request it should be signed with the secret key from the node.

[ilblackdragon]

I was thinking indeed stop & start node, as this is not normal operation.

But through RPC might be useful. If we are going that way, we would want to have API_KEY (signing is complicated and ideally calling RPCs should not happen from the node which means there won't be any keys).
We can use http base authentication in RPC for this, e.g. curl https://x:<API_KEY>@rpc-host/unban

But I don't think we should do this for Phase 1, to let's keep this in Icebox for now.

[mfornet]

What is the best workflow to generate and validate an API_KEY? It needs to be generated directly with our binary from the node.

I see two ways to do this:

1. Random keys:

• Generate an API_KEY on the fly and store its hash on a database (protected .txt/.json should work ok)
• To check an API_KEY is valid just check its hash is on the database
• To revoke an API_KEY remove it from the database

2. Signed keys:

• Create a new key pair (api_key_generator)
• To generate an API_KEY do:
  • Generate a random number of length K
  • Sign this number using the api_key_generator
  • The generated API_KEY consist on the concatenation of both
• To check an API_KEY is valid check the signature matches
• To revoke an API_KEY change the api_key_generator (it will revoke all other existing API_KEY too).

I think, the first variant is strictly better.

Ok with doing this after phase 1. This entire mechanism will be useful not only for ban/unban peers, but with other private functionalities we want to expose through RPC.

[frol]

Alternatively, we can implement a separate RPC server using a separate TCP port, by default listening on 127.0.0.1, so there is no way to suddenly expose the RPC to the outside world. Exposing this RPC then can be done with a reverse-proxy basic auth configuration or even a custom managing service. This way we don't need to roll out yet another key management.

[stale]

This issue has been automatically marked as stale because it has not had recent activity in the last 2 months.
It will be closed in 7 days if no further activity occurs.
Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity in the last 2 months.
It will be closed in 7 days if no further activity occurs.
Thank you for your contributions.

[frol]

@janewang I want to bring this up to NodeX team awareness. I feel that there might be a need for granular administration of a running node through a dedicated admin RPC. We already have adversarial features hidden under a compilation flag, which might also be moved under this admin RPC.

[bowenwang1996]

If some peers got banned, it's really hard to unban them right now.

That is actually not the case. You can change ban_window in config.json to a small number (such as 1s) to unban peers