-
Notifications
You must be signed in to change notification settings - Fork 804
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
Conversation
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
@@ -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); |
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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 🙏
There was a problem hiding this comment.
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.
The CI pipeline was cancelled due to failure one of the required jobs. |
Signed-off-by: Alexandru Vasile <[email protected]>
Counterpart of: #4031 cc @paritytech/networking --------- Signed-off-by: Alexandru Vasile <[email protected]> Co-authored-by: Sebastian Kunert <[email protected]>
…ech#4906) Counterpart of: paritytech#4031 cc @paritytech/networking --------- Signed-off-by: Alexandru Vasile <[email protected]> Co-authored-by: Sebastian Kunert <[email protected]>
…ech#4906) Counterpart of: paritytech#4031 cc @paritytech/networking --------- Signed-off-by: Alexandru Vasile <[email protected]> Co-authored-by: Sebastian Kunert <[email protected]>
…ech#4906) Counterpart of: paritytech#4031 cc @paritytech/networking --------- Signed-off-by: Alexandru Vasile <[email protected]> Co-authored-by: Sebastian Kunert <[email protected]>
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:
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:
This is a followup of:
Testing Done
cc @paritytech/networking