every tampered NetworkView sent out, one NetworkView will be returned and the consumed bandwidth is the same on both nodes.
The only way for a malicious node to cause honest nodes to change their neighbour- hood is by sending them better neighbours. They would become pending neighbours on the honest node and it would try to connect to them. There is no way for an attacker to just create identities of nodes that are better neighbours for an honest node. Node identities are only created by the certification authority. However, an attacker could store the identities of nodes that have been in the network before. It could select the identities of nodes that would be better neighbours currently and put them in a NetworkView. The honest receiver would try to connect to all of these nodes. Until the connection attempts fail, it would not send out any NetworkViews and it would not be able to receive routed messages as discussed in section 4.7. Therefore, a malicious node can temporarily influence the processing of messages in the network and timed right might be able to influence the outcome of storage queries. The only way to deal with this misbehaviour is trying to detect it. It would theoretically be possible for honest nodes to blacklist the non-existent node reported by the attacker so they would not try to connect to it for a certain time and the network stays stable. However, this mechanism could be exploited by an attacker to prevent other nodes from joining the network for a certain time. Therefore, if an honest node keeps receiving NetworkViews with non-existing nodes from some other node, it concludes that node is trying to tamper and its NetworkViews should be ignored at least for some time and this misbehaviour will be reported.
Finally, the influence gained this way is just slightly bigger than the influence gained directly modifying the results of queries received by malicious nodes as can be seen in section 5.5.
4.4 Bootstrapping and Join
With the self-stabilizing maintenance procedure, a joining node a connects to the bootstrapper node it received from the bootstrapping service assuming it is a neigh- bour. The bootstrapper will answer with a NetworkView and a will pick better neighbours from this NetworkView. This procedure is repeated and a connects to better neighbours until it cannot improve its neighbourhood. In the worst case, a is located in the lower right corner of the key space and its bootstrapper is in the upper right. Then a has to connect and exchange NetworkViews with all nodes in a
68 Chapter 4 A Self-Stabilizing Delaunay Overlay
a b
Figure 4.12: Corridor of nodes contacted by joining nodea with bootstrapper b
corridor around the diagonal through the key space from upper left to lower right, while it gradually gets closer to its correct neighbours, see figure 4.12. In the worst case, O(√n) messages have to be exchanged for just one node joining. Furthermore,
the more nodes involved in a join process, the more likely a constellation of malicious nodes is able to eclipse the joining node.
Therefore, we use an alternate join process first bringing a close to its correct neigh- bours in O(log n) steps before starting the self-stabilizing maintenance to integrate
a. Instead of sending a NetworkView to its bootstrapper b, a sends a special JoinRe- quest. The destination of the message is a’s own position. This means the message
will be received by the node c currently responsible for the position of a after O(log n) hops, see figure 4.13. This node c will definitely become a neighbour of a as no other node is closer. Node c will reply to the JoinRequest with a NetworkView, starting the self-stabilizing integration of a. As a’s new neighbours will be from c’s one- and two-hop neighbourhood, the number of nodes involved depends on the node degree (the number of neighbours). Although the node degree is only bounded by
n− 1 for special cases like a star topology, the average node degree in a random
Delaunay graph is a constant, see section 6. Thus, only a constant number of nodes are involved in this part of the joining process.
However, this procedure is more vulnerable than the self-stabilizing procedure. In the latter, a joining node is only eclipsed if the bootstrapper is malicious or malicious nodes have a special constellation in the join corridor, see section 4.3.6. Since the JoinRequest is routed on a single path, just one node on the path is enough to eclipse
4.4 Bootstrapping and Join 69
a b
a
Figure 4.13: JoinRequest path from bootstrapperb to nodes involved in the join of a
a joining node. Therefore, we use multiple redundant join paths. An attacker would need a malicious node on all of the r join paths to successfully eclipse a node. To realize these r redundant join paths, the bootstrapping service has to supply r bootstrapping nodes to a joining node. The choice of supplied nodes is a critical one. At any time, the bootstrapping service will know a subset of nodes in the network serving as bootstrapping nodes. From this subset, it will make a selection of r nodes it will supply to a bootstrapping node. This selection process must fulfil the same requirement the overlay hast to fulfil: the share of malicious nodes supplied by the bootstrapping service must not be greater than the share of malicious nodes in the whole network. If the bootstrapping service is compromised and malicious nodes are delivered as bootstrapping nodes much more often, this will extend to the overlay. If it only supplies malicious nodes, every joining node will be eclipsed from the start. Therefore, a suitable bootstrapping service should effectively make a random selection from the nodes in the overlay.
Ideally, the paths taken by the JoinRequests sent to the r bootstrappers are com- pletely disjoint. This way an attacker would need one malicious one each of the r paths. However, as all JoinRequests have the same destination, the join paths will converge at the destination. Even worse, the last node to receive the message is the same – the closest node to the destination. This means if the last node happens to be malicious, the joining node will be eclipsed despite the r paths. Therefore JoinRequests are routed slightly differently. A JoinRequest will be received by any
70 Chapter 4 A Self-Stabilizing Delaunay Overlay
node who would become a neighbour of the joining node. If messages are routed towards the destination from different directions, they will end up on different nodes and the paths will most likely be disjoint. However, this cannot be guaranteed. Therefore, we additionally take advantage of a mechanism developed to initially fill the routing table generating disjoint paths with a high probability, see section 4.5.5. This makes it hard for an attacker to prevent the JoinRequests from reaching their correct destination.
Finally, there is a second mechanism making eclipsing of nodes while joining ex- tremely unlikely. It takes advantage of the special structure of the routing table as a result of the way its maintenance is performed (see the next section 4.5) and the fact that nodes perform a special storage query after joining the overlay (see section 5.4 and the resilience discussion in section 5.5.3).
It is important to note that initially, when the overlay is started for the first time, no malicious nodes should be present. If the very first node is already malicious, all following nodes have no chances to create a correct overlay. All of them will be eclipsed. Therefore, the operator has to supply some nodes known to be trustworthy until a critical mass of honest nodes has been reached.