Floodsub - Denial of Service

[Stebalien]

Given that floodsub isn't widely deployed, I believe it's best to discuss this in the open (more input).

Currently, there are several protocol-level DoS attack vectors against floodsub that we'll need to address before relying on it more widely (note: none of these require botnets or even high-bandwidth internet connections).

Message Silencing

Currently, every message is identified by an (author, seqno) and peers drop all messages with IDs that they've already seen. This means that an attacker could silence messages by sending messages with colliding IDs. Two possible fixes are: (1) having authors sign all messages or (2) identifying messages by a hash of their content.

Traffic Amplification

Currently, an attacker that knows of some well-connected peers subscribed to a target topic could send rapidly send large messages to individual. Each peer will then rebroadcast these messages to all of their peers, thus dramatically amplifying the traffic. Worse, peers can't simply blacklist the attacker because the attacker isn't sending a high volume of traffic to any individual peer. The core problem here is that peers are forwarding traffic from untrusted sources: topic authentication can't be optional.

Traffic Replay

Assuming we had some way to authenticate messages on topics, attackers could still replay old messages to perform the traffic amplification attack by replaying messages older than 30s (the current timeout on our message deduplication cache). That is, they could just store enough old messages such that never have to repeat a message within a 30s window. Unfortunately, simply removing this timeout would lead to memory exhaustion so that's not an option. As far as I can tell, there are a few solutions (not necessarily exclusive):

1. Provide some way to deduplicate messages on a topic using a constant-sized data structure. For example, we could give all messages a total order and store the latest message.
2. Limit the topic to a trusted set of peers. That is, on any given topic, only forward messages received directly from a peer (not forwarded) in the set of peers allowed to broadcast on that topic.
3. Make message expire after 30s (the deduplication timeout).

[film42]

I'm not sure if there is a way to configure the max message size, but without one it's also possible to crash an application with a significantly large rpc message.

[Stebalien]

The max message size is currently 1MB.

[Kubuxu]

Also libp2p will refuse to transfer messages bigger than 2MiB-overhead but it should not be relayed upon.

[Stebalien]

@Kubuxu that shouldn't really make a difference in this case; that's just the max packet size to prevent individual streams from monopolizing on the connection. ReadMsg should loop internally and repeatedly call Read on the stream until it either has a complete message or exceeds the message size limit.

[film42]

Awesome! Glad to hear there's a reasonable default max message size in place. 👌

[keks]

Message Silencing

To me both signing authored messages and addressing messages by their hash seem like a good idea, not only for dealing with duplicates.

Traffic Amplification

I think this will be a problem as long as there is no permission system for authoring messages. Compare this to email: as long as everyone is allowed to send messages, you have spam, and in a system where everyone is a relay this leads to amplification.

Traffic replay

Maybe some fancy data structure might help here. I read about something like a bloom filter variant that has false negatives, but no false positives. Using that to keep track of already sent messages seems like a good idea.

[jvsteiner]

Traffic Amplification

I believe the recent addition of Validators moves in the direction of solving this problem, but I wonder how it would work with different groups of users sending messages to a noisy topic. Say there are two groups of Subscribers to topic foo, all interconnected, but some of them use a strict "must be signed by 'Bob'" policy, while the other group does not enforce this policy. I believe the second group would experience the issue, but the first group, while not propagating invalid messages, would still be subjected to receiving them.

If this is correct, it's hard to see how a universally enforced validation policy could be constructed to avoid this. One idea I had is that evil peers who relay invalid traffic might be dropped by good peers, and IP's could be blacklisted for some time to avoid reconnects.

[Stebalien]

One idea I had is that evil peers who relay invalid traffic might be dropped by good peers, and IP's could be blacklisted for some time to avoid reconnects.

That's exactly what I'd do. Really, I'd like the validator to be encoded in the topic (IMO, the topic should really be CID pointing to an IPLD object describing the topic and how to validate messages on it).

[D4nte]

Traffic Replay

Maybe I am missing something in terms of feature requirements for floodsub..

If you have authentication (signature) and you include a timestamp as part of the message that is being signed (assuming the topic is also signed) then you could simply have node drops messages that are older than X minutes, stopping an attacker to accumulate enough messages for such attack.

[vyzo]

We have authentication now, but there is no timestamp -- that would require clock synchronization.
Maybe we can assume ntp though.

[raulk]

Distributed systems like Ethereum assume NTP, so it wouldn’t be a scandal.

[Stebalien]

libp2p is supposed to work in a disconnected networks... but I can't think of a better solution.

[D4nte]

The time limit can be adjusted accordingly. Event with 10min, you are still stopping an attacker to accumulate more than 10 minute of traffic.
Do you expect the software to work with nodes that are more than 10 min of time difference?

[Stebalien]

Do you expect the software to work with nodes that are more than 10 min of time difference?

The only time-based assumptions we currently have are in IPNS, as far as I know. However, we can probably just make validating timeouts optional so that mostly offline devices can disable it.

Apparently there are some byzantine fault tolerant clock synchronization schemes but I worry a bit about the communication complexity.

[daviddias]

Can we declared this solved as in "The Hardening exists for Gossipsub now (i.e. https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md)"?

[vyzo]

Replay is still an issue, but we rely on the application to fail validation on stale messages.
We can probably close however.

[daviddias]

Closing, reopen if necessary 👌🏽