Piggybacking on slow messages

Description of the attack

The IOTA Congestion Control Algorithm (ICCA) is built in such a way that messages issued by honest users experience similar delay, defined as the time needed for this message to be delivered to all nodes. For the sake of simplicity, in our simulations we classified nodes in three categories:

  • Content nodes, which generate messages at a rate proportional to their share of access Mana;
  • Best-effort nodes, which generate messages as fast as rate setting module allows;
  • Malicious nodes, which generate messages as fast as possible without following the protocol.

From simulations, we notice that best-effort nodes set an upper bound on the expected delay. This is because such nodes continuously “waste” their deficit, hence they have to wait some time before the next message can be scheduled. On the other hand, content nodes issue messages only when their deficit is large enough. Finally, messages issued by attackers are stuck in honest nodes’ queues and not scheduled in a short time. The interaction of scheduler and rate setter is described in previous articles.

While attackers are blacklisted when they issue a large number of messages, it may happen that honest nodes are unlucky and attach their messages to some malicious node’s message. Since messages are gossiped only when their parents are, attaching to messages with large delays also increases the delay of the child message.

Experimental results

Our claim is also validated through simulations.

The scenario presented in the figure above shows an attacker with low mana issuing different streams of messages to different neighbors. We see that its neighbors (orange arrow) are slowing down because they are more likely to append their messages to the attacker’s ones.

Countermeasures

The idea is to “promote” messages which have already been approved, that is, in other words, have already been started building their approval weight. In this proposal, the way the scheduler increases the deficit is different whether a message in the outbox is a tip or has already been validated. In the former case, we proceed as usual by increasing the deficit proportionally to the access Mana of the issuing node; in the latter case, we propose two options:

  • Boost based on approver(s)’s message priority. The parent message is scheduled either when it gets enough deficit or when any of its children is ready to be scheduled.
  • Boost based on approver(s)’s access Mana. In this scenario, the deficit of the parent node is increased by the sum of its access Mana plus the access Mana of the approver(s).

To evaluate the validity of this proposal, we need to consider the following three things:

  • How this approach affects fairness. In fact, we are providing additional throughput to attackers, which is not fair. However, since this approach is relevant only for attacks performed by low mana nodes, we can assume that the additional throughput gained is negligible.

  • It requires a thorough attack analysis to evaluate the introduction of potential new attack vectors.

  • What is the complexity to implement this solution in the node software? The scheduler needs to check the dependencies between child and parent messages in real time. We need to verify the feasibility of this.

What happens if an attacker with reasonable amount of mana first creates a lot of small mana nodes and then performs the attack via those?

Here is an idea:

  • All messages which have been booked go to the scheduler (and are considered “ready”)
  • The total work of a message is the sum of the work of the message, and the work of the messages in its past cone which have not been scheduled (can this be easily computed?)?
  • When we schedule a message, we schedule its past cone
    So, when a message has lots of messages in its future cone, it becomes increasingly likely that one of them will be scheduled.

Let me see if I understood correctly. You are basically proposing the first option (Boost based on approver’s priority) where the work to schedule any child message is equal to its work plus the work of any unscheduled message in its past cone.

Exactly! Maybe it was the same exact idea. Also I think I quoted the wrong bullet point.

I guess the attack is amplified.

In the proposal the work of the children messages remained the same. I think your proposal makes more sense (I guess it’s fairer) but it may be a bit complicated to implement as you have noticed.