Network Blacklisting from config file

[NicolasDP]

add a mean for the user to set a list of IP addresses to blacklist.

This list will be in the config file, and will blacklist incoming connection from these peers or will remove the IP addresses from any incoming gossips.

[stanfieldr]

What would be the advantages of handling this at the software layer instead of at the firewall?

[NicolasDP]

You can blacklist from your firewall indeed. But you won't be able to filter out the IP addresses from the gossips too.

[JamesRobertKelley]

I believe you're planning to get rid of Public IDs, but a blacklist for public IDs could be good. Also, a bad but satisfying idea would be a blacklist for blocks by specific pool IDs.

[feqifei]

I think it's a very bad and dangerous idea. You cannot allow that the majority shuts up a node because a node is a voice, a human being, a small community. Even if sometimes in the past it acted as pool or even a bad actor. In the history majorities also voted dictators in free elections so you cannot delegate the majority of something that in democracy is in charge of Constitutions and Supreme Courts. It must be the algo that takes care of understanding if that node, that voice, is putting in danger the net or is asking for help through a message on the blockchain. It's the algo that has to punish bad behaviors but keep the door open to everybody. You can imagine a kind of "Lost" situation where a survivor could send an SOS message on the chain but that node is banned by the majority? Please re-think it again.

[mmahut]

@feqifei while your idea might be nice, I think you misunderstand how the protocol is supposed to work. The goal of the protocol is to keep a stable, performing and secure network, not be to fair to all players at all time.

[consuman]

I also think this is a dangerous and bad idea. Everyone with real bad intentions will be able to circumvent this, through a new IP, Proxy or whatever but this will hurt people making mistakes and once they are on the blacklist, that might get carryed around and copy&pasted to lots of nodes, in the hope to make nodes run more stable, people might be excluded without even noticing, constantly trying to get connected again.

This is against what I think Cardano stands for and can only be a desperate solution for a protocol not fit for the real world.

For network protection I got nothing against automatic quarantine in case of bad or poor behaviour, but only temporary and with clear notice in the nodelogs. @feqifei really got a point here.

[feqifei]

@mmahut it's the behavior that need to be evaluated and in case punished and the algo cannot cut the corner allowing participants to ban ip addresses undefinitely. An IP address is not an ID card, it's fungible. Can you imagine if you decide to run a vps and you buy a static ip address from the provider but later you discover that it's banned by the majority of the cardano community? Maybe because of bad actions related to several years and several owners before? Moreover, the community will relay to entities that will provide a list of bad ip addresses to be added to the node-config file. Who will be responsible to keep a list of "bad" ip address? Is he reliable? Do you think that this situation match with the idea of decentralization? There are a lot of considerations to do before taking a decision like this. We are not only talking about keeping a protocol stable in my opinion

[mmahut]

@feqifei what is the reason that protocol would not allow it when you can just simply do it using other means, such as firewall as mentioned? or well, just put the code in the node yourself.

[NicolasDP]

Thanks everyone for participating and helping us understand more the use cases of our community.

Being able to blacklist known IP addresses is a basic feature that we want to provide. It is important that operators have the tools and the mean to protect their nodes.

Allowing the node to reject any connections from a given IP address does not mean the whole network will. It only means a node operator felt it was important to block that ip address in order to be successful at operating their nodes (stake pool or not): it can be to prevent DoS or anything else. Providing this at the node level will just make it simpler for the stake pool operator to configure their nodes.