Network Working Group Y. Mao Internet-Draft V. Narayanan Intended status: Informational A. Swaminathan Expires: September 5, 2009 Qualcomm, Inc. March 4, 2009 Threat Analysis for Peer-to-Peer Overlay Networks draft-mao-p2psip-threat-analysis-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 5, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this Mao, et al. Expires September 5, 2009 [Page 1] Internet-Draft P2P-threat-analysis March 2009 material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Abstract This document provides a threat analysis for peer-to-peer networks, where the system relies on each individual peer to route message, store data, and provide services. The threats against P2P network include those that target individual peers, those that target routing protocol, those that target identity management, and those that target stored data. Focusing on distributed hash table based P2P network, we first establish a threat model and perform a triage of various assets in a P2P system. We then describe each individual threat in details, including threat description, impact of attack, and possible mitigations. The threats and mitigations are discussed under the context of feasibility and practicality, with the ultimate goal of achieving better understanding of the threats for secure P2P system design. Mao, et al. Expires September 5, 2009 [Page 2] Internet-Draft P2P-threat-analysis March 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Centrally Managed vs Distributed P2P Network . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Basic Security Principles for Peer-to-Peer Networks . . . . . 6 3.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. The Importance of Detecting Attacks . . . . . . . . . . . 7 4. Peer-to-Peer Network Asset Classes . . . . . . . . . . . . . . 7 4.1. Critical Assets . . . . . . . . . . . . . . . . . . . . . 7 4.2. Non-Critical Assets . . . . . . . . . . . . . . . . . . . 8 5. Attacker's Goals and Motivations . . . . . . . . . . . . . . . 9 6. Threats Against P2P Networks . . . . . . . . . . . . . . . . . 9 6.1. Threat 1: False Claim to Owned Resource ID . . . . . . . . 10 6.1.1. Threat Description . . . . . . . . . . . . . . . . . . 10 6.1.2. Attack Method and Difficulty . . . . . . . . . . . . . 10 6.1.3. Attack Impact . . . . . . . . . . . . . . . . . . . . 11 6.1.4. Mitigations . . . . . . . . . . . . . . . . . . . . . 12 6.2. Threat 2: Abuse Bootstrapping Process . . . . . . . . . . 12 6.2.1. Threat Description . . . . . . . . . . . . . . . . . . 12 6.2.2. Attack Method and Difficulty . . . . . . . . . . . . . 13 6.2.3. Attack Impact . . . . . . . . . . . . . . . . . . . . 13 6.2.4. Mitigations . . . . . . . . . . . . . . . . . . . . . 13 6.3. Threat 3: Abuse Routing Update . . . . . . . . . . . . . . 14 6.3.1. Threat Description . . . . . . . . . . . . . . . . . . 14 6.3.2. Attack Method and Difficulty . . . . . . . . . . . . . 14 6.3.3. Attack Impact . . . . . . . . . . . . . . . . . . . . 14 6.3.4. Mitigations . . . . . . . . . . . . . . . . . . . . . 15 6.4. Threat 4: Targeted Node ID Generation . . . . . . . . . . 15 6.4.1. Threat Description . . . . . . . . . . . . . . . . . . 15 6.4.2. Attack Method and Difficulty . . . . . . . . . . . . . 15 6.4.3. Attack Impact . . . . . . . . . . . . . . . . . . . . 16 6.4.4. Mitigations . . . . . . . . . . . . . . . . . . . . . 16 6.5. Threat 5: Sybil Attack . . . . . . . . . . . . . . . . . . 16 6.5.1. Threat Description . . . . . . . . . . . . . . . . . . 16 6.5.2. Attack Method and Difficulty . . . . . . . . . . . . . 17 6.5.3. Attack Impact . . . . . . . . . . . . . . . . . . . . 17 6.5.4. Mitigations . . . . . . . . . . . . . . . . . . . . . 17 6.6. Threat 6: Eclipse Attack . . . . . . . . . . . . . . . . . 17 6.6.1. Threat Description . . . . . . . . . . . . . . . . . . 17 6.6.2. Attack Method and Difficulty . . . . . . . . . . . . . 18 6.6.3. Attack Impact . . . . . . . . . . . . . . . . . . . . 18 6.6.4. Mitigations . . . . . . . . . . . . . . . . . . . . . 18 6.7. Threat 7: Lack of Practical Reputation System . . . . . . 19 6.7.1. Threat Description . . . . . . . . . . . . . . . . . . 19 6.7.2. Existing Proposals . . . . . . . . . . . . . . . . . . 19 6.8. Threat 8: Free Riding and Whitewashing . . . . . . . . . . 20 6.8.1. Threat Description . . . . . . . . . . . . . . . . . . 20 Mao, et al. Expires September 5, 2009 [Page 3] Internet-Draft P2P-threat-analysis March 2009 6.8.2. Attack Impact . . . . . . . . . . . . . . . . . . . . 20 6.8.3. Mitigations . . . . . . . . . . . . . . . . . . . . . 21 6.9. Threat 9: Replay and Rollback . . . . . . . . . . . . . . 21 6.9.1. Threat Description . . . . . . . . . . . . . . . . . . 21 6.9.2. Attack Impact . . . . . . . . . . . . . . . . . . . . 21 6.9.3. Mitigations . . . . . . . . . . . . . . . . . . . . . 21 6.10. Threat 10: Data Corruption . . . . . . . . . . . . . . . . 22 6.10.1. Threat Description . . . . . . . . . . . . . . . . . . 22 6.10.2. Attack Impact . . . . . . . . . . . . . . . . . . . . 22 6.10.3. Mitigations . . . . . . . . . . . . . . . . . . . . . 23 6.11. Threat 11: Software Vulnerabilities . . . . . . . . . . . 23 6.11.1. Threat Description . . . . . . . . . . . . . . . . . . 23 6.11.2. Mitigations . . . . . . . . . . . . . . . . . . . . . 24 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.1. Normative References . . . . . . . . . . . . . . . . . . . 24 7.2. Informative References . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Mao, et al. Expires September 5, 2009 [Page 4] Internet-Draft P2P-threat-analysis March 2009 1. Introduction A peer-to-peer network is the organization of a collection of nodes, with routing capabilities to each other built upon some form of physical communication links. A peer-to-peer network typically provide storage, retrieval, and other services to the applications that are built on top of it. Often times, the P2P network will rely on some other form of transport networks, such as IP network, for connectivity from one node to another. The P2P layer on the protocol stack can thus be viewed as a "middleware" layer between the transport layer and the applications. This document provides a threat analysis of P2P networks. Robustness, scalability, reliability, and high availability to the applications are some of the design goals for P2P networks. For example, for a well-designed P2P network, as the network gains popularity and the amount of content increases, the network can leverage the computation, storage and network resources of its peers to keep scaling up without degradation of service. It is therefore very important to maintain the functionality of each individual peer for the functionality of the network. 1.1. Centrally Managed vs Distributed P2P Network Some early forms of P2P file distribution systems have a central entity to manage the whereabouts of the file contents. For example, Napster used a centralized index for discovery. But the actual transfers of files are performed directly between the machines. Distributed P2P network designs find a way to store and search file contents and other services among the peers, thus reducing the reliance on a central server. However, central servers may still be necessary to maintain certain security features. For example, the recent RELOAD design by the P2PSIP working group uses a centralized enrollment server to assign each peer a node id during the node join process. The main concern here is not scalability (since each peer essentially enrolls only once), but the trustworthiness of the node id when it is used to contact other nodes. In such cases, using a central identity distributor and certifier will provide a root of trust to every peer in the network, while the validation of the identity can be conducted in a distributed fashion using public key cryptography. In this document, we will mainly focus on distributed P2P network with a central server for peer admission, identity provision, and bootstrapping during a node join. Our analysis will mostly cover distributed hash table based structured overlay. Distributed hash table (DHT) provides a mapping from the overlay identity and content identity (e.g. a string) to an address, typically a binary value of Mao, et al. Expires September 5, 2009 [Page 5] Internet-Draft P2P-threat-analysis March 2009 length k bits. In doing so the address space of overlay nodes becomes identical to those of files, resources, services, etc. A number of P2P routing protocols have been proposed based on the DHT design concept, such as CAN, Chord, Tapestry, Pastry, etc. Because of the use of DHT, each peer maintains its own overlay-layer routing table in the P2P network. The routing table consists of the id of its connected peers and the underlining network address (such as IP address) for the connections. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. 3. Basic Security Principles for Peer-to-Peer Networks There are two security related goals we want to achieve for a P2P network: (1) An overlay node should function correctly (either in terms of providing or receiving services, or routing overlay messages, etc.) in spite of the compromise and disruption of other overlay peers, or the attempted disruption of its normal functionality by other peers. (2) The entire overlay as a system, should continue to serve its designed functionality even with a small fraction of compromised or corrupted peers in the P2P network, or non-critical attacks against overlay entities. 3.1. Threat Model We use the Byzantine fault model in our analysis. Since overlay communications mostly use IP network, we consider the internet threat model applicable to the P2P overlay security. The internet threat model assumes that critical assets are not compromised, while the attacker may obtain full control of the communication channel or attack non-critical assets. The communication links can be eavesdropped (passive attack), data may be modified or simply dropped (active attack). We will identify two asset classes in the P2P network, critical assets and non-critical assets. Mao, et al. Expires September 5, 2009 [Page 6] Internet-Draft P2P-threat-analysis March 2009 3.2. The Importance of Detecting Attacks The importance of detecting an attack in an early stage should not be overlooked, as it is the first step towards discovering and mitigating the problem. Attacks can be detected through cryptographic means, such as verifying a signature or hash, or they can be detected simply by comparing and validating event notifications sent by other peers. This analysis does not focus on attack detection since there are a large number of works on sophisticated attack detection algorithms. But whenever a simple detection method can be used, we will provide a brief description along with the threat analysis. 4. Peer-to-Peer Network Asset Classes Assets in a P2P network may be classified into the following categories. A critical asset is the one whose failure or compromise leads to either a failed peer or a failed operation for the entire P2P network. Some assets may be critical to an individual peer, such as the P2P middleware instance, but may not be critical to the entire P2P system as a whole. We will differentiate in what sense an asset is critical in subsequent analysis. A non-critical asset is one whose failure or compromise may cause a temporary disruption to an individual node, or a small fraction of misbehavior in the overlay. But in general, an individual peer or the P2P network can still be operational despite the failure or compromise of these assets. One example is a particular entry in a peer's routing table. If only this entry is corrupted, the peer loses direct routing information to that particular peer. However, the host peer can still reach most other peers and potentially get to that particular peer via overlay routing. 4.1. Critical Assets o Enrollment and credential servers: This asset is critical to both the P2P system and to individual peers. Enrollment and credential server are responsible for peer admission, identity assignment, issuing certificate to individual peers, as well as bootstrapping the peer join. These servers are essentially the root of trust in the overlay and if compromised, attackers can masquerade as other peers, disrupt routing, or launch Sybil attack [3]. o Bootstrap peers: This asset is critical to both the P2P system and to individual peers. In a system with multiple bootstrap peers, Mao, et al. Expires September 5, 2009 [Page 7] Internet-Draft P2P-threat-analysis March 2009 any one bootstrap peer is potentially a non-critical asset to the system or an individual peer. But, the collection of bootstrap peers as a whole becomes a critical asset without which, no new peers will be able to join the system. In many P2P network designs, bootstrap peers are the peers that a node will first contact when trying to join the overlay. The bootstrap peers will direct the joining peer to the correct join location in the overlay, and possibly provide initial routing information for the joining peer to start operating. o The middleware instances on an overlay node: This asset is critical only to individual peers, but compromise of a small fraction of middleware instances are not critical to entire overlay. The middleware instance of a node includes the private keys of the node, the certificates, the node's routing table, and in general the code that conducts normal functionalities of the node. These are critical assets for the peer to maintain its identity and to function correctly in the network. o The peer's computational, storage, and networking capabilities: This asset is critical only to individual peers, but not to the entire P2P network. A peer relies on its computation, storage, and network capabilities to perform its normal functionalities. 4.2. Non-Critical Assets o Data stored in the P2P network: Typically, a P2P network for distributed storage relies on data replication for the availability of the data. A fraction of the replicated data set is a non-critical asset as its corruption can be self-corrected. However, all copies of data collectively is a critical asset as the corruption of the entire collection cannot be recovered. o A small portion of routing entries: By nature of the distributed routing mechanism, a peer should be able to route messages correctly as long as there are a fraction of correct routing entries in its routing table, and most of the routing entries of other peers remains correct. Therefore overlay routing should withstand the corruption of a small fraction of routing entries at each node. (Note that simultaneous corruption of a selected set of routes in the routing table of each node may lead to network- wide partitioning. But such a corruption requires a highly coordinated attack.) Mao, et al. Expires September 5, 2009 [Page 8] Internet-Draft P2P-threat-analysis March 2009 5. Attacker's Goals and Motivations In most cases of computer crimes, attacker's ultimate goal is to obtain monetary gain. Other motivations may be for fame in the attacker world, for fun out of sabotaging a deployed system, or just for making a statement against a group that the attacker does not agree with. An attacker's immediate goal could be eavesdropping, falsify data and messages, disabling communication links for denial of service, impersonating other peers in the network, etc. There are two types of attackers, those who attack from outside the P2P network, and those who attack from inside the network. If the attacker's ultimate goal is just to sabotage the normal P2P network operation (e.g. some recording labels tried to disrupt the P2P file sharing to protect their copyrights), a powerful enough outside attacker can simply disrupt network operations, spread computer viruses, etc. But once the P2P network is large enough, an attacker's resources cannot easily overcome the robustness of the network. And sometimes an attacker wants to victimize a targeted peer while still be able to use the P2P system. These are the cases when attacks from inside the P2P network become more efficient. For this purpose, an attacker has to join the overlay first, possibly behaving normally for a period of time to establish connections with other peers, for the ultimate goal of degrading overlay functionality, disrupting the overlay service, or simply targeting specific peers. 6. Threats Against P2P Networks We have identified the following types of threats according to the potential targets of the attack. o Threats against the underlining network infrastructure that an overlay network relies upon. This includes either wired or wireless network. o Threats against the software platform that a P2P middleware relies upon. o Threats against the P2P middleware itself. The middleware code, or API's, can be susceptible to attacks. o Threats against P2P protocols. The first three types of threats, although critical, are common to threats against most software systems and applications that rely on Mao, et al. Expires September 5, 2009 [Page 9] Internet-Draft P2P-threat-analysis March 2009 communication network. In particular, the first two types of threats are out of control in designing a P2P system. Therefore we will focus our attention on those threats against P2P protocols in this threat analysis. In this part we consider specific threats against P2P networks. These threats are analyzed in terms of attack method, the difficulty to launch attack, and potential impact. We will mainly focus on the P2P systems that use distributed hash tables. Also we assume there exists a server responsible for peer admission, id generation, and issuance of certificates. We assign three levels of impact to each attack: low, medium, and high. A low-impact attack will mostly cause inconvenience to the peers, but will not result in material damage. The medium-impact attack will cause some loss to the peers, such as loss of data, but will not cause critical damage to a peer or to the entire P2P network. The high-impact attacks will cause severe damage to either a peer or the entire network, such as an attacker being able to impersonate other nodes. 6.1. Threat 1: False Claim to Owned Resource ID 6.1.1. Threat Description In a P2P network using DHT, resources (files, services, etc.) use the same id space as nodes. When trying to locate a particular resource, a node simply sends out a message with the resource id, and this message will be routed to the node with a node id closest to the resource id (the definition of "closest" may vary in different P2P routing protocols). However, any node on the overlay route can respond and claim that it owns this resource id, or simply claim that the given resource id does not exist. In the case where the querying node tries to store data, a malicious on-path node can discard the data but reply with a "store successful" message. Although the response is not "authentic" in the sense that it is a false claim to the resource id, it is very hard for the sender to distinguish a false claim from a real one. 6.1.2. Attack Method and Difficulty This attack requires the attacker node to be on the route of the message, and be able to inject arbitrary response message into the overlay. As a "fake" response, the attacker can choose to reply that he owns the resource, or that the resource does not exist, which amounts to a denial of service attack. Mao, et al. Expires September 5, 2009 [Page 10] Internet-Draft P2P-threat-analysis March 2009 6.1.3. Attack Impact The impact of this attack varies include denial of service, injecting false messages, or even data modification. Whether the attack can be detected depends on two factors. The first factor is whether the querying node knows about the data origin in data retrieval. The second factor is whether data integrity protection, such as digital signature, is in place. When the querying node does not know about the data origin, a node on the routing path can inject falsified data even when data integrity protection is in place. This is because although querying node is expecting a signature on the data, it does know whose signature it should be looking for. Using a signature does not establish ownership of the data, nor does it provide a binding relation between the origin NodeID/user-name and the message. Potentially, every peer can sign the same message as long as they have an identity certified by the enrollment server. This includes the compromised peer on the routing path. When the querying node knows the data origin and data integrity protection is in place, this attack will result in denial of service, because any falsified data that attacker returns to the querying node will eventually be dismissed. If data replication is employed by the source of data, the querying node can try to find other copies of the data in the network. Without data integrity protection, an attacker can claim the owned resource id and return falsified data. Under the assumption that the querying node knows the data origin, the attack impact is low with both data integrity protection and data replication; the impact is medium with data integrity protection but without data replication; without either data integrity protection or data replication, the attack impact is high. In terms of how wide this attack can spread, in a ring based overlay design (Chord), a message routes through log(N) nodes on average, where N is the total number of nodes in the overlay and log() is the base-2 logarithm. If any node on this path is compromised, the attack can be launched. Denote the probability that a node in the network can be compromised by m. The probability that a request, routing through log(N) nodes is not compromised is (1-m)^(log N). If we allow a maximum f percent of requests to fail, then the maximum value of m should be m = 1 - (1-f)^(1/log(N)). For example, when N=2^9 and with five malicious nodes, 4.4% of all requests would fail. This shows that with a tiny fraction of peers compromised, as long as the compromised nodes are evenly distributed in the overlay topology, they can spread the attack to a larger portion of requests originated from the peers. We can also show that when the fraction of malicious Mao, et al. Expires September 5, 2009 [Page 11] Internet-Draft P2P-threat-analysis March 2009 nodes is grater than or equal to 50%, with high probability of a request will fail. 6.1.4. Mitigations There are a few ways to detect and mitigate to this attack. The first step towards detecting the attack is to have mandatory data integrity protection in place, such as in the RELOAD design by the P2PSIP working group. A mismatch in data integrity check signals potential attack (but random error in communications can also cause the same problem). The next intuitive action by the querying node is to resend the request via a different route. Typically overlay routing protocols will try to mandate the next hop according to certain rules optimized for minimum hop count or delay. To avoid the attack, the querying node should at this stage ignore these rules and try to route the request via a few randomly select nodes in its routing table. In general, the more routes it tries, the higher the likelihood that at least one route will return a correct response. But such behavior is not guaranteed as certain placement of the attacker at strategic location in the network topology will defeat all the redundant routes selected. If the querying node knows other replication resource id's, it should also try to retrieve those data. This mitigation is a low-cost method in general. A querying node only sends out redundant requests in reaction to a detected attack, and the overhead is only a few more messages routed through the overlay. A more costly mitigation was proposed in [4], where a set of proof managers, who are also ordinary nodes, are used to collect and verify if a peer has an id in an designated segment of id space. The id information collection has to be performed periodically, and all verifications need to go through the proof managers. The specific proposal in [4] used prefix based routing protocol such as Tapestry as an example, and the key provisioning overhead is quite large since an offline CA has to distribute a pair of public-private key to all peers in each unique prefix group. If there each id is L digits, and there are N nodes in the overlay, this amounts to provision (LxN) pairs of keys. 6.2. Threat 2: Abuse Bootstrapping Process 6.2.1. Threat Description In many P2P network design, a joining peer will rely on the bootstrapping peers to obtain initial information for overlay operations, including neighbor information, connections to other peers, etc. If the bootstrap peers are compromised, during the bootstrap process they can set up connections in such a way that the Mao, et al. Expires September 5, 2009 [Page 12] Internet-Draft P2P-threat-analysis March 2009 joining peer will only have compromised nodes as its connected peers. These malicious peers will "shadow" the joining node and perform traffic censoring, denial of service attacks. For this reason, malicious peers, or a group of malicious peers controlled by a single attacker, have strong incentives to become bootstrap peers. 6.2.2. Attack Method and Difficulty Since a joining peer typically obtains a list of bootstrap peers, malicious peers also have incentives to become the majority or even exclusive bootstrap peers to increase their chances of being selected. While RELOAD does not specify a means of dynamically updating the lists of bootstrap peers, the ability to do so greatly improves the bootsrap peer availability in the system, when the system is not under attack. However, the attack described here can be achieved by volunteering to become bootstrap peers, and by reporting that other non-compromised bootstrap peers are unavailable. Typically, the list of bootstrap peers (BPs), maintained by the enrollment server, should be updated when existing bootstrap peers leave the network and new peers volunteer to serve as BPs. If the enrollment server does not take cautionary steps to validate the reported departure of BPs, attackers will be able to occupy a substantial portion of the BP list. Typically, attackers will have no difficulty to volunteer as a bootstrap peer. However, if they want to remove other BPs from the BP list, the difficulty depends on whether enrollment server performs availability check before removing BPs. In case the availability check is in place, attackers cannot succeed in removing other BPs, unless then can cause the network failure of the targeted BPs. In the case where there is no availability check, attackers can achieve their goal easily. 6.2.3. Attack Impact The impact of this attack is high to affected peers, because it can stop individual node from functioning. This attack could also be wide-spread if the malicious peers take over the BP list at an early stage of the overlay formation and a large number of peers joined afterwards. Once a large number of correct nodes are affected, the overlay functionalities will severely degrade. 6.2.4. Mitigations The two ways to defend against this attack is not to allow compromised peers to become bootstrap peers, and not to remove valid bootstrap peers from the BP list. Unfortunately, to achieve the former requires identification of compromised peers, and/or measuring Mao, et al. Expires September 5, 2009 [Page 13] Internet-Draft P2P-threat-analysis March 2009 of how well BPs are performing, which are hard problems themselves and should be separately researched. The latter can be achieved at relative low cost. The enrollment server should maintain direct links to all BPs and verify the availability of BPs periodically, or in case of reported departure of certain BPs. 6.3. Threat 3: Abuse Routing Update 6.3.1. Threat Description Peers in a P2P network may leave abnormally without notifying its neighbors and connected peers. When a peer discovers another peer's departure, it should notify its neighbors to update their routing information. Typically, upon learning a node's departure, other peers need to find another connection to replace the leaving node in their routing table. The replacement node will likely to be a neighbor of the leaving node. Attackers can abuse this process, using compromised nodes to send out false routing update about its neighbors, and attract other peers to select itself as a routing entry. This attack increases the chances that an attacker node can be on a message route of other correct peers, resulting in increase possibility that an attacker can perform eavesdropping, modifying messages (when message authentication is not in place), or falsely claim resource id's it owns (Threat 1). 6.3.2. Attack Method and Difficulty Any attacker can send out false routing update. If there is not check for validity of these updates, attacker will succeed with ease. When validity checks are performed by recipient nodes, the attacker can still convince the verifying peer by causing network failure at the targeted peer. The difficulty of causing network failure/ congestion is medium. 6.3.3. Attack Impact This attack will directly impact those nodes who replace the (falsely reported) departing node with the attacker node in their routing table, causing potential eavesdropping, denial of service, or data falsification. The impact is high to the node being attacked, but to the entire overlay, the impact is medium if only a few attacker nodes succeed. The impact to the entire overlay becomes high once a large portion of the peers in the overlay are affected. This attack will only affect those peers who have a direct connection with the reported departing peer. Using Chord as an example, on average, a peer is connected to O(log N) other peers, where N is the number of peers. For prefix based routing such as Pastry, on average Mao, et al. Expires September 5, 2009 [Page 14] Internet-Draft P2P-threat-analysis March 2009 a peer is connected to O(LxD), where L is the number of digits for a peer id, and D the base of each digit. 6.3.4. Mitigations This attack can be detected if the recipients of the false routing update contact the reported departing node to verify the update. In case the routing update is originated from the departing node itself, the recipient needs to verify the identity of the sender to ensure the message is not forged. In addition, the update message should have integrity protection and replay protection to prevent malicious peers from modifying or resending the update message. All the fore- mentioned mitigations can be achieved using cryptographic signatures. 6.4. Threat 4: Targeted Node ID Generation 6.4.1. Threat Description When node ID's are not distributed by a central server, a peer can try to generate a node id in a specific range of id space. Typically, node id's are generated using cryptographic hash, the pre- image resistance in cryptographic hash makes generating a specific node id extremely difficulty. But, since cryptographic hash functions behave like a uniform random number generator, an attacker targeting a specific range of id space can succeed with a probability proportional to the size of the segment length. 6.4.2. Attack Method and Difficulty Suppose Attacker try to generate and ID between two existing nodes id's (n1, n2), the success probability for each trial is roughly (n1- n2)/(2^k). Here we assume binary node id and k is the total number of bits in a node id. Typically an attacker will try to generate a node id between two consecutive node id's in the overlay, in this way the attacker is guaranteed to become part of the routing table of the immediate neighbors and a number of attacks (Threat 1, 3, an 5) becomes possible. The success probability to generate such a node id in one trial is roughly 1/N, where N is the number of peers in the overlay. The number of trials for the attacker to succeed is a discrete random variable T. The success probability in exact t trials is: Pr[success in t trials] = Pr[T = t] = (1 - 1/N)^(t-1)*(1/N) t = 1, 2, 3, ... It can be shown that the expected value of T, i.e. the average number of trials that an attacker has to perform to obtain an node id in the desired id segment (between two existing consecutive node id's) is Mao, et al. Expires September 5, 2009 [Page 15] Internet-Draft P2P-threat-analysis March 2009 E[T] = N. Therefore the attacker's effort is to generate different node id's in proportion to the number of peers in the network. Considering most id generation algorithms are cryptographic hash functions and can be performed millions of time per second, the computational difficulty of this attack is rather low. 6.4.3. Attack Impact The impact of this attack is high because it enables various other kinds of threat including Sybil and eclipse attack, denial of service, falsely claim resources, etc. 6.4.4. Mitigations To avoid this attack, many P2P network design does not allow self- generated node id by the peer. A central server (such as an enrollment server) is used to randomly generate and distribute node id's and a peer can only take an assigned id. This mitigation is sufficient most of time. If an attacker has enough resources, it can still join the network N times through the enrollment server as different peers. The result is that it will likely control a neighbor next to every normal peer in the network. Such a strategy is not economical to the attacker, in the sense that the attacker has to use a large amount of resources only to influence an equal amount of resources. In case where a central server is not available, such as in a P2P network formed in an ad hoc fashion, peers will have to choose their own id's according to some id generation algorithms. In those cases, the mutual trust among the peers will play a big role in maintaining the security of the P2P group. If out of band communication is available, mutually trusted peers can set up a shared secret key for the admission into the P2P network, under the assumption that any peer with the secret key will not be malicious and generate its node id according to a given algorithm. 6.5. Threat 5: Sybil Attack 6.5.1. Threat Description Sybil attack refers to any attack that involves multi-node, multi- identity collusion. In order to join the P2P network as multiple nodes, the attacker could obtain multiple identities and use them to register in the overlay (think about obtaining multiple email addresses). Or an attacker could compromise several peers in the overlay, and coordinate these compromised peers to launch attacks. Once an attacker controls multiple peers, he/she can perform eavesdropping, denial of service, censoring traffic, etc. [3] Mao, et al. Expires September 5, 2009 [Page 16] Internet-Draft P2P-threat-analysis March 2009 6.5.2. Attack Method and Difficulty If externally registered identities are allowed and identity registration is open, such as email registration, an attacker can simply register as many identities as its resource would allow and join all identities in the P2P network. Such attack is of low difficulty. If the registration is tightly controlled and requires tasks such as liveliness proof, solving computational puzzles, or even in-person, then the difficulty level will become medium to high. Attackers can also try to compromise the middleware instance of the nodes via software bugs. In this case the attack difficulty will depend on the implementation quality of the middleware. 6.5.3. Attack Impact This attack's impact depends on the percentage of compromised nodes in the overlay, how well the attacker coordinates the compromised nodes, and the amount of resources the attacker has. If the fraction of nodes corrupted is small, the impact will be medium to the entire network operations, but still be critical to particular node targeted by the attacker. If the attacker can coordinate its asset well, a group of colluding nodes can be used to defeat a feedback or reputation system. 6.5.4. Mitigations Most mitigations to this attack are related to controlled identity registrations. For example, the registration process can require liveliness proof to prevent a machine from automatically registering itself. Commonly used techniques, such as IP address check, allowing only one registration per address could limit the exposure to this threat. A non-technical but effective mitigation is to require payment for each registration. For overlay with high security requirement, a close-registration form at a location controlled by an administration entity or even invitation-only participation will help reduce the risk. 6.6. Threat 6: Eclipse Attack 6.6.1. Threat Description When all inbound and outbound connections from a peer are controlled by an attacker, the peer is essentially "eclipsed". The attacker can sensor traffic, replay messages, perform denial of service, or launch other attacks. The term "eclipse" is used also because the attacker can simulate a valid outside world for the shadowed node and the node being shadowed may not even notice it is under such attack [5]. Mao, et al. Expires September 5, 2009 [Page 17] Internet-Draft P2P-threat-analysis March 2009 A special case of the eclipse attack is what we call "degree-one" eclipse attack. This happens to a peer that fully relies on a host node to perform overlay routing. RELOAD allows for the notion of "client" nodes that do not perform message routing but still wants to participate in other overlay activities, by allowing a client to be attached to a peer. The point of attachment is usually determined by the closeness in peers' node id (see RELOAD design of P2PSIP for example). If the host node is compromised, it can perform degree-one eclipse attack against the non-routing peer attached to it. 6.6.2. Attack Method and Difficulty To achieve this attack, malicious peers need to attract more connections to themselves. This can be done via false routing update (see Threat 3), or false claim of network latency in case there are latency/location optimization in the network routing. An eclipse attack against certain targeted node can be done via targeted node id generation. When the node id is not assigned by a central server, it is possible for an attacker node to become immediate neighbors of a targeted victim peer and attract all inbound/outbound connections from that peer. If the peer itself is a non-routing peer and relies on its immediate neighbor to perform overlay routing, the degree-one eclipse attack can thus be launched. Since this attack is always achieved via other attack methods, its difficulty will be reflected in the specific means to achieve the attack goal. 6.6.3. Attack Impact This attack has high impact to the targeted victim peer, but would only have low impact to other peers in the overlay. To launch an eclipse attack, an attacker has to control all or most of the inbound/outbound connections of a peer. Thus with limited resource from attacker and normal P2P network constraint on forming connection between peers, an attacker's best bet is to concentrate its resources on a few targeted victims. Naturally the compromised nodes may also become part of the routing table of some other peers, enabling them to launch other attacks such as denial of service, false claimed resource id (Threat 1), etc. But these attacks are not as critical to the victim peer as a complete eclipse attack. 6.6.4. Mitigations A low cost mitigation to this attack is to avoid forming connections with the compromised nodes. As described in Threat 3, false routing updates can lead to connections with malicious nodes. Therefore all peers should be cautious in adhering to overlay constraints in forming connections, take care in verifying any node join/departure activities. Mao, et al. Expires September 5, 2009 [Page 18] Internet-Draft P2P-threat-analysis March 2009 In [5], Singh et. al. introduced a more sophisticated defense by posing a limit on the outbound degree on any peer in the overlay. To enforce this limit, they introduced an anonymous challenge mechanism among the overlay neighbors. Each peer maintains a list of other peers that has a connection to it. It then can challenge any given neighbor anonymously about the number of outbound connections and the destination of these connections. A correct answer must contain the challenger. Since a peer is challenged by all its neighbors and does not know the identity of the challenger, it must report its actual neighbor list honestly, otherwise the act of lying may be caught. The drawbacks of this scheme is its high communication overhead and the required anonymous communication channel may not be easy to come by. 6.7. Threat 7: Lack of Practical Reputation System 6.7.1. Threat Description Reputation systems for P2P systems have been widely researched as a stand-alone topic [6] [7]. But practical integration of reputation management into a P2P system design is still lacking in the current stage of research and design. The risk from lack a reputation system is that even when various attacks are detectable and the culprits can be traced, there will be no framework to systematically notify all peers in the network about the activities of a few rogue peers. Thus the rogue peers can get away and continue to cause damages to the network. 6.7.2. Existing Proposals There are a number of existing proposals for reputation systems in P2P systems. See references [6] and [7] and citations listed in these references. When considering reputations systems for P2P network, one needs to consider robustness of the reputation, complexity of implementation, and scalability of the solution (whether the reputation system can be fully distributed). Some reputation system are designed to be solely transaction based [6], just as the feedback mechanism in eBay. The peers can compute and publish feedback scores based on their experience with other peers in prior transactions. The drawback of this kind of proposal is that if there are a group of rogue peers that can coordinate well, they can produce skewed feedback, frame other peers, and defeat the purpose of reputation system. In [7], other parameters are taken into consideration, such as the credibility of the feedback source, transaction context for differentiating mission-critical transactions from non-critical ones, and group context for addressing network-wide threats. Another consideration is that the complexity of the reputation scheme must be low enough for practicality. Mao, et al. Expires September 5, 2009 [Page 19] Internet-Draft P2P-threat-analysis March 2009 Note: Analysis shows that with about 50% of the nodes misbehaving, the system starts to be non-functional. Replication will improve the availability, but clearly, when a reasonable number of peers are malicious or selfish, those peers also stop benefitting from the system. So, a game theoretic analysis may show that balance and a functioning system will be maintained by the peers just in the interest of serving their own needs. Given that and given the complexity of most good reputation management solutions, it is not clear that reputation management is actually needed to thwart the threats outlined here. More analysis is needed on this front to draw further conclusions and future revisions of this draft will address this. 6.8. Threat 8: Free Riding and Whitewashing 6.8.1. Threat Description In a P2P system, free riding means a peer will only retrieve content without willing to route and store content for other peers. Such selfish behavior is detrimental to the overall health of the P2P system [8] [9]. If the percentage of such selfish peers is large enough, overlay routing and storage performance will degrade significantly to the extent that the entire P2P system will be almost non-functional. Whitewashing refers to a free-riding peer trying to "reset" its reputation once its reputation has gone bad, by leaving the P2P system and then join with a new identity. If the P2P system cannot track the whitewashing behavior, a free-rider can repeatedly enjoy service without contribution or getting punished. 6.8.2. Attack Impact One characteristic of a fully distributed P2P system using DHT is that every peer, or most of the peers, has to participate in order for the system to function correctly. The free-rider's behavior has the same effect as denial of service, as they refuse to route and store messages. When the percentage of free-riders is small, the free-riders will degrade the system performance for other peers. Messages destined to correct peers may be dropped and storage requests denied. As analyzed in the Attack Impact section of Threat 1, if more than 50% of the peers become free-riders, with very high probability an overlay message will fail. Thus a large percentage of free-riders will also impact the service they receive. The impact of whitewashing is mostly on reputation system, as it renders the free- riders activity untraceable. Mao, et al. Expires September 5, 2009 [Page 20] Internet-Draft P2P-threat-analysis March 2009 6.8.3. Mitigations Reputation system can be used to track the free-riders' behavior. Recent study on centralized P2P file sharing system [8] [9] has shown that reputation system can curb the free-riders' behavior, but not completely eliminate it. At the same time, whitewashing can still cause traceability problem for reputation systems. The enrollment server could limit the total number of registrations per day, but such limit may affect innocent users as well. The enrollment server can also use identities that are not easy to obtain by users, and thus discourage whitewashing. For example, if the registration process requires proof of human interaction and takes a few steps for verification, a selfish user may have less incentive to perform whitewashing as it will bring inconvenience. 6.9. Threat 9: Replay and Rollback 6.9.1. Threat Description A malicious peer M can store a message (or a series of messages) sent between peer A and peer B, and replay the same message at a later time. The first use of such method is to attack a communication protocol, when the protocols are not well designed/implemented. For example, when authenticating a peer using public key cryptography, the validating peer B may ask the proving peer A to demonstrate the possession of the secret signing key, usually by requesting peer A to sign a given value. If this value is not chosen randomly each time the protocol is performed, a malicious peer M who records the entire message exchange can repeat the protocol masquerading as A. A second use of such protocol is to corrupt data by replay earlier store/overwrite requests. Suppose peer A sent a request to store a data item at peer B, and later sent another request to update the data item. A malicious peer M can record the first storing request and resend it after the data has been updated. The effect is that the updated data will be converted back to the older version, causing data corruption. 6.9.2. Attack Impact If protocols are not carefully designed, replay attack can lead to impersonation, faking authentication credentials, injecting false messages, data corruption. 6.9.3. Mitigations At the protocol level, replay attacks can be mitigated using authenticated communication sessions with random nonce. Since each Mao, et al. Expires September 5, 2009 [Page 21] Internet-Draft P2P-threat-analysis March 2009 session uses a new key, an attacker will not be able to replay a message from an old session. Within the same session, the recipient can keep a limited memory (window) for messages that are received recently and to be received. Any message that is already inside the window or falls out of the window will be discarded. If two peers are directly communicating to each other, they can use TLS or DTLS protocol and enable the replay protection options that come with the protocols. For a P2P system, the replay challenge remains when two peers try to contact each other via overlay routing, because protocols like TLS can only offer per-hop replay protection. In this case, a reasonable solution would be for the sender and recipient peers to use time stamp on the overlay messages. This solution requires that sender and recipient be loosely time synchronized and any message outside a designated time window should be discarded. 6.10. Threat 10: Data Corruption 6.10.1. Threat Description One common goal of an attacker is to remove or modify stored data in the network. Without data authorization, an attacker can create a data item with the same resource-name as an existing resource, and try to store the new data. A DHT-based overlay routing will route the data to the same peer who stored the data with identical name, and the existing data could be overwritten as a result. With data authorization, an attacker cannot overwrite the data, but can still try to inject multiple copies of garbage data with the same resource- name as certain popular data items. Here the attack goal is to frustrate users who try to distinguish the real data from fake ones. Aside from malicious attacks, using a weak hash function to generate resource-id can also cause unintended collision in resource id. Typically resource IDs are generated by a hash function with resource name as input. Using a weak hash function or a weak random number generator, the chance to cause a resource ID collision from different resource names is higher than using a cryptographically strong hash function. Such collision may cause unwanted confusion in data retrieval, since the retrieving peer has to inspect all data entries to decide which one is needed. 6.10.2. Attack Impact This attack impacts the data owner, and whoever wants to use the corrupted data item. The nature of attack is mostly denial of service, or brings inconvenience to users. Mao, et al. Expires September 5, 2009 [Page 22] Internet-Draft P2P-threat-analysis March 2009 6.10.3. Mitigations To reduce unintended resource id collision, a cryptographic hash function should be used for resource id generation. For example, the collision probability for commonly used hash function SHA-1 is about 2^(-63). To prevent attackers from overwriting data, an identity-based data authorization model can be used. One example is the RELOAD data storage model. Typically, only the owner of the data can modify and remove data. The ownership is established at the time of data storage, where the data owner signs the data entry and the owner's user-name and public key should be recorded with the data. Subsequent update to the data requires the proof of the possession of the signing key, unless the data owner explicitly delegate data update capability to other designated users. The system can still allow multiple users to write to the same resource-id, as long as different user's data are separately stored, and differentiated by either the user identity or type of data. After retrieving the data, the retrieving peer can also check the signature to verify the integrity of the data. However, the signature with data can only ensure that the message has not been modified after the signature was signed. In verifying the signature, the receiving peer has to know the signing peer already or have some out-of-band trust with the signing peer. Otherwise the signature verification will not be meaningful, as the message can be modified and resigned by a malicious peer on the routing path. Using a signature also does not establish ownership of the data. This is because there is no tying relation between the NodeID and the message. Potentially, every peer can sign the same message. For this reason, whether the signature covers signer's identity along with data or not is not important. 6.11. Threat 11: Software Vulnerabilities 6.11.1. Threat Description The P2P middleware relies on software implementation to achieve its functionalities. If exploitable software bugs exists, the P2P middleware will be vulnerable to various software-based attacks. Attacks such as stealing keys and passwords, disrupt routing, obtaining protected data can be achieve just by exploiting software bugs. Mao, et al. Expires September 5, 2009 [Page 23] Internet-Draft P2P-threat-analysis March 2009 6.11.2. Mitigations Standard software security practice should be employed in implementing the P2P middleware. Lessons learned through past software exploits include: maintain process separation, perform careful memory and buffer management, use strong cryptographic algorithms (random number generator, authentication, etc.), store and protect secret data securely [10]. 7. References 7.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base Protocol", draft-ietf-p2psip-base-01 (work in progress), December 2008. 7.2. Informative References [3] Douceur, J., "The Sybil Attack", , 2002. [4] Ganesh, L. and B. Zhao, "Identity Theft Protection in Structured Overlays", NPSec Proceedings of the 1st Workshop on Secure Network Protocols, 2005. [5] Singh, A., Ngan, T., Druschel, P., and D. Wallach, "Eclipse Attacks on Overlay Networks: Threats and Defenses", In Proc. of the IEEE INFOCOM, 2006. [6] Kamvar, S., Schlosser, M., and H. Garcia-Molina, "The EigenTrust Algorithm for Reputation Management in P2P Networks", In Proc. of the 12th international conference on World Wide Web, 2003. [7] Xiong, L. and L. Liu, "PeerTrust: supporting reputation-based trust for peer-to-peer electronic communities", In IEEE Transactions on Knowledge and Data Engineering, 2004. [8] Adar, E. and B. Huberman, "Free Riding on Gnutella", , 2000. [9] Yang, M., Zhang, Z., Li, X., and Y. Dai, "Empirical Study of Free-Riding Behavior in the Maze P2P File-Sharing System", Lecture notes in computer science, 2005. Mao, et al. Expires September 5, 2009 [Page 24] Internet-Draft P2P-threat-analysis March 2009 [10] Howard, M., LeBlanc, D., and J. Viega, "19 Deadly Sins of Software Security: Programming Flaws and How to Fix Them", McGraw-Hill Osborne Media, 2005. [11] Yongchao, S. and X. Jiang, "Diagnose P2PSIP Overlay Network", draft-ietf-p2psip-diagnostics-00 (work in progress), January 2009. [12] Castro1, M., Druschel, P., Ganesh, A., Rowstron, A., and D. Wallach, "Secure routing for structured peer-to-peer overlay networks", In Proc. of the 5th Symposium on Operating Systems Design and Implementation, 2002. [13] Naor, M. and U. Wieder, "A simple fault tolerant distributed hash table", In 2nd International Workshop on Peer-to-Peer Systems (IPTPS), 2003. [14] Ratnasamy, S., Francis, P., Handley, M., Karp, R., and S. Shenker, "A Scalable Content-Addressable Network", Proc. ACM SIGCOMM, 2001. [15] Rowstron, A. and P. Druschel, "Pastry: Scalable, decentralized object location, and routing for large-scale peer-to-peer systems", Lecture Notes in Computer Science, 2001. [16] Stoica, I., Morris, R., Karger, D., Kaashoek, M., and H. Balakrishnan, "Chord: A scalable peer-to-peer lookup service for internet applications", In Proc. of the ACM SIGCOMM, 2001. Authors' Addresses Yinian Mao Qualcomm, Inc. 5775 Morehouse Dr San Deigo, CA USA Phone: +1 858-651-6193 Email: yinianm@qualcomm.com Mao, et al. Expires September 5, 2009 [Page 25] Internet-Draft P2P-threat-analysis March 2009 Vidya Narayanan Qualcomm, Inc. 5775 Morehouse Dr San Deigo, CA USA Phone: +1 858-845-2483 Email: vidyan@qualcomm.com Ashwin Swaminathan Qualcomm, Inc. 5775 Morehouse Dr San Deigo, CA USA Phone: +1 858-845-8775 Email: sashwin@qualcomm.com Mao, et al. Expires September 5, 2009 [Page 26]