You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
GossipSub v1.1 introduced a scoring system to avoid, broadly, two kinds of attacks:
DDoS by sending invalid messages
Avoid "black-hole" attacks (when a peer doesn't forward you messages even though he should)
However, the second point is mainly addressed by setting an expected rate of messages on a topic (through a convoluted decaying formula), and punishing peers if we don't get that rate.
It kinds of make sense in a blockchain scenario like eth or filecoin (for which it was designed): we should get 1 block every 12 seconds, no less.
However, in practice, besides being hard to configure, sometimes a block will be missed because the validator is offline, and it doesn't mean our peers are attacking us.
Also, it's unusable on a network with unpredictable traffic, like Waku
For the "invalid messages DDoS", something like #920 seems a lot more promising anyway, as it also takes into account the size of messages
Proposal 1:
Instead of hardcoding the v1.1 scoring mechanism, we could put it behind an interface, where applications could setup their own scoring mechanism instead. Or we could even ship multiple scoring systems, and they could choose one
Proposal 2:
I'm pretty sure we could create an "universal scoring system", that would work in all reasonable scenarios, without requiring complex setup and magic values.
GossipSub already has a "failure recovery" mechanism, which is the IHAVE/IWANT. If our mesh is attacking us, we will retrieve messages through IWANT. Or, we could say, everytime we use IWANT, our mesh failed.
Note that sometimes, a peer will just be faster than our mesh to relay a message, so sending an IWANT doesn't mean we are getting attacked. However, IHAVE/IWANT is supposed to be a lot slower than our mesh (since it runs on a heartbeat, and the IWANT/message dance costs 1 RTT).
So if we are frequently getting messages from peers outside of our mesh, something is wrong.
My intuition for this scoring system would be pretty simple:
If a peer sends us a message first, he gets 10 points. If a peer sends us the message after that, he gets <5 points. (maybe dynamic based on delay?)
This also applies to peers outside of our mesh
We then use something similar to opportunistic grafting to graft peers who have a better score than the one in our mesh
(note: this is quite similar to First Message Deliveries in gossipsub v1.1, and early simulations actually used this)
I'm not sure yet if this score should be per topic or global, feels like it should be per topic (otherwise I can attack you on a topic, play nicely on 3 other topics, and my score will be positive)
You can find some early results here
This would require more simulations of black-hole attacks in different scenarios to make sure this work properly.
But keep in mind that currently, most networks have scoring disabled, so anything will be better than nothing (as long as it doesn't open new attack vectors)
You can simulate a black-hole attacker by returning "Ignore" to the messageValidator (you'll find examples in both the shadow sims and testground)
If this gives good results, we could avoid creating the generic interface, and just replace the scoring with this mechanism. Or this could be one of the implementation of said interface
We should also upstream any findings in the GS specs
The text was updated successfully, but these errors were encountered:
Background
GossipSub v1.1 introduced a scoring system to avoid, broadly, two kinds of attacks:
However, the second point is mainly addressed by setting an expected rate of messages on a topic (through a convoluted decaying formula), and punishing peers if we don't get that rate.
It kinds of make sense in a blockchain scenario like eth or filecoin (for which it was designed): we should get 1 block every 12 seconds, no less.
However, in practice, besides being hard to configure, sometimes a block will be missed because the validator is offline, and it doesn't mean our peers are attacking us.
Also, it's unusable on a network with unpredictable traffic, like Waku
For the "invalid messages DDoS", something like #920 seems a lot more promising anyway, as it also takes into account the size of messages
Proposal 1:
Instead of hardcoding the v1.1 scoring mechanism, we could put it behind an interface, where applications could setup their own scoring mechanism instead. Or we could even ship multiple scoring systems, and they could choose one
Proposal 2:
I'm pretty sure we could create an "universal scoring system", that would work in all reasonable scenarios, without requiring complex setup and magic values.
GossipSub already has a "failure recovery" mechanism, which is the IHAVE/IWANT. If our mesh is attacking us, we will retrieve messages through IWANT. Or, we could say, everytime we use IWANT, our mesh failed.
Note that sometimes, a peer will just be faster than our mesh to relay a message, so sending an IWANT doesn't mean we are getting attacked. However, IHAVE/IWANT is supposed to be a lot slower than our mesh (since it runs on a heartbeat, and the IWANT/message dance costs 1 RTT).
So if we are frequently getting messages from peers outside of our mesh, something is wrong.
My intuition for this scoring system would be pretty simple:
(note: this is quite similar to
First Message Deliveries
in gossipsub v1.1, and early simulations actually used this)I'm not sure yet if this score should be per topic or global, feels like it should be per topic (otherwise I can attack you on a topic, play nicely on 3 other topics, and my score will be positive)
You can find some early results here
This would require more simulations of black-hole attacks in different scenarios to make sure this work properly.
But keep in mind that currently, most networks have scoring disabled, so anything will be better than nothing (as long as it doesn't open new attack vectors)
You can simulate a black-hole attacker by returning "Ignore" to the messageValidator (you'll find examples in both the shadow sims and testground)
If this gives good results, we could avoid creating the generic interface, and just replace the scoring with this mechanism. Or this could be one of the implementation of said interface
We should also upstream any findings in the GS specs
The text was updated successfully, but these errors were encountered: