-
Notifications
You must be signed in to change notification settings - Fork 80
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
QBFT: Mitigate OOM attack by spamming future messages #524
Comments
is this a bug? or more like a security feature? |
On second thought, buffering only a single future round for each peer can negatively affect liveness. Since we might be throwing away valid messages that can cause consensus of earlier rounds. We could strike a balance between liveness and safety by buffering only a "fixed amount of messages per peer", e.g. 100. Buffering max 100 messages per peer should provide ample future message buffering to ensure optimal liveness in 99.9% of valid cases. And it will ensure that OOM is not possible. 100 msgs/peer == 25 rounds (4 messages per peer per round). We could also make this configurable by adding |
@corverroos but what is the eviction rule? the oldest are evicted? what if we retain the last X rounds? I think that would be easier if we keep the messages in a map[dedupKey]Msg instead of []msg |
Actually, I think we can remove the current So maybe buffer can be |
something like this ^^. Feels like it actually simplifies the algo...? |
Refactors buffering to FIFO per peer to prevent DDoS of future round messages. category: refactor ticket: #524
you mean with key as process? I think it is better than before |
Problem to be solved
The current implementation of QBFT buffers all future messages of all peers. This can be attacked by sending an "infinite" number of valid future round messages, resulting in OOM.
Proposed solution
highestRound map[process]round
for each peer.The text was updated successfully, but these errors were encountered: