Allow only connections from specific agent strings

[baubleb]

Is your feature request related to a problem? Please describe.
Connections from old outdated versions of nodes

Describe the solution you'd like
Ability to only allow connections for specific agent strings

Describe alternatives you've considered
Automated script to periodically check and force disconnect the connected nodes via JSON-RPC but that is an after the fact connection thus too late in the process.

Additional context
Currently they get a 1y IP ban, agent string filtering will prevent them getting a continual 1y ban, or a firewall block.

[vertiond]

The issue I see with this is that the agent string doesn't mean much as it can be freely modified by a malicious actor.

[vertiond]

We also wouldn't want to ban honest actors who have modified their agent string.

[baubleb]

We also wouldn't want to ban honest actors who have modified their agent string.

"We"? I decide whom connects to my node, nobody else. It is "my" node, not "yours", not "we".

The issue I see with this is that the agent string doesn't mean much as it can be freely modified by a malicious actor.

There are other values in the connection for versions, just the agent string is human readable.

Either way, I will hard IP block any nodes I do not want, for a very long time, with more control over what connects to the node, that will mitigate against hard blocks to those that do run nodes that I want to be connected to "my" node.

I simply want more control over "my" node, what you do with "your" node is up to "you".

I want to be able to make a "ruleset" of "attributes" on the connecting peer for what can connect to "my" node, right now I have to use JSON-RPC to boot them off if they don't meet "my" connecting peer criteria, and if they persist, I will IP hard block at the firewall. This is easily automated, but after the connection happens.

[vertiond]

You are free to make changes and block connections from whomever you decide; the modifying of agent string or other connection info isn't the way to go about it. The way it currently is set up is based on duplicate requests of headers and after three duplicate requests, that connection is banned.

[baubleb]

the modifying of agent string or other connection info isn't the way to go about it

I don't want any of their connection info modified, just to set a "rule" for what can connect to me as a peer.

For example (but not limited to), as per https://developer.bitcoin.org/reference/rpc/getpeerinfo.html, setting a constraint requirement on minimum version (for example >= 70016) or other attributes of the connecting peer advertised.

Right now, as I have it, the connecting peer gets a very hard long term booting from my node. Having a ruleset available to be defined in the node daemon would reduce that hard block window to when they meet my connecting criteria rather than years down the line.

[vertiond]

Right now, as I have it, the connecting peer sending duplicate requests for old headers gets a very hard long term booting from my node. Having a ruleset available to be defined in the node daemon would reduce that hard block window to when they meet my connecting criteria rather than years down the line.

I believe this to be the core issue - @baubleb could you please add this to the header of the original message to help clarify for others?

[baubleb]

I believe this to be the core issue

It is not the core issue, I want to put RULES into my node daemon as to what kind of peer can connect, be it on version, be it on services, be it on other attributes they advertise in the getpeerinfo.

I want to fine grain control what peers I want connected to my node based on the peer advertised attributes that I can get from getpeerinfo RPC call.

[vertiond]

That's a request for enhancement, not an issue.

[baubleb]

That's a request for enhancement, not an issue.

Obviously that's why it was opened as a feature request.