Spam in Status on the level of Whisper
======================================

What we consider as a successful DDoS attack?
-

At what rate of the traffic our network won't be able to handle it? What kind of resources have to be spent to lower reliability and increase latency noticeably? It is a critical problem if we can prove that it can be done from single laptop.

How much traffic is too much for mobile device? For example, I have 2gb of free traffic per month. For anything beyond that I will have to pay. Is it a critical problem or small inconvinience?

Who can execute those attacks?
-

I tend to think that it is not possible to spam the network from mobile or desktop client in any a way that will have those described effects. So, any solution that we will discuss should take into account that network is spammed by an intentionally written program. And we can expect certain level of creativity.

Discussed solutions:
-

1) Whisper's proof of work

Sending 10mb of traffic with TTL of 20 seconds and PoW 0.2 - cost ~30 seconds of computation using only single core. For 2gb - ~2h. PoW definitely eliminates the possibility that network will spammed at a rate that will decrease its reliability. But it is still possible to make mobile device to download lots of traffic.

2) Rate limiting

Rate limiting can be used to solve both of these problems. There are several concerns about it. Identities in the p2p network are free. And we can expect creation of multiple identities, because of the reason dicussed above. Another concern, to make them useful we need to set limits to quite a low number. Like 10mb per hour.

- Using public IPs as identifiers

It solves the problem of free identities. Public IPs are scarce and will increase resources required to execute an attack. The main concern are multiple devices behind NAT. Any "good" participant can be affected by spammer that accidentally shares same IP. It might be not an issue while Status is not widely addopted.

3) Payments

Using funds for access to the network is a solution for free identities. Those who spam can be blacklisted and "lose" their funds this way. The concern is how requirement to pay for the network will impact adoption.

Proposal for rate limiting implementation
-

Every participant in the network must have a local limit for received traffic. Defined as traffic unit per duration (100mb/hour). It will be splitted between existing peers in a fair way. And, it must be advertisted using separate whisper method.

On the image below you can see peers in the network (this of links as bidirectional, even they are not the graph). A is a regular mobile device. E and F are our whisper "cluster" nodes. B is a spammer.


For A local limit is 20mb/hour. F and E have local limit of 2gb/hour. B defined local limit is 10gb/hour. I am using hours, but i think those should be seconds to make it practically useful.

Rate limits of all links:

E -> A : 10mb/hour. Advertised by A.
A -> E : 100mb/hour. Advertised by E.
F -> E : 1gb/hour. Advertised by E.
E -> F : 1gb/hour. Advertised by F.
B -> E : 1gb/hour. Advertised by E.
E -> B : 1gb/hour. Advertised by B.
F -> B : 1gb/hour. Advertised by B.
B -> F : 1gb/hour. Advertised by F.

If B sends to E more than 1gb/hour it gets disconnected and blacklisted. E must not send to A more than 10mb/hour. Some traffic must be dropped. We could drop traffic from peer B, but it won't be enough because of the next situation. If B sends to F more than 1gb/hour - B will be blacklisted on peer F. But some traffic will go through. What we do with traffic that B -> F -> E that must not be sent to A. Proposed classification methods:
- Traffic that comes from least known peer has lower priority.

Peer that wants to spam the network will rarely be known for long time. Thats an immediate identifier of not-trustworthy peer.
- Traffic without signature has lower priority
- Traffic with same signature that breaks the limit has lower priority

If someone will be using same key for signatures such traffic will be easily identifiable as malicious. I am assuming that chat user can't break limits.
- Traffic to the same topic and breaks the limit has lower priority

Known topics such as Status can be easily spammed. Somewhat hard to understand what is more important, receiving messages in 'Status' channel or not receing tons of useless traffic.

What we will get
-

Mobile devices will almost never receive more than required amount of traffic. In case of intentional spam - some part of useful traffic may not be received by mobile devices.