Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

peer_store: Increase peer ban time until escapes banned threshold #4031

Merged
merged 3 commits into from
Apr 9, 2024

Conversation

lexnv
Copy link
Contributor

@lexnv lexnv commented Apr 8, 2024

This is a tiny PR to increase the time a peer remains banned.

A peer is banned when the reputation drops below a threshold.
With every second, the peer reputation is exponentially decayed towards zero.

For the previous setup:

  • decaying to zero from (i32::MAX or i32::MIN) would take 948 seconds (15mins 48seconds)
  • from i32::MIN to escaping the banned threshold would take 10 seconds
    This means we are decaying reputation a bit too aggressive and misbehaving peers can misbehave again in 10 seconds.
    Another side effect of this is that we have encountered multiple warnings caused by a few misbehaving peers.

In the new setup:

  • decaying to zero from (i32::MAX or i32::MIN) would take 3544 seconds (59 minutes)
  • from i32::MIN to escaping the banned threshold would take ~69 seconds

This is a followup of:

Testing Done

  • Created a misbehaving client with subp2p-explorer, the client is banned for approx 69seconds until it is allowed to connect again.

cc @paritytech/networking

@lexnv lexnv added A1-insubstantial Pull request requires no code review (e.g., a sub-repository hash update). R0-silent Changes should not be mentioned in any release notes I5-enhancement An additional feature request. D0-easy Can be fixed primarily by duplicating and adapting code by an intermediate coder. labels Apr 8, 2024
@lexnv lexnv requested a review from dmitry-markin April 8, 2024 16:37
@lexnv lexnv self-assigned this Apr 8, 2024
@@ -39,15 +39,22 @@ use crate::protocol_controller::ProtocolHandle;
pub const LOG_TARGET: &str = "peerset";

/// We don't accept nodes whose reputation is under this value.
pub const BANNED_THRESHOLD: i32 = 82 * (i32::MIN / 100);
pub const BANNED_THRESHOLD: i32 = 71 * (i32::MIN / 100);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Worth double-checking we don't have this constant hardcoded anywhere in reputation costs.

/// - `i32::MAX` becomes 0 in exactly 3544 seconds, or approximately 59 minutes
/// - `i32::MIN` becomes 0 in exactly 3544 seconds, or approximately 59 minutes
/// - `i32::MIN` escapes the banned threshold in 69 seconds
const INVERSE_DECREMENT: i32 = 200;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could also include a more complex mechanism for this (where the numbers are also configurable constants):

  • if a peer is reported as banned at least 3 times within 5 minutes
  • then we wait 10 minutes until the reputation is decayed (basically banning the peer for around 10 mins + 69 seconds)

It may be overkill for now, but something to think about if we still have misbehaving peers (like shown in kusama). Would love to get your thoughts on this @dmitry-markin 🙏

Copy link
Contributor

@dmitry-markin dmitry-markin Apr 8, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The goal is to conserve resources not handling misbehaving peers' messages/requests. It seems already fine with ~1 min banning, but we have yet to observe the real DoS attack to make informed decisions regarding the banning mechanism in general.

@paritytech-cicd-pr
Copy link

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable 3/3
Logs: https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/5828418

@lexnv lexnv added this pull request to the merge queue Apr 9, 2024
Merged via the queue into master with commit b1c9209 Apr 9, 2024
130 of 135 checks passed
@lexnv lexnv deleted the lexnv/peer-store-incr branch April 9, 2024 11:54
github-merge-queue bot pushed a commit that referenced this pull request Jun 28, 2024
Counterpart of: #4031

cc @paritytech/networking

---------

Signed-off-by: Alexandru Vasile <[email protected]>
Co-authored-by: Sebastian Kunert <[email protected]>
TomaszWaszczyk pushed a commit to TomaszWaszczyk/polkadot-sdk that referenced this pull request Jul 7, 2024
…ech#4906)

Counterpart of: paritytech#4031

cc @paritytech/networking

---------

Signed-off-by: Alexandru Vasile <[email protected]>
Co-authored-by: Sebastian Kunert <[email protected]>
TarekkMA pushed a commit to moonbeam-foundation/polkadot-sdk that referenced this pull request Aug 2, 2024
…ech#4906)

Counterpart of: paritytech#4031

cc @paritytech/networking

---------

Signed-off-by: Alexandru Vasile <[email protected]>
Co-authored-by: Sebastian Kunert <[email protected]>
sfffaaa pushed a commit to peaqnetwork/polkadot-sdk that referenced this pull request Dec 27, 2024
…ech#4906)

Counterpart of: paritytech#4031

cc @paritytech/networking

---------

Signed-off-by: Alexandru Vasile <[email protected]>
Co-authored-by: Sebastian Kunert <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A1-insubstantial Pull request requires no code review (e.g., a sub-repository hash update). D0-easy Can be fixed primarily by duplicating and adapting code by an intermediate coder. I5-enhancement An additional feature request. R0-silent Changes should not be mentioned in any release notes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants