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.