Securing GNUnet MQTT against topic flooding

⚠️ WARNING ⚠️

The information presented here might be obsolete!

Scalability

In the current REGEXP based implementation, a peer has to send n messages if we wants to publish on a topic with n subscribers.

Advantages

• It will be hard to compromise a topic with millions of subscribers because a lot of bandwith will be required
• Load on the network is little because only subscribed peers will be addressed directly. Other peers that also run the GNUnet-MQTT service but do not subscribe to the topic will not be bothered

Disadvantages

• It is hard for a single client to reach a large number of people
• Topics with few subscribers can be easily spammed
• Faster uplink and stronger machines will make this attack more severe in the future

Questions

• It is unclear how much power/bandwith is required to do some real damage on a popular topic

Message control for topics

Option 1. Pre-Shared Secret Topic

Idea: Make it hard to find the topic that people are communicating. For some cases like a shared message exchange for a group of coworkers one could try to generate a Topic name which is hard to guess (e.g. sufficiently large random sequence of characters) and use this as a "pre-shared" key so that only authorized peers know the topic.

Advantages

• No complex message flow

Disadvantages

• This is not a real message control but should also do the job.

Option 2. Authorized transmissions

Here the idea is the following: Publishing to a subscriber is only possible if the publisher is in possession of a token issued by the subscriber. Otherwise the subscriber will deny the reception.

1. A peer uses the REGEXP to get a list of subscribers
2. If he wants to send a messages to a subscriber he checks his current cache if he has a session token for that subscriber
3. If he has, he sends the message to subscriber and is done
4. If he does not have a session token he sends a "Token Request" to the subscriber
5. The subscriber can now according to his policy either send him a token directly (e.g. for known, trusted peers) or request a proof of work from the publisher 1. Whitelist only 1. Do the proof of work if I don't know you 1. I accept anyone on this topic
6. Once the publisher has received the request he can either do the work or skip the transmission to that subscriber
7. If he decides to do the proof of work he obtains the token and can send messages to the subscriber for as long as the token is valid

Advantages

• If there is something like a firewall that allows to deny reception of messages from untrusted peers in the network this method can save a lot of network bandwith
• It could also work for topics with many subscribers (e.g. the New York Times wants to send some news to millions of people)

Disadvantages

• Proof of work could be infeasible for constrained device like sensors. Unfortunately sensors are one of the main applications of M2M

Questions

• Is there such a "firewall" in GNUnet?
  • See https://github.com/vsaw/gnunet-mqtt/wiki/Random-Pieces-of-Knowledge#how-to-filter-incoming-gnunet_mesh-connections-aka-channels