search

XRPLF / rippled

Decentralized cryptocurrency blockchain daemon implementing the XRP Ledger protocol in C++
https://xrpl.org
ISC License
4.51k stars 1.46k forks source link

Flood control IP whitelist #3173

Open WietseWind opened 4 years ago

WietseWind commented 4 years ago

My local rippled nodes connect to a pair of full history rippled nodes, and I'm getting this in the logs quite often:

2019-Dec-04 10:39:56.016072635 Resource:WRN Consumer entry 10.30.50.100 dropped with balance 15006 at or above drop threshold 15000
2019-Dec-04 10:39:56.016114643 Peer:WRN [009] 10.30.50.100:48768 failed: charge: Resources

An IP whitelist would be nice, like the [ips] section, allowing me to configure local node IP's (or subnets even) that are allowed to consume all resources they ask for.

A [whitelist_ips] (or ...) section would be nice, or simply don't apply flood control on [ips_fixed].

MarkusTeufelberger commented 4 years ago

I think that's what clustering might be used/intended for.

I agree that it would be nice to also be able to have a list of peers (maybe by public key rather than IP?) that are exempt from limits.

wojake commented 2 years ago

Rather then making a new whitelist for this, why don't we just use the UNL?

If we use the UNL, validator maintainers will make sure the validators that are in their UNL are truly trustworthy since a validator in their UNL can attack their validator and drain up their resources.

This will not only increase the trust in the XRP Ledger but it will ensure that the validators dont randomly add unknown and untrustworthy validators to their UNL.

wojake commented 2 years ago

If a validator turns corrupted and attacks its UNL peers, a lot of validators would go offline which will disrupt the XRP Ledger.

So a limit must placed, if one of the validators in the UNL hits this limit, the validator maintainer would be alerted. We wouldn't accualty know if the validator is attacking or if it's going crazy, so the validator maintainer would only be alerted.

I suggest adding this to the feature ^^

@intelliot Can this be added to XRPL 1.8?

MarkusTeufelberger commented 2 years ago

Validators don't announce to other nodes if they are validating and if they would, that would be a security concern (I got a bug bounty for finding and reporting such a case for example).

UNLs don't contain IPS, they contain public keys. UNLs are private to each node, there is no "the" UNL.

Validators shouldn't be full history nodes, validators gain no benefit at all from storing any historic data - they only operate on the current ledger.

wojake commented 2 years ago

I see, thanks for clarifying.

I just realized my mistake midway of writing a response,

My local rippled nodes connect to a pair of ((full history rippled nodes))

I thought he was referencing a regular node. Since not all validators are full history nodes, using a UNL is not the right choice, so I'd go with a whitelist. Thanks.