Toward Collusion-Robust Link-State Routing in Open Networks

Transcription

1 UNIVERSITY OF CALIFORNIA, RIVERSIDE TECH REPORT - J. ERIKSSON, M. FALOUTSOS, S. KRISHNAMURTHY Toward Collusion-Robust Link-State Routing in Open Networks Jakob Eriksson, Michalis Faloutsos, Srikanth Krishnamurthy University of California, Riverside jeriksson,michalis,krish@cs.ucr.edu Abstract Open, self-organized networks present a formidable routing security challenge. When strangers are allowed to join the network as full citizens rather than just guests with limited privileges, new security paradigms must be adopted. Instead of making use of manual configuration phases or online certification authorities, we must rely on the routing layer to be robust against all manner of attacks, possibly mounted by powerful adversaries. With the explicit purpose of supporting byzantine secure routing in open multi-hop wireless networks, we propose a novel routing protocol design. The key components of our approach are the following: (a) we use link state information as the basis for routing, (b) we use asymmetric cryptography to authenticate link-state updates, limiting attackers to announcing fake links incident on themselves, (c) we develop a randomized feedback-based path generation algorithm to detect and route around attackers. We demonstrate that our protocol performs well under several attacks which are not handled by previous secure routing protocols. An interesting effect of our algorithm is that overly aggressive attacks are easier to detect and isolate. Thus, attackers are forced to: (a) let some traffic through, and (b) limit the number of potentially falsified links they announce. Otherwise, their negative effect in the network is reduced. This effectively limits the efficacy of any attack to a fraction of what would otherwise be possible. I. INTRODUCTION A denial of service attack at the routing layer can be highly disruptive in an unprotected network. Depending on the routing protocol used, a single attacker may be able to disrupt routing throughout the entire network by distributing falsified routing information. Previous work has largely approached the problem of secure routing by adding security features (read: encryption) to existing routing protocols. We propose a novel byzantine secure routing protocol design, using linkstate dissemination and randomized path generation, developed explicitly to provide routing robustness against strong colluding adversaries. Open networks pose many challenging security problems: anyone is welcome to join in without any credentials other than possession of the necessary equipment. Examples of such networks are fixed wired/wireless community networks without central administration, and emergency response networks, where multiple organizations collaborate to form a network at the location of a major catastrophe. In such networks, one cannot assume that any given node is trustworthy, nor can one afford to shut nodes out of the network simply because one cannot trust them. Moreover, no traditional network administrator exists that is able to pinpoint problems and address them through manual intervention. Instead, all nodes are allowed to participate, and we must rely on a robust routing protocol to operate reliably despite interference from unintentional misconfiguration as well as intentional sabotage from large numbers of colluding malicious nodes. A large body of work already exists in the area of secure routing, for example [1] [7]. However, much of the previous work does not apply to open networks, but instead focus on providing a secure environment for insider nodes with respect to attacking outsiders. Some of the previous work applies to open networks. In particular, in [7], the authors address the issue of open networks directly, and proposes an on-demand routing protocol with provisions for finding bad links in non-working paths, and using this information to guide subsequent route requests. Unfortunately, ODBSR is vulnerable to colluding attackers, as we will describe in more detail in the next section. We propose a novel routing protocol design to enable byzantine secure routing in open multi-hop wireless networks. Our only requirement is the existence of public keys: we assume that each node is given a signed public key at the time of manufacture. The key characteristics of our protocol are the following. First, we use global link state information as the bases for routing. The reason for preferring link state is that link state updates are signed by the originators of the updates, and broadcast across the network unmodified. This way we limit the extent of potential fake link advertisements: attackers can only advertise links that have at least one attacker as end-point. The other key characteristic of our approach is the use of randomized path generation. Given the link-state graph, the sender of a packet generates a path to the destination using a small set of rules and a random number generator. The success or failure of a path is recorded, and used to guide the future generation of paths. The main advantage of random path generation is that it is immune to many of the attacks that can be mounted against deterministic path computation. We demonstrate through simulation that random-path routing can quickly find working as well as efficient paths, even in large networks under heavy assault (up to 500 good nodes and 150 attackers). Our work in perspective. We wish to emphasize that this is early work, with focus on a hard problem and a novel general solution. We describe our idea, and show through simulation that it holds a lot of promise for future protocols. By no means do we claim to have a complete protocol, or indeed a complete evaluation of the current protocol. However, as far

2 UNIVERSITY OF CALIFORNIA, RIVERSIDE TECH REPORT - J. ERIKSSON, M. FALOUTSOS, S. KRISHNAMURTHY as we have been able to tell, randomized path generation is the only solution so far that fully addresses the problem of selforganizing routing in open networks, in the face of powerful colluding attackers. The remainder of this paper is structured as follows. In section II we provide additional background and motivation for our work. In section III, we give a brief overview of the problems we face, and the general approach taken to address these problems. In section IV, we discuss the details of how a maximally reliable link-state graph can be computed in the face of adversaries. In section V we describe our approach to random path generation in the face of polluted link-state graphs. In section VI we evaluate the high-level performance of the protocol through analysis as well as simulation. Finally, in section VII we conclude the paper. II. MOTIVATION AND BACKGROUND Routing in self-organizing wireless networks has been studied extensively, for example [8] [13]. However, routing under malicious attack, especially in the case of colluding attackers, is still largely an open problem. There exists a large number of attacks that can be mounted against the routing layer. Here, we only consider attacks that results in a performance degradation compared to if the attacking node was not active at the time. One typical attack is the black hole attack, in which a node announces routes to some or all destinations, but drops any data packets it receives. A related attack is the grey hole attack, which drops some, but not all packets, and the jellyfish attack, which disguises itself as randomly occurring failures rather than purposeful malicious attack. Some protocols are vulnerable to the wormhole attack, in which colluding attackers tunnel packets to make it appear as if a link exists between them. In the sybil attack, an attacker masquerades as one or more other nodes in order to force more paths to go through it. The power of the sybil attack can be lessened by requiring nodes to authenticate their packets with keys signed by a trusted off-line authority. However, in the case of multiple colluding attackers, these can share keys and thus potentially increase the power of their attack by the square of the number of attackers. An assumption that appears in several paper is that of tamper-proof hardware, where adversaries cannot masquerade as other nodes. While this is a convenient assumption, we do not depend on tamper proof hardware in this work. Most of the work on secure routing in ad hoc wireless networks has been done on reactive routing protocols. ARAN [1] uses cryptography to protect the communication between a set of trusted nodes from attacks by outsiders. However, it does not adequately address compromised insider nodes. ARIADNE [3] uses one-way hash chains to ensure that the route setup phase cannot be tampered with. SPR [4] makes less aggressive use of cryptography, and only requires connection end-points to have security associations. In common for all the schemes above is that they are not able to handle colluding nodes, and deal with a limited range of attacks. In particular, the black hole attack and its relatives are not adequately addressed. A somewhat more heavyweight protocol, ODBSR [7], uses cryptographic techniques to authenticate each node along an on-demand discovered route. If a path does not work as expected, ODBSR tracks down the faulty link using a fault detection technique that involves signed acknowledgments from intermediate nodes. A link weight list in each route request ensures that the faulty link is not included in subsequent path attempts. Unfortunately, ODBSR is susceptible to three powerful attacks by colluding nodes. The sybil attack, where colluding attackers may share their private keys and thus be able to appear as multiple nodes in each location. Also, the wormhole attack, where colluding attackers may create a large number of fictitious links, all of which must be identified as bad before the protocol succeeds. Using a combination of these two attacks, colluding attackers with nodes close to both source and destination may be able to postpone a successful route establishment for a long time. In fact, the number of ODBSR route request floods necessary to find a working path in this situation is proportional to the square of the number of attacker nodes. Finally, in a blackmail attack, a pair of colluding attackers on a path between source and destination are able to incriminate a link on the path between them, by selectively dropping acknowledgments and packets. By blackmailing the critical/bottleneck nodes, attackers may be able to partition the network. Most reactive routing protocols are vulnerable to the wormhole attack. In [14], countermeasures against the wormhole attack are presented. However, these techniques make strong assumptions about synchronization or geometric relationships that may not apply in most network scenarios. In [15], Distributed Reinforcement Learning is employed to guarantee that a near-optimal route is found. The authors assume a very strong adversary, and claim that if a nonadversarial path exists, their algorithm will eventually find it. This paper does present an interesting alternative approach to secure routing. However, the authors do not address convergence time, which could be an issue with a reinforcement learning based approach. There has also been some work on security in proactive ad hoc routing protocols. SEAD [2] makes use of one-way hash chains to protect the integrity of distance metrics and sequence numbers of a DSDV-like [10] protocol. SEAD is vulnerable to colluding attackers, and does not appear to address the black hole attack. SLSP [6] is a Link State protocol with some security enhancements. It is robust against some attacks from single attackers but cannot handle colluding attackers or the sybil, black hole or wormhole attacks. In SMT [16], the authors assume the existence of multiple paths of varying reliability, and design an end-to-end secure message transmission protocol that exploits these paths to ensure maximum reliability and throughput. The SMT approach is complementary to our work, where SMT handles end-toend message transmission reliability, and our protocol finds the paths that SMT relies on. Pathrater and Watchdog [5] rely on overhearing over the wireless channel to determine whether a neighboring node is forwarding packets correctly, and use this to guide subsequent path selection. Unfortunately, this is not reliable in common

3 UNIVERSITY OF CALIFORNIA, RIVERSIDE TECH REPORT - J. ERIKSSON, M. FALOUTSOS, S. KRISHNAMURTHY network scenarios, such as multirate networks, power-adaptive or directional communication. Moreover, falsely classifying transmission failures as malicious behavior can result in the exclusion of well-behaved nodes, with severe performance degradation or network partition as a result. The standard has built-in security support. However, the purpose of these technologies is to keep strangers out. We are studying open networks where strangers are expected, and welcome, to join the network at any time. Unfortunately, this means that standard security functionality will not be useful for our purposes. Jamming and MAC-layer Denial-of-Service attacks are not explicitly addressed in this paper. However, as long as the effect of these attacks is localized, our protocol will handle links in the affected region as non-existent links, and route around them. There has been a significant amount of work on security in wireline networks, some of which applies to wireless networks as well. In particular, [17] is a pioneering work in secure routing. Perlman describes a secure flooding protocol, and a linkstate routing protocol which are highly resilient to byzantine attacks. This work shares some aspects with Perlman s early efforts. In particular, we use the secure flooding protocol as described in that work. Our proposed protocol stands up well against the attacks mentioned above, yet makes none of the weakening assumptions made by previous work. We allow collusion between adversaries, out-of band communication between adversaries, and large numbers of attacking nodes. We also make no assumptions with respect to tamper-proof hardware, network geometry or means of connectivity. III. OVERVIEW In this section, we present our approach toward a denial-ofservice resistant routing protocol. From a high-level perspective, our protocol is a link-state routing protocol. Link-state routing keeps intermediate nodes out of route computation, which is a great help in securing the protocol. In contrast with distance vector protocols, like DSDV, link-state updates are flooded across the network unmodified. Moreover, since the source node has knowledge of the entire network topology, we can combine link-state routing with source-based routing, allowing the source the freedom to choose any path it wishes 1. A. Scenario As explained in previous sections, we assume that all nodes are strangers, i.e. no previous cryptographic associations or trust relationships exist. Moreover, extremely limited authentication is possible, due to the fact that nodes only have publicly available knowledge in common. In this paper, we concentrate on wireless links, but with the exception of our MAC layer enhancements, we expect our results to apply to wired networks as well. 1 We introduce minor restrictions on this freedom to protect against a weak form of DoS attack We assume that nodes have enough computational power to perform verifications of signatures produced by a public key crypto-system, as well as creating signatures at a rate similar to the rate of link changes. Since signature verification is a much more common event than signature creation, we use keys with a small public exponent, to optimize for this case. Under nonadversarial conditions, our protocol can be made to function similar to OLSR [12], OSPF [18] or any other link-state protocol, but due to the extra computational and transmission overhead incurred by the cryptographic signatures we require, it may not be able to operate as efficiently at high rates of link state change (read: mobility). B. Basic Protocol Let us describe the operation of the protocol without any security features. This follows the typical operation of any link-state routing protocol. When a new neighbor is discovered (either through beaconing or passive monitoring), or when a link is broken or withdrawn, a link-state update message is created. This message contains the identities of the two endpoints of the link, a sequence number generated by the node announcing the link, and the current state of the link. The message is then flooded to all nodes in the network. When a source needs a path to some destination, it uses the linkstate information it has received to compute a path. The full path to the destination is then entered into the packet header before transmission, and intermediate nodes simply forward the packet along the indicated path. C. Security Measures The protocol as described above is vulnerable to numerous attacks. To avoid or increase robustness to such attacks, we introduce a set of security measures. Signed Public/Private Key Pairs - Each node is given a unique public/private key pair, signed by an offline central authority like, for example, the manufacturer of the network card. Public Key as Node Identifier - The public key of each node is used as node identifier. That is, we use the public key as identifier instead of the hardware MAC-address or IPaddress of a node. Signed Link-State Updates - Link-state updates are signed by one (in the case of link outage) or both (in the case of link discovery) end-points of the link in question. This process requires some careful design to avoid a man-in-the middle, or wormhole, attack. We will address this in more detail later. Secure Flooding Protocol - A secure flooding protocol [17] is used to ensure that link-state updates reach all nodes. Bi-Directional Links Only - We require signed link-state updates from both ends of a connection before adding a link to the link-state graph. Signed End-to-End Acknowledgments - Signed end-toend routing layer acknowledgments of each data packet are used, and sent along the reverse-path of the packet being acknowledged. Node Performance Statistics - When a packet acknowledgment is not received before its timeout expires, this is noted

4 UNIVERSITY OF CALIFORNIA, RIVERSIDE TECH REPORT - J. ERIKSSON, M. FALOUTSOS, S. KRISHNAMURTHY in the performance record of each node that is part of the path in question. MAC Layer Security Enhancement - We extend the RTS/CTS exchange in to include a 32-bit nonce in the CTS message. This is used to prevent tunneling attacks. Randomized Path Generation - Finally, as the main contribution of this paper, we propose a randomized method of path computation, which effectively and efficiently finds routes despite the link-state graph pollution and packet drops caused by malfunctioning or misbehaving nodes. D. Attacks and how they are countered We will now go through some known attacks, and show how these are addressed by our protocol. Black Hole - In the black hole attack, an attacker node drops all the payload packets that passes through it. This attack is handled in two ways: first, packets are sent over many different paths. If one path fails, this results in a partial, and temporary, loss of service only. Second, when a path doesn t deliver a packet correctly, the nodes on that path are marked as having lost a packet. This results in them being less likely to be picked for future randomly generated paths. Gray Hole - In the gray hole attack, the attacker drops only some of the payload packets. This attack is more powerful than the black hole attack in that it is more difficult to detect and avoid grey holes. The same mechanisms that handle the black hole attack also handle the grey hole attack, as shown in section VI. Sybil - In the sybil attack, the attacker fabricates MAC-layer packets to appear as more than one node, usually increasing the power of its attack in the process. We address this attack by requiring nodes to have their public key signed by an offline authority. This is merely for the purpose of limiting the number of keys an attacker can acquire: rather than just generating new keys, the attacker is forced to request, or buy keys from the offline authority. The sybil attack is difficult to stop completely in the face of colluding attackers. Attackers may choose to share their key information, and thereby be able masquerade as each other. While we cannot prevent this, we design our randomized path generation algorithm to be robust to this sort of attack, and show in section VI that its effect is limited. Wormhole - The wormhole attack is a concern only for reactive protocols, where the attacker forwards route requests to a point close to the destination using a fast out-of-band connection, thereby gaining an advantage in the route selection phase. Our protocol does not use a route request flood, and an attacker has nothing to gain from forwarding our data packets faster than usual. Black-mail - In reputation based routing, there is always the concern of attacker nodes setting up a situation such that well-behaved nodes get the blame for the misbehavior of attackers. This is a common occurrence in our protocol. However, all nodes on a malfunctioning path get an equal amount of blame, meaning attackers cannot escape the blame for their misbehavior. In addition, due to the randomized nature of our protocol, well-behaved nodes are likely to appear in both working and non-working paths. We calculate node weights in a way that rewards good behavior more than it punishes misbehavior. As long as well-behaved nodes end up on good paths occasionally, their reputation will remain good. Fabricated Link-State Updates - Link-State protocols are vulnerable to attackers fabricating link-state updates and broadcasting these to all the nodes in the network. We require signed updates from both ends of the link before authenticating a link. Thereby, we restrict what links can be fabricated: attackers can fabricate links between themselves. In addition, colluding attackers can masquerade as each other, meaning colluding attackers can also create the impression of links existing between any attacker and any neighbor of any attacker. We cannot prevent attackers from advertising fake links between themselves. Instead, we use a bias in our randomized path generation algorithm to make it unattractive to attackers to fabricate large numbers of links. We show in section VI that attackers have an incentive to keep the number of fabricated links low. Tunneling Attack - Colluding nodes may attempt to tunnel beacon messages to make it appear as if links exist between non-adjacent, non-attacker nodes. In section IV we introduce a MAC-layer security extension that prevents this attack. Dropped Link State Updates - We use a secure broadcasting scheme due to Perlman [17] to ensure that link updates reach all nodes. Replay - Sufficiently large serial number fields in link-state updates make replay attacks on control messages infeasible. Replay attacks on payload packets are a higher-layer concern, and not addressed here. Jellyfish - In the Jellyfish attack, attackers selectively drop a few packets crucial to upper layers. Due to the small volume of dropped packets, they can do this without being detected by security mechanisms in the lower layers. The jellyfish attack is more relevant for transport and application layers, and should in general be addressed there. However, we do partially counter this attack by providing end-to-end payload encryption. E. A Note on Asymmetric Cryptography The use of asymmetric cryptography is strictly limited to link-state updates and session establishment, thereby the computational and transmission overhead incurred is limited. Although our protocol would work with any type of asymmetric cryptography, we encourage the use of elliptic curve cryptography [19], as this can achieve similar cryptographic strength as an RSA cryptography, but with considerably smaller keys. 2 IV. CONSTRUCTING THE LINK STATE GRAPH At the core of any link-state routing protocol lies an algorithm for constructing a link-state graph. In this section, we present a scheme for constructing a link-state graph under adversarial conditions. While a completely reliable link-state graph is not achievable in the face of colluding attackers, we 2 In [19], it is claimed that a 160-bit ECC key has equivalent same computational safety as a 1024-bit RSA key. The difference in computational cost is similar.

5 UNIVERSITY OF CALIFORNIA, RIVERSIDE TECH REPORT - J. ERIKSSON, M. FALOUTSOS, S. KRISHNAMURTHY S 1. RTS R notation description n i nonce generated by node i ID(i) identifier/public key of node i [x] i message signed by node i s private key TABLE I CTS, n R NOTATION USED FOR MAC-LAYER LINK VERIFICATION SUPPORT n S (ID(R), n R, n S ) R Fig. 1. Secure Link Verification. Node S is verifying that a direct link exists to node R. Non-essential transmissions excluded from figure. show how to construct a close approximation, which we use for randomized path generation in the following sections. Constructing the link state graph can be decomposed into two separate components. First, link discovery detects and verifies the existence of a link between two nodes, as well as detecting when a link is lost. After link discovery, signed link-state updates are broadcast by both end-points of the link. Here, link state dissemination ensures that all nodes in the network are aware of the links currently in existence. Attacks on both of these components exist. We describe the attacks, and show how they are countered by our scheme. A. Link Discovery The objective of the link discovery component is to accurately determine the existence of a link between two nodes. Generally, this would be accomplished through the transmission of periodic beacon messages, where the correct reception of one or more beacon message indicates the existence of a unidirectional link from the transmitter to the receiver. However, under adversarial conditions, this is not sufficient. An adversary could, for example, send counterfeit beacon message messages to make nodes believe that non-existent links are really there. We can address this vulnerability by having the sender sign the beacon message before transmission. However, the attacker still has two more attacks in its repertoire. First, in a replay attack, the attacker could store signed beacon messages from other nodes, for the purpose of replaying them later. Second, in a tunneling attack, colluding adversaries could record beacons at one location, exchange recorded messages either in-band or out-of-band, and replay them at the other. These attacks could make nodes believe that links exist between potentially very distant parts of the network. If attackers could fake links between arbitrary pairs of well-behaved nodes in the network, finding a working path in a network under attack would be very challenging indeed. We cannot prevent two colluding adversaries from counterfeiting a link between themselves, as they possess, and may share, all the key information necessary to construct a valid link update message. Nor is it realistic to try to prevent one adversarial node from masquerading as another attacker, as long as the attackers are colluding. However, we will now present a MAC layer technique that prevents the adversary from fabricating link updates concerning links between two non-adversarial nodes. This effectively limits the errors in the link state graph to links that connect to malicious nodes, a crucial characteristic we take advantage of during path selection. B. MAC-layer Support for Link Verification In order to counter a man-in-the-middle / tunneling attack, we introduce a small modification to the MAC layer to allow verification of the existence of a link. Table I lists the notation that will be used in this subsection. As a first step, when a node S hears a beacon message, it doesn t immediately accept this as an authentic message. Instead, it sends a cryptographic challenge to the originator of the beacon message, requesting it to sign a nonce 3 n S generated by S to prove its identity. This prevents the replay attack, since the attacker, not having access to the correct private key, is unable to respond to the challenge. However, an attacker may still mount a tunneling attack by forwarding the challenge to the original sender of the beacon message, and using the response as if it was its own. In order to prevent tunneling in wireless networks, we introduce a cross-layer mechanism as shown in Figure 1. After detecting a new neighbor R, either through hearing a beacon message, or overhearing some other transmission, node S initiates a link-verification exchange. Link verification starts with an RTS/CTS exchange, similar to what is done in IEEE today. However, we introduce a minor modification to the CTS packet. In addition to the standard information, a 32-bit nonce n R is generated by R and included in the CTS. After the RTS/CTS exchange has cleared the way for transmission, S sends a link verification challenge to R. The challenge, n S, is a nonce generated by S. If the challenge is correctly received, n R is passed up to the network layer at node R together with the challenge packet, for use in the challenge response. R responds to the challenge by sending [ID(R), n R, n S ] R. For the response to be valid, n R has to be equal to that in the original CTS message, n S has to be equal to that in the challenge, and the signature must match the ID(R) public key in the response. The key here is the nonce n R. The CTS containing n R is sent after an extremely short time interval (i.e. 16 µs in IEEE ). We will now argue that for an attacker M, adjacent to node S, to mount a successful tunneling attack, it must retrieve n R from the other end of the tunnel, node R, 3 A nonce is a common concept from cryptography. It is a generated random number used to provide uniqueness. Theoretically, the same nonce should never be generated twice.

6 UNIVERSITY OF CALIFORNIA, RIVERSIDE TECH REPORT - J. ERIKSSON, M. FALOUTSOS, S. KRISHNAMURTHY S RTS CTS, n R n S (ID(R), n R, n S ) R M RTS CTS, n R n S (ID(R), n R, n S ) R Fig. 2. Secure Link Verification. Malicious node M is attempting to counterfeit a direct link between S and R. Non-essential transmissions excluded from figure. within this time interval. Let s assume there is a malicious node M in between S and R, as shown in Figure 2. Theorem 1: For any two nodes R, S outside radio range from each other, an attacker M cannot fabricate a link announcement for a link between R and S. Condition: The time interval allowed before a CTS response on one of M s links is less than the time required for M to complete a message exchange on the other link. Proof: First, message 8 (m 8 ) cannot be forged or modified by M due to the cryptographic signatures in use. Therefore, m 7, m 8 must be identical, and be created by node R. In order for node R to create m 7, it must have the correct values of n R and n S. To preserve the value of n S, m 5, m 6 must be identical. Moreover, to preserve the value of n R, m 3, m 4 must be identical. Finally, due to the identical nature of RTS messages, m 1, m 2 are identical. We now know that M is unable to modify any message in the exchange. However, we still have to prove that the transmission order of m 1 m 8 has to remain the same for m 8 to be validated by S. The order of messages 1, 4, 5, 8 is trivially preserved by node S. The same is true for messages 2, 3, 6, 7, where node R enforces the ordering. We know from above that m 3, m 4 have to be identical. Since nonce n R is a random number generated by R, node M cannot send m 4 before receiving m 3. Similarly, M cannot guess nonce n S ahead of time, and so it cannot send m 6 before receiving m 5. Finally, M cannot forge m 8 due to the cryptographic signature, and so it has to receive m 7 before sending m 8. Thus we have proven M can violate neither content, nor order, of messages m 1 through m 8 in the link verification exchange. The link verification exchange described above gives node S proof that it has a direct link to node R. R then executes the same procedure to get its own verification. Finally, both nodes advertise the link as [ID(S), ID(R), ser S,R ] S and [ID(R), ID(S), ser R,S ] R respectively. For a link to be added to the internal link-state graph of a node, authenticated announcements from both end-points of the link are required. R C. Link State Dissemination The objective of the link state dissemination component is to reliably deliver authentic link state updates to all nodes in the network. Authenticity is ensured by verifying the signatures in each link update at every node traversed. For link-state dissemination, we make use of the work presented in the doctoral thesis of Perlman [17]. Specifically, we use the protocol described there for secure flooding under byzantine failures. Since flooding does not involve route computation, an attacker can only attempt to interfere with the actual data transmission. At the network layer, a denial of service attack could be mounted by sending packets at too high a rate, causing the packets of other nodes to be dropped. Perlman solves this problem by reserving buffer space for one packet from each node in the network, on every router, and using cryptographic authentication to ensure that the reserved memory is only used by the node entitled to it. If authentication is not possible at the rate of transmission, an attacker could potentially overwhelm a node by sending link state update packets at a rate so high that the node is unable to authenticate messages fast enough. This is a viable attack. However, its power is limited by the fact that the attacker has to be a neighboring node, and that the result is simply the denial of service at a single node, not the entire network. Simpler attacks at the MAC or PHY layer could be used to achieve similar effects. D. End-to-End Payload Encryption In order to ensure that attacking nodes cannot selectively drop data packets, all payloads are end-to-end encrypted. Note that the use of public key cryptography is not necessary beyond session establishment. To improve performance, a symmetric key is created during session establishment. This key is subsequently used for efficient encryption, decryption, signature and signature verification of data payloads and acknowledgments exchanged between the pair of nodes in question. E. A note on Wired Networks In wired networks, man-in-the-middle, or tunnelling, attacks are less likely to happen due to the common use of physical security around wired links. However, open wired networks are not unheard of. For such scenarios, techniques exist that effectively prevent tunneling attacks, see [20]. All other aspects of the link-state graph construction remains the same for wired networks. V. PATH GENERATION AND NODE WEIGHT MANAGEMENT In this section, we will describe a technique for finding good, working paths in link-state graphs which may be polluted by non-existent links and nodes that, maliciously or erroneously, drop packets. As discussed in the previous section, attackers have the power to add non-existent links to the link-state graph by broadcasting fabricated link-state updates. However, attackers are limited to fabricating updates for links that connect one attacker to any node that is a

7 UNIVERSITY OF CALIFORNIA, RIVERSIDE TECH REPORT - J. ERIKSSON, M. FALOUTSOS, S. KRISHNAMURTHY neighbor of some attacker. To make our protocol robust to such errors in the link-state graph, we introduce mechanisms for generating randomized paths, for monitoring the performance of nodes in the network, and for adapting to the observed performance. Our proposed protocol makes use of source routing. That is, the source computes a path, and writes a representation of the path into the packet header. The packet is then forwarded hop-by-hop along this path. Once the packet arrives at the destination, a signed acknowledgment packet is sent in response. The acknowledgment is forwarded along the reverse path of the packet being acknowledged. Computing routes using a polluted link-state graph requires the use of techniques other than the customary shortestpath computation using Dijkstra s algorithm. We make use of two techniques: first, instead of computing the shortest path, we continuously generate randomized paths to the intended destination. The success or failure of these randomly generated paths influences our node weight management technique, which estimates the performance of every node in the network. For every packet sent along a path, negative reinforcement is applied to all nodes on the path in question, recording the fact that a packet has been sent along the path, which has not yet been acknowledged. When a path succeeds in delivering the packet, a fact proven by the receipt of a signed acknowledgment, positive feedback is applied to all nodes on the path, encouraging our randomized path generation to use theseeu apparently well-behaved nodes in future paths. The result is to spread traffic over a number of paths, not relying on a single path to work correctly, and gradually converging on a set of paths that work well. We will begin by discussing our weight management technique, and then proceed to describe how our randomized paths are generated. A. Node Weight Management We will now discuss how each node maintains a reliability weight for each node in the link state graph. These weights are later used to guide path generation. As described in the previous section, attackers have a limited capability for disrupting the link state graph. They cannot remove, or arbitrarily add edges between non-malicious nodes. However, they do have the power to add edges between any pair of malicious nodes, or between any malicious node and a neighbor of any malicious node. Attackers also have the option of simply dropping any or all data packets that come their way. We observe that these three attacks have something in common: there is always at least one malicious node on the path that dropped the packet. We will exploit the correlation between a node appearing on the path, and a packet being dropped, to gradually identify malicious or simply malfunctioning nodes. The idea behind the node weight management technique is simple. For each received packet, a signed network-layer acknowledgment is sent back along the reverse path. This ensures that the sender knows, with certainty, that the packet arrived at the destination. The success of a path tells the sender that all nodes on the path worked as expected. However, a failed packet delivery says nothing about which node failed. Instead, all the sender knows is that at least one of the nodes on the path failed to do its job. It is unclear what the best formula is for computing the reliability of a node given this limited form of feedback. For the sake of argument, we will start out discussing a weight formula that we do not currently use. We will show why such a formula is not adequate, and then move on to the node weight formula we use in this work. Let us start out with the following, somewhat intuitive, weight of node i: w i = acked i + 1 sent i + 2, (1) The counter variables acked i and sent i are stored in the link-state graph of the sender node. They are never seen by anyone other than the sender. For every packet sent, the value sent i is incremented by one for every node along the selected path. Similarly, for every correctly acknowledged packet, acked i is incremented by one. Since acked i sent i, this equation yields 0 < w i < 1. We will now go over a quick example to illustrate the node weight management process. Initially, i, sent i = 0, acked i = 0 and thus i, w i = 1 2. When the first packet has been sent, but not yet acknowledged, sent i = 1, acked i = 0 and thus w i = 1 3, for all nodes along the selected path. This means that until the first packet has been acknowledged, these nodes will be less likely to be used for the next packet transmission. This is arguably a good policy under adversarial conditions, as it is likely to increase path diversity in the initial stages. However, once the acknowledgment reaches the sender, the new state will be sent i = 1, acked i = 1 and thus w i = 2 3. Over time, as long as some packets make it to the destination, nodes that intentionally drop packets seem bound to end up with lower weights than nodes that reliably forward them. However, since all nodes on a non-working path get the same treatment, the initial policy described by Eq. 1 has a strong tendency to also punish well-behaved nodes. In a network where most paths are non-working, the majority of feedback will be negative. For every packet successfully delivered by a good path, any number of other paths, passing through the same node, may have failed to deliver a packet. This leads to a situation where a good node gets a weight of w good = N and a bad node gets a weight of w bad = N, where N is the number of paths tried. While this this will probably still work in the limit, it does mean that nodes that have not been tried yet will have a much higher weight than a good node that has been tried multiple times. We would like to give positive feedback a stronger impact on the overall weight computation. As an alternative, we propose w i = 1 2 outi, (2) where out i is the number of outstanding packets: packets sent since the last received acknowledgment. The effect of this weight computation is to set the weight of a node to 1 any

8 UNIVERSITY OF CALIFORNIA, RIVERSIDE TECH REPORT - J. ERIKSSON, M. FALOUTSOS, S. KRISHNAMURTHY time a packet is successfully transmitted through this node. Clearly, this opens up an opportunity for a gray hole attack, where an attacker node would drop most, but not all, packets, and rely on the remaining packets to keep its weight high. We study the effectiveness of the gray hole attack in section VI. B. The problem with Deterministic Path Generation A deterministic algorithm can be vulnerable to targeted attacks by determined assailants. For example, we could potentially compute a weighted shortest path with Dijkstra s algorithm, using the weights provided by the weight management technique described above. As discussed earlier, the attacker has the capability to create a large number of links that do not actually exist. This allows the attacker to add links that would appear to be shortcuts through the graph. A deterministic algorithm would invariably choose to use these links, as doing so results in the shortest path. Weight management would gradually reduce the weight of this path, eventually avoiding the bad path entirely. However, using a tunneling technique, the attacker may be able to forward some or all packets across these non-existent links, reducing the efficacy of weight management. Moreover, colluding attackers would likely be able to create a large number of shortcuts, each of which would have to be tried before any of the actual paths can be found. In practice, we have found that a weighted Dijkstra s algorithm works most of the time, although converging to a good path can take a long time. However, we have observed cases where the deterministic algorithm is unable to find a working path, whereas randomized path generation always finds one eventually. C. Randomized Path Generation A randomized algorithm can be more robust to both failures and attacks. Our algorithm for randomized path generation picks paths through the link state graph, given some carefully designed constraints. As is often the case with randomized algorithms, the first path generated may not be very good, but given a small number of attempts, the probability of finding a high-quality path is very high. There are several goals guiding the design of our path generation algorithm. First, we want the path to be truly randomly generated, as this minimizes our susceptibility to manipulation by attackers. Second, attackers have a known capability of making themselves seem extremely well connected in the linkstate graph, and so might be able to increase the likelihood of a randomly generated path passing through them. We want to minimize the effect of this attack. Third, even though we want paths to be randomly generated, we would like to generate good paths, whenever this can be done without jeopardizing the randomness of the paths selected. Finally, we want to be able to guide the randomized path generation by means of node weights, so that once bad nodes have been detected, randomly generated paths are less likely to consist of such nodes. To address the first and fourth goals, each hop of the generated path is selected among the neighbors of the previous hop, using a weighted randomized generation algorithm. Since no path metrics other than actual path performance are used in the path generation process, there are no metrics that an attacker can manipulate to influence path generation (other than perform as a regular node, which is likely not the attacker s intent). To address the second and third goals, we make an observation about the nature of randomly generated paths. Once a node, n, has been considered for inclusion in a path, it makes sense to not consider that node again for that path. If we were to consider n a second time, adding it to the path will always result in an unnecessarily long path, since we could have just gone directly to n when we first considered it. We will call nodes that have already been considered for inclusion considered nodes. To see how this works, consider the network graph in Figure 3. Path generation starts at node S. From node S, there are three potential next hops. Once the first hop has been selected, all three considered nodes marked with gray are disqualified from subsequently appearing in the path. Essentially, each node gets at most a single chance to appear in the path. While we could theoretically allow the considered nodes to appear in the path, this would introduce suboptimal paths. Moreover, allowing considered nodes in the path adds no security benefits: the goal of path generation is to find a path that doesn t contain any attacker nodes. Adding redundant hops to a path does nothing to achieve this goal. As discussed earlier, attackers possess the power to fake links between any two attacker nodes, as well as between any attacker node and any non-attacker neighbor of an attacker node. To see the potential power of this attack, consider a network graph of N nodes, where αn nodes are attackers. Given an average node degree of d, there are 1 dn (3) 2 actual links in this network. However, attackers can fake 1 2 α2 N 2 (4) links between attackers, and another 1 2 α2 dn 2 (5) between attackers and neighbors of attackers. We note that faking links between two attacker nodes is unlikely to give the attacker much of an advantage: once one attacker is in the path, there is usually no need to add additional attackers to it. As α 2 N 1, the number of fake links is the same as the number of authentic links, and with α 2 N > 1, the number of fake links can vastly exceed that of authentic links. The probability of randomly finding a good path in a graph where a fraction 0 λ 1 of the links are bad is approximately (1 λ) h where h is the number of hops. Clearly, if λ is a above a very small fraction, the probability of successfully finding good paths by picking next hops completely at random can become very low, very quickly. Interestingly, disallowing considered nodes in the path effectively addresses this issue. Attacker nodes that fake a large number of links are still very likely to show up in randomly

9 UNIVERSITY OF CALIFORNIA, RIVERSIDE TECH REPORT - J. ERIKSSON, M. FALOUTSOS, S. KRISHNAMURTHY S S D D Fig. 3. Successfully generating a path through a link-state graph. As the path grows, more nodes (gray) end up in the considered list. generated paths. However, once this attacker appears in the path, all of its neighbors will be marked as considered. If the attacker has an artificially high degree, this means that a large number of nodes will be disqualified from appearing in the path. With a sufficiently large number, this will preclude the path finding algorithm from finding a path to the destination, and the process will restart. This leads to an equilibrium state where attacker nodes can only fake up to a certain number of links in the graph before the fake links start working against them. In section VI we demonstrate the existence of this equilibrium through simulation. Below is the high-level algorithm for the randomized generation of a path. This algorithm assumes that the destination node is part of the connected link-state graph. At each step, until the destination is reached, select a new next-hop and append it to the path. If we reach a point where there is no next hop, and we still haven t reached the destination, we restart the process and try again. The considered list contains a list of all nodes that have so far been either considered, or chosen, to be the next hop at some point along the path. The function select one takes a list as argument and returns one element selected at random. fun generate_path(): n := sender path := (), considered := (n) while n!= destination do n := select_one (n.neighbors - considered) if n!= null path := path + (n) considered := considered + n.neighbors else return generate_path () done return path end Without the weight management, it would be sufficient to use the built-in random() function to select an element uniformly at random. Although this strategy would likely find a good path eventually, even under severe adversarial conditions, it would probably take a very long time. To address this, we make use of the node weights w i, to S S D D guide the randomized path generation. The function below selects an element from the list proportional to the value of node.weight. fun select_one ( list ): weight_sum := 0 for node in list do weight_sum := weight_sum + node.weight done i := random() mod weight_sum for node in list do i := i - node.weight if i <= 0 then return node; done end Figure 3 shows an example of randomized path generation in action. Next hops are randomly selected, and nodes are gradually added to the considered list and thereby excluded from further consideration for path membership. VI. PERFORMANCE EVALUATION In this section, we provide simulation results to validate the intuition and analysis provided in previous sections. To perform the experiments, we used our custom built simulation environment. The simulator was built for high-level studies of routing protocols, and does not simulate a MAC layer. Instead, the routing protocol is run on top of a graph, where links have some probability of dropping packets. The graph is generated by randomly placing nodes on a rectangular field, and adding edges between nodes where the nodes are within transmission range from each other. The simulator, in addition to numerical results in the form of logs, also provides visual feedback and allows the researcher to interact with the simulation and study node state details at runtime. In this paper, we focus on path finding performance, rather than payload throughput. To the best of our knowledge, no routing protocol currently in existence was designed to withstand the attacks we describe, in an open network, see section II. Therefore a head-to-head comparison is hard to provide. Instead, we focus on analyzing and describing the functioning of our protocol, leaving throughput comparisons with other protocols for when such protocols become available. A. Length of Randomly Generated Paths To evaluate the quality of randomly generated paths, we ran a set of simulation experiments. In these experiments, there are no adversarial nodes, as we wish to isolate the performance effect of randomized path selection from the security aspects. In these experiments, we used randomly generated topologies of sizes 100, 250 and 500 nodes. Node density was set to approximately 8 nodes per radio range, which ensured that all graphs were connected. We measured the path length between several node pairs which were manually selected. In all cases, these node pairs were chosen at opposite ends of the graph, to maximize the distance between them and so to make fullest use of the selected graph size. Source nodes were allowed up