Simple Waku Relay DoS mitigation

[kaiserd]

This issue is part of SeM secure scaling and tracks the work on (a) simple Waku Relay DoS mitigation technique(s), which are necessary for the scaling Status to 1 mio users.

actions

• specification of simple Waku Relay DoS mitigation
  • idea: only relay messages if signed with key provided by community owner
    • works for 1:1 mapping of community to shard (i.e. pubsub mesh)
  • form: hackmd linked as a comment in this issue
  • this will be part of RFC most likely: New RFC: BCP Waku Simple Scaling #160

more info / related

• Application Defined Message Validation #141
• Improve Waku resilience against flooding attacks #148

[alrevuelta]

Some discussions around this were started here: #148. Linking it here.

[alrevuelta]

Quick summary of our meeting(s), regarding simple DoS mitigation for the current MVP (< 6 months)

DoS protection can be archived at two different levels:

• Protocol level: Preventing relaying invalid messages, disconnecting from malicious peers, avoiding connecting to sybils under the same IP (see collocation factor). However, due to how gossipsub works, all these can help to mitigate the most naive ways of spamming, but can't entirely fix it. So we need to complement this with some information taken from the application level.
• Application level: Also, DoS can't entirely be solved by the application level. Even if end users are protected from spam by just filtering the messages they get (but without fixing spaming on a protocol level), the network (nodes) can end up collapsed. In other words, its not only about not getting spam to the app, its also about not relying on it in the underneath layer (protocol).

So the solution to DoS is a mix of both levels. Some application-level identifiers, that allow us to i) prevent sybils and ii) rate limit existing nodes, and some validation built in at the protocol level that allows us to enforce some rules using the said identifiers.

The main questions are: where are these identities taken from, and how are they used to avoid DoSing the network. The where sets the entry barrier to waku and the how sets nodes requirements in terms on bandwidth.

We currently have 3 ideas on "simple" DoS mitigation techniques. All of them implement message validation in different ways on a gossipsub level, an already exposed interface by libp2p using addValidator, that allows to Accept, Ignore or Reject messages given some criteria. These are the ideas we have, ordered by complexity (low to high). Note that they can be considered incremental steps to reach the latest one.

• (Added afterwards): Rate limiting on peerId: As a previous step before "manual whitelisting" we could require each peerId to sign the message. Then each relay uses that peerId to rate limit (eg x bytes per hour). This ofc doesn't prevents from having sybil attacks, but makes DoS more difficult than currently is. This idea is conceptually the same as "manual whitelisting" where the only difference is that the "identifier" in this case is the peerId. Mixing this with the libp2p collocation factor, we could prevent some spaming, but ofc this doesn't entirely fixes it.
• Manual Whitelisting: Before gossiping each message, we validate that the message is tied to some identifier and otherwise Reject it. We use this identifier to i) rate limit and ii) prevent spam, since we assume that ids in the white list are honest. This would require adding a new field to WakuMessage containing some kind of signature or related field derived by some key material that is shared by the community owner. Con is that we prevent spamming but we limit access to waku, where participants are manually whitelisted by a central entity. Pro is that we prevent spamming and everything is offchain (key sharing to sign valid messages).
• Waku Tokenized Bandwidth (on-chain queries): See this for ongoing work/brainstorming. In short, it does message validation by requiring each message to be signed by an address holding x amount of tokens. Message rate is determined with the amount of tokens the address owns, being ERC20 and stored in Ethereum. If waku bandwidth is capped at 1 Gb/hour, and there are 100 tokens, if you hold 10 you can send messages at a 10% of that rate. Otherwise, you are rate limited (not slashed). Con requires piggybacking on Ethereum and multiple (gas free though) interactions + full nodes or delegating it to 3rd parties like infura. Pro, we prevent spamming but keeping waku permissionless (assuming erc20 tokens tradeable in secondary markets).
• Waku Tokenized Bandwidth (off-chain proofs and light-clients): See this. Tanguy's idea, where the main pros are that we can leverage light clients and proofs, requiring fewer full nodes and leveraging light clients. Cons, it's a bit more complex and after PoS light client are not working yet, so blocked by Ethereum right now + requires a dedicated content topic to share this information.

[rymnc]

Hey @alrevuelta, adding this document(semaphore for community-level message validation) which may be of relevance to this thread.

[LNSD]

Remember that the Message Unique ID ADR also adds a message integrity check to the Waku Relay protocol: waku-org/pm#9

[fryorcraken]

@alrevuelta can this be closed?

[alrevuelta]

@fryorcraken Yes, closing it. The deliverable of this was the opt-in dos protection designed ad-hoc for status (note that its not meant to be used by the waku network)