diff options
Diffstat (limited to 'doc/rfc/rfc5765.txt')
| -rw-r--r-- | doc/rfc/rfc5765.txt | 1571 |
1 files changed, 1571 insertions, 0 deletions
diff --git a/doc/rfc/rfc5765.txt b/doc/rfc/rfc5765.txt new file mode 100644 index 0000000..71fe1de --- /dev/null +++ b/doc/rfc/rfc5765.txt @@ -0,0 +1,1571 @@ + + + + + + +Internet Research Task Force (IRTF) H. Schulzrinne +Request for Comments: 5765 Columbia University +Category: Informational E. Marocco +ISSN: 2070-1721 Telecom Italia + E. Ivov + SIP Communicator + February 2010 + + + Security Issues and Solutions in Peer-to-Peer Systems + for Realtime Communications + +Abstract + + Peer-to-peer (P2P) networks have become popular for certain + applications and deployments for a variety of reasons, including + fault tolerance, economics, and legal issues. It has therefore + become reasonable for resource consuming and typically centralized + applications like Voice over IP (VoIP) and, in general, realtime + communication to adapt and exploit the benefits of P2P. Such a + migration needs to address a new set of P2P-specific security + problems. This document describes some of the known issues found in + common P2P networks, analyzing the relevance of such issues and the + applicability of existing solutions when using P2P architectures for + realtime communication. This document is a product of the P2P + Research Group. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Research Task Force + (IRTF). The IRTF publishes the results of Internet-related research + and development activities. These results might not be suitable for + deployment. This RFC represents the consensus of the Peer-to-Peer + Research Group of the Internet Research Task Force (IRTF). Documents + approved for publication by the IRSG are not a candidate for any + level of Internet Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc5765. + + + + + + + + +Schulzrinne, et al. Informational [Page 1] + +RFC 5765 Security in P2P Realtime Communications February 2010 + + +Copyright Notice + + Copyright (c) 2010 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 + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Schulzrinne, et al. Informational [Page 2] + +RFC 5765 Security in P2P Realtime Communications February 2010 + + +Table of Contents + + 1. Introduction ....................................................4 + 1.1. Purpose of This Document ...................................6 + 1.2. Structure of This Document .................................7 + 2. The Attackers ...................................................8 + 2.1. Incentive of the Attacker ..................................8 + 2.2. Resources Available to the Attacker ........................9 + 2.3. Victim of the Attack ......................................10 + 2.4. Time of Attack ............................................10 + 3. Admission Control ..............................................10 + 4. Determining the Position in the Overlay ........................11 + 5. Resilience against Malicious Peers .............................12 + 5.1. Identification of Malicious Peers .........................13 + 5.1.1. Proactive Identification ...........................13 + 5.1.2. Reactive Identification ............................13 + 5.2. Reputation Management Systems .............................14 + 5.2.1. Unstructured Reputation Management .................14 + 5.2.2. Structured Reputation Management ...................14 + 6. Routing and Data Integrity .....................................15 + 6.1. Data Integrity ............................................15 + 6.2. Routing Integrity .........................................15 + 7. Peer-to-Peer in Realtime Communication .........................16 + 7.1. Peer Promotion ............................................17 + 7.1.1. Active vs. Passive Upgrades ........................17 + 7.1.2. When to Upgrade ....................................18 + 7.1.3. Which Clients to Upgrade ...........................18 + 7.1.4. Incentives for Clients .............................19 + 7.2. Security ..................................................19 + 7.2.1. Targeted Denial of Service .........................19 + 7.2.2. Man-in-the-Middle Attack ...........................20 + 7.2.3. Trust between Peers ................................20 + 7.2.4. Routing Call Signaling .............................20 + 7.2.5. Integrity of Location Bindings .....................21 + 7.2.6. Encrypting Content .................................21 + 7.2.7. Other Issues .......................................22 + 8. Open Issues ....................................................22 + 9. Security Considerations ........................................23 + 10. Acknowledgments ...............................................23 + 11. Informative References ........................................23 + + + + + + + + + + + +Schulzrinne, et al. Informational [Page 3] + +RFC 5765 Security in P2P Realtime Communications February 2010 + + +1. Introduction + + Peer-to-peer (P2P) overlays have become quite popular with the advent + of file-sharing applications such as Napster [NAPSTER], KaZaa + [KAZAA], and BitTorrent [BITTORRENT]. After their success in file- + sharing and content distribution [Androutsellis-Theotokis], P2P + networks are now also being used for applications such as Voice over + IP (VoIP) [SKYPE] [Singh] and television [PPLIVE] [COOLSTREAM]. + However, most of these systems are not purely P2P and have + centralized components like the login server in Skype [Baset] or + moderators and trackers in BitTorrent [Pouwelse]. Securing pure P2P + networks is therefore still a field of very active research + [Wallach]. + + P2P overlays can be broadly classified as structured and unstructured + [RFC4981], depending on their routing model. Unstructured overlays + are often relatively simple, but search operations in them, usually + based on flooding, tend to be inefficient. Structured P2P overlays + use distributed hash tables (DHTs) [Stoica] [Maymounkov] [Rowstron] + to perform directed searches, which make lookups more efficient in + locating data. This document will mostly focus on DHT-based P2P + overlays. + + When analyzing the various attacks that are possible on P2P systems, + it is important to first understand the motivation of the attackers + as well as the resources (e.g., computation power, access to + different IP subnets) that they would have at their disposal. + + Once the threat has been identified, admission control is a first + step towards security that can help avoid a substantial number of + attacks [Kim]. Most solutions rely on the assumption that malicious + nodes represent a small fraction of all peers. It is therefore + important to restrict their number in the overlay. + + Other P2P-specific security problems discussed here include attacks + on the routing of queries, targeted denial-of-service attacks, and + attacks on data integrity. + + In the remainder of this document, we outline the main security + issues and proposed solutions for P2P systems. Following this, we + focus on a particular class of P2P applications that provide realtime + communications. Realtime communications use the same DHTs used by + file-sharing applications; however, the data that is saved in these + DHTs is different. In realtime communications, the contents stored + in the DHTs comprises user location, the DHT being the substitute for + a centralized registration server. + + + + + +Schulzrinne, et al. Informational [Page 4] + +RFC 5765 Security in P2P Realtime Communications February 2010 + + + At first glance, it may appear that requirements on peer-to-peer + systems for realtime communication services are no different than + those for file-sharing services. Table 1 demonstrates that there are + sizeable differences related to privacy, availability, and a marked + increase in the general security requirements. + + +-----------------+-----------------------+-------------------------+ + | | File-sharing | Realtime communication | + +-----------------+-----------------------+-------------------------+ + | Distributed | Shared file locations | User locations are | + | database | are indexed in a | indexed in a table | + | | table distributed | distributed among | + | | among peers; often | peers; rarely more than | + | | hundreds or thousands | one per peer. | + | | per peer. | | + | Availability | Same files are | Users are unique; | + | | usually available at | attacks targeting | + | | multiple locations | single users may be | + | | and failures | addressed both to the | + | | involving single | distributed index and | + | | instances are | to the user's device | + | | overcome by abundancy | directly. | + | | of resources; attacks | | + | | targeting single | | + | | files need to be | | + | | addressed to the | | + | | distributed index. | | + | Integrity | Attackers may want to | Attackers may want to | + | | share corrupted files | impersonate different | + | | in place of popular | users in order to | + | | content, e.g., to | handle calls directed | + | | discourage users from | to them; constitute a | + | | acquiring copyrighted | particular threat for | + | | material; constitute | the user as, in case of | + | | a threat for the | success, the attacker | + | | service, but not for | acquires full control | + | | the users. | on the victim's | + | | | personal | + | | | communications. | + | Confidentiality | Shared files are, by | Communications are | + | | definition, readable | usually meant to be | + | | by all users; in some | private and need to be | + | | cases, encryption is | encrypted; | + | | used to avoid | eavesdropping may | + | | elements not involved | reveal sensitive data | + | | in the service to | and is a serious threat | + | | detect traffic. | for users. | + + + + +Schulzrinne, et al. Informational [Page 5] + +RFC 5765 Security in P2P Realtime Communications February 2010 + + + | Bitrate and | The file-transfer use | Realtime traffic almost | + | latency | case is particularly | always requires a | + | | tolerant to unstable | constant minimum | + | | bitrates and ability | bitrate and low latency | + | | to burst on and off | in order to avoid | + | | as peers disappear or | problems like jitter. | + | | new ones become | While this is not | + | | available. | directly related to a | + | | | specific sort of | + | | | attacks, it is a | + | | | significant constraint | + | | | to the design of | + | | | certain design | + | | | solutions, and in | + | | | particular those that | + | | | somehow affect routing. | + | Peer lifetime | File-sharing users do | Realtime communication | + | | not need to stay in | applications need not | + | | the overlay more than | leave the overlay for | + | | the time required for | as long as the user | + | | downloading the | wants to stay connected | + | | content they are | and be reachable. This | + | | looking for. | gives the attackers | + | | | longer time for | + | | | conducting successful | + | | | targeted attacks. | + +-----------------+-----------------------+-------------------------+ + + Table 1: Main differences between P2P applications used for + file-sharing and for realtime communication. + +1.1. Purpose of This Document + + The goal of this document is to provide authors of P2P protocols for + realtime communications with background that they may find useful + while designing security mechanisms for specific cases. The document + has been extensively discussed during face-to-face meetings and on + the P2PRG mailing list; it has been reviewed both substantially and + editorially by two members of the research group and reflects the + consensus of the group. + + The content of this document was partially derived from the article + "Peer-to-peer Overlays for Real-Time Communication: Security Issues + and Solutions," published in IEEE Surveys & Tutorials, Vol. 11, No. + 1, and originally authored by Dhruv Chopra, Henning Schulzrinne, + Enrico Marocco, and Emil Ivov. + + + + + +Schulzrinne, et al. Informational [Page 6] + +RFC 5765 Security in P2P Realtime Communications February 2010 + + + It is important to note that this document considers "security" from + the perspective of application developers and protocol architects. + It is hence entirely agnostic to potential legislation issues that + may apply when protecting applications against a specific attack, as, + for example, in the case of lawful interception. + +1.2. Structure of This Document + + The document is organized as follows. In Section 2, we discuss P2P + security attackers. We try to elaborate on their motivation, the + resources that would generally be available to them, their victims, + and the timing of their attacks. In Section 3, we discuss admission + control problems. In Section 4, we identify the problem of where a + node joins in the overlay. In Section 5, we describe problems + related to identification of malicious nodes and the dissemination of + this information. In Section 6, we describe the issues of routing + and data integrity in P2P networks. Finally, in Section 7 we discuss + how issues and solutions previously presented apply in P2P overlays + for realtime communication. + + Table 2 and Table 3 provide an index of the attacks and the solutions + discussed in the rest of this document. + + +---------------------------------------+---------------------------+ + | Attack name | Referring sections | + +---------------------------------------+---------------------------+ + | botnets (use of) | Section 2.1, Section 2.2 | + | denial of service (DoS) | Section 2.1, | + | | Section 7.2.1 | + | man in the middle (MITM) | Section 7.2.2 | + | poisoning | Section 6.1, | + | | Section 7.2.2 | + | pollution | Section 2.1, Section 6.1 | + | sybil | Section 2.2, Section 4 | + | targeted denial of service | Section 7.2.1 | + +---------------------------------------+---------------------------+ + + Table 2: Index of some of the more popular attacks and problems + discussed in this document. + + + + + + + + + + + + +Schulzrinne, et al. Informational [Page 7] + +RFC 5765 Security in P2P Realtime Communications February 2010 + + + +---------------------------------------+---------------------------+ + | Solution name | Referring sections | + +---------------------------------------+---------------------------+ + | admission control | Section 3 | + | anonymity | Section 5.2 | + | asymmetric key pair | Section 7.2.5 | + | CAPTCHA | Section 3 | + | certificates | Section 7.2.3 | + | CONNECT (SIP method) | Section 7.2.4 | + | cryptographic puzzles | Section 4 | + | diametrically opposite IDs | Section 4 | + | end-to-end encryption | Section 7.2.4 | + | group authority | Section 3 | + | group charter | Section 3 | + | iterative routing | Section 7.2.2 | + | no profit for newcomers | Section 5.2 | + | online phone book | Section 7.2.5 | + | passive upgrades | Section 7.1.1 | + | peer promotion | Section 7.1 | + | proactive identification | Section 5.1.1 | + | reactive identification | Section 5.1.2 | + | recommendation | Section 3 | + | reputation management systems | Section 5.2 | + | self-policing | Section 5.2 | + | signatures | Section 3 | + | social networks (using) | Section 4, Section 6.2, | + | SRTP | Section 7.2.6 | + | structured reputation management | Section 5.2.2 | + | SybilGuard (protocol) | Section 4 | + | transitivity of trust | Section 5.2.2 | + | trust and distrust vectors | Section 5.2.1 | + | trust and trusted nodes | Section 3, Section 6.2, | + | | Section 7.2.3 | + | unstructured reputation management | Section 5.2.1 | + | voluntary moderators | Section 6.1 | + +---------------------------------------+---------------------------+ + + Table 3: Index of some of the more popular solutions discussed in + this document. + +2. The Attackers + +2.1. Incentive of the Attacker + + Attacks on networks happen for a variety of reasons such as monetary + gain, personal enmity, or even for fame in the hacker community. + + + + + +Schulzrinne, et al. Informational [Page 8] + +RFC 5765 Security in P2P Realtime Communications February 2010 + + + There are quite a few well-known cases of denial-of-service attacks + for extortion in the client-server model [McCue]. One of the salient + points of the P2P model is that the services it provides have higher + robustness against failure. However, denial-of-service attacks are + still possible against individuals within the overlay if the + attackers possess sufficient resources. For instance, a network of + worm-infected malicious nodes spread across the Internet and + controlled by an attacker (often referred to as botnet) could + simultaneously bombard lookup queries for a particular key in the + DHT. The peer responsible for this key would then come under a lot + of load and could crash [Sit]. However, with replication of key- + value pairs at multiple locations, such threats can be mitigated. + + Attackers may also have other incentives indirectly related to money. + With the growth of illegal usage of sharing files with copyrights, + record companies have been known to pollute content in the overlays + by putting up nodes with corrupt chunks of data but with correct file + names to degrade the service [Liang] and in hope that users would get + frustrated and stop using it. Similarly, competition between + different communication service providers, either or both based on + P2P technologies, and the low level of traceability of attacks + targeted to single users could be considered as motivation for + attempting service disruption. + + Attacks can also be launched by novice attackers who are attacking + the overlay for fun or fame in a community. These are perhaps less + likely to be successful or cause damage, since their resources tend + to be relatively limited. + +2.2. Resources Available to the Attacker + + Resource constraints play an important role in determining the nature + of the attack. An attacker who controls a botnet can use an Internet + relay channel and launch distributed denial-of-service attacks + against another node. With respect to attacks where a single node + impersonates multiple identities, as in the case of the Sybil attack + [Douceur] described in Section 4, IP addresses are also an important + resource for the attacker since in DHTs such as Chord [Stoica], the + position in the overlay is determined by using a base hash function + such as SHA-1 [SHA1] on the node's IP address. The cryptographic + puzzles [Rowaihy] that are sometimes suggested as a way to deter + Sybil attacks by making the join process harder are futile against an + attacker with a botnet and virtually unlimited computation power. + Douceur [Douceur] proves that even with the assumption that attackers + only have minimum resources at their disposal, it is not possible to + defend against them in a pure P2P system. + + + + + +Schulzrinne, et al. Informational [Page 9] + +RFC 5765 Security in P2P Realtime Communications February 2010 + + +2.3. Victim of the Attack + + The victim of an attack could be an individual node, a particular + content entry, or the entire overlay service. If malicious nodes are + strategically placed in the overlay, they can block a node from using + its services. Attacks could also be launched against specific + content [Sit] or even the entire overlay service. For example, if + the malicious nodes are randomly placed in the overlay and drop + packets or upload malicious content, then the quality of the overlay + would deteriorate. + +2.4. Time of Attack + + A malicious node could start misbehaving as soon as it enters the + overlay or it could follow the rules of the overlay for a finite + amount of time and then attack. The latter could prove to be more + harmful if the overlay design suggests accumulating trust in peers + based on the amount of time they have been present and/or not + misbehaving. In Kademlia [Maymounkov], for instance, the routing + tables are populated with nodes that have been up for a certain + amount of time. While this provides some robustness from attacks in + which the malicious nodes start dropping routing requests from the + moment they enter, it would take time for the algorithm to adapt to + nodes that start misbehaving in a later stage (i.e., after they have + been recorded in routing tables). Similarly for reputation + management systems, it is important that they adapt to the current + behavior of a peer. + +3. Admission Control + + Admission control depends on who decides whether or not to admit a + node and how this permission is granted. Kim et al. [Kim] answer + these questions independently of any particular environment or + application. They define two basic elements for admission in a peer + group, a group charter, which is an electronic document that + specifies the procedure of admission into the overlay, and a group + authority, which is an entity that can certify group admission. A + prospective member first gets a copy of the group charter, satisfies + the requirements, and approaches the group authority. The group + authority then verifies the admission request and grants a group + membership certificate. + + The group charter and authority verification can be provided by a + centralized certificate authority or a trusted third party, or it + could be provided by the peers themselves (by voting). The former is + more practical and tends to make the certification process simpler + although it is in violation of the pure P2P model and exposes the + system to attacks typical for server-based solutions (e.g., denial- + + + +Schulzrinne, et al. Informational [Page 10] + +RFC 5765 Security in P2P Realtime Communications February 2010 + + + of-service attacks targeted to the central authority). In the latter + case, the group authority could either be a fixed number of peers or + it could be a dynamic number based on the total membership of the + group. The authors argue that even if the group charter requires a + prospective member to get votes from peers, the group membership + certificate must be issued by a distinct entity. The reason for this + is that voters need to accompany their votes with a certificate that + proves their own membership. Possible signature schemes that could + be used in voting such as plain digital signature, threshold + signature, and accountable subgroup multisignature are also + described. Saxena et al. [Saxena] performed experiments with the + different signature schemes and suggest the use of plain signatures + for groups of moderate size and where bandwidth is not a concern. + For larger groups and where bandwidth is a concern, they suggest + threshold signature [Kong] and multisignature schemes [Ohta]. + + Another way of handling admission would be to use mechanisms based on + trust and recommendation where each new applicant has to be known and + vouched for by at least N existing members. The difficulties that + such models represent include identity assertion and preventing bot/ + worm attacks. A compromised node could have a valid certificate + identifying a trustworthy peer, and it would be difficult to detect + this. Possible solutions include sending graphic or logic puzzles + easily addressed by humans but hard to solve by computers, also known + as CAPTCHA [Ahn]; however, reliability of such mechanisms is at the + time of writing a topic of lively debate [Tam] [Chellapilla]. + +4. Determining the Position in the Overlay + + For ring-based DHT overlays such as Chord [Stoica], Kademlia + [Maymounkov], and Pastry [Rowstron], when a node joins the overlay, + it uses a numeric identifier (ID) to determine its position in the + ring. The positioning of a node determines what information it + stores and which nodes it serves. To provide a degree of robustness, + content and services are often replicated across multiple nodes. + However, it is possible for an adversary with sufficient resources to + undermine the redundancy deployed in the overlay by representing + multiple identities. Such an attack is called a Sybil attack + [Douceur]. This makes the assignment of IDs very important. One + possible scheme to tackle such attacks on the ID mapping is to have a + temporal mechanism in which nodes need to re-join the network after + some time [Condie] [Scheideler]. Such temporal solutions, however, + have the drawback that they increase the maintenance traffic and + possibly deteriorate the efficiency of caching. Danezis et al. + [Danezis] suggest mechanisms to mitigate the effect of Sybil attacks + by reducing the amount of information received from malicious nodes. + Their idea is to vary the nodes used for routing with time. This + helps avoiding trust bottlenecks that may occur when applications + + + +Schulzrinne, et al. Informational [Page 11] + +RFC 5765 Security in P2P Realtime Communications February 2010 + + + only route traffic through a limited set of highly trusted nodes. + Other solutions suggest making the joining process harder by + introducing cryptographic puzzles as suggested by Rowaihy et al. + [Rowaihy]. The assumption is that the adversary has limited + computational resources, which may not be true if the adversary has + control over a botnet. Another drawback of such methods is that non- + malicious nodes would also have to perform the extra computations + before they can join the overlay. + + A possible heuristic to hamper Sybil attacks is to employ redundancy + at nodes with diametrically opposite IDs (in the DHT ID space) + instead of successive IDs as in Chord. The idea behind choosing + diametrically opposite nodes is based on the fact that a malicious + peer can grant admission to others as its successor without them + actually possessing the required IP address (whose hash is adjacent + to the former's), and then they can cooperate to control access to + that part of the ring. If, however, admission decisions and + redundant content (for robustness) also involve nodes that are the + farthest away (diametrically opposite) from a given position, then + the adversary would require double resources (IP addresses) to + attack. This happens because the adversary would need presence in + the overlay at two independent positions in the ring. + + Another approach proposed by Yu et al. [Yu] to limit Sybil attacks + is based on the usage of the social relations between users. The + solution exploits the fact that as a result of Sybil attacks, + affected P2P overlays end up containing a large set of Sybil nodes + connected to the rest of the peers through an irregularly small + number of edges. The SybilGuard protocol [Yu] defines a method that + allows to discover such kinds of discontinuities in the topology by + using a special kind of a verifiable random walk and hence without + the need of one node having a global vision of the graph. + + It is also worth mentioning that in DHT overlays using different + geometric concepts (e.g., hypercubes instead of rings), peer + positions are usually not related to identifiers. In the content + addressable network (CAN) [Ratnasamy], for example, the position of + an entering node may be either selected by the node itself or, with + little modification to the original algorithm, assigned by peers + already in the overlay. However, even when malicious nodes do not + know their position before joining, the overlay is still vulnerable + to Sybil attacks. + +5. Resilience against Malicious Peers + + Making overlays robust against even a small percentage of malicious + nodes is difficult [Castro]. It is therefore important for other + peers to identify such nodes and keep track of their number. There + + + +Schulzrinne, et al. Informational [Page 12] + +RFC 5765 Security in P2P Realtime Communications February 2010 + + + are two aspects to this problem. One is the identification itself, + and the second is the dissemination of this information amongst the + peers. Different metrics need to be defined depending on the peer + group for the former, and reputation management systems are needed + for the latter. + +5.1. Identification of Malicious Peers + + For identifying a node as malicious, malicious activity has to be + observed first. This could be done in either a proactive way or a + reactive way. + +5.1.1. Proactive Identification + + When acting proactively, peers perform periodic operations with the + purpose of detecting malicious activity. A malicious node could + prevent access to content for which it is responsible (e.g., by + claiming the object doesn't exist), or return references to content + that does not match the original queries [Sit]. With this approach, + publishers of content can later perform lookups for it at periodic + intervals and verify the integrity of whatever is returned. Any + inconsistencies could then be interpreted as malicious activity. The + problem with proactive identification is the management of the + overhead it implies: if checks are performed too often, they may + actually hinder scalability, while, if they are performed too rarely, + they would probably be useless. + + An additional approach for mitigating routing attacks and identifying + malicious peers consists in sending multiple copies of the same + message on different paths. With such an approach, implemented, for + example, in Kademlia [Maymounkov], the sending peer can identify + anomalies comparing responses coming in from different paths. + +5.1.2. Reactive Identification + + In a reactive strategy, the peers perform normal operations and if + they happen to detect some malicious activity, then they can label + the responsible node as malicious and avoid sending any further + message to it. In a file-sharing application, for example, after + downloading content from a node, if the peer observes that data does + not match its original query it can identify the corresponding node + as malicious. Poon et al. [Poon] suggest a strategy based on the + forwarding of queries. If routing is done in an iterative way, then + dropping of packets, forwarding to an incorrect node, and delay in + forwarding arouse suspicion and the corresponding peer is identified + as malicious. + + + + + +Schulzrinne, et al. Informational [Page 13] + +RFC 5765 Security in P2P Realtime Communications February 2010 + + +5.2. Reputation Management Systems + + Reputation management systems are used to allow peers to share + information about other peers based on their own experience and thus + help in making better judgments. Most reputation management systems + proposed in the literature for file-sharing applications [Uzun] + [Damiani] [Lee] [Kamvar] aim at preventing misbehaving peers with low + reputation to rejoin the network with a different ID and therefore + start from a clean slate. To achieve this, Lee et al. [Lee] store + not only the reputation of a peer but also the reputation of files + based on file name and content to avoid spreading of a bad file. + Another method is to make the reputation of a new peer the minimum + possible. Kamvar et al. [Kamvar] define five design considerations + for reputation management systems: + + o The system should be self-policing. + + o The system should maintain anonymity. + + o The system should not assign any profit to newcomers. + + o The system should have minimal overhead in terms of computation, + infrastructure, storage, and message complexity. + + o The system should be robust to malicious collectives of peers who + know one another and attempt to collectively subvert the system. + +5.2.1. Unstructured Reputation Management + + Unstructured reputation management systems have been proposed by Uzun + et al. [Uzun] and Damiani et al. [Damiani]. The basic idea of + these is that each peer maintains information about its own + experience with other peers and resources, and shares it with others + on demand. In the system proposed by Uzun et al. [Uzun], each node + maintains trust and distrust vectors for every other node with which + it has interacted. When reputation information about a peer is + required, a node first checks its local database, and if insufficient + information is present, it sends a query to its neighbors just as it + would when looking up content. However, such an approach requires + peers to get reputation information from as many sources as possible; + otherwise, malicious nodes may successfully place targeted attacks + returning false values for their victims. + +5.2.2. Structured Reputation Management + + One of the problems with unstructured reputation management systems + is that they either take the feedback from few peers or, if they do + so from all, then they incur large traffic overhead. Systems such as + + + +Schulzrinne, et al. Informational [Page 14] + +RFC 5765 Security in P2P Realtime Communications February 2010 + + + those proposed by [Lee] [Kamvar] try to resolve it in a structured + manner. The idea of the eigen trust algorithm [Kamvar], for example, + is transitivity of trust. If a node trusts peer X, then it would + also trust the feedback it gives about other peers. A node builds + such information in an iterative way; for maintaining it in a + structured way, the authors propose to use a content addressable + network (CAN) DHT [Ratnasamy]. The information about each peer is + stored and replicated on different peers to provide robustness + against malicious nodes. They also suggest favoring peers + probabilistically with high trust values instead of doing it + deterministically, to allow new peers to slowly develop a reputation. + Eventually, they suggest the use of incentives for peers with high + reputation values. + +6. Routing and Data Integrity + + Preserving integrity of routing and data, or, in other words, + preventing peers from returning corrupt responses to queries and + routing through malicious peers, is an important security issue in + P2P networks. The data stored on a P2P overlay depends on the + applications that are using it. For file-sharing, this data would be + the files themselves, their location, and owner information. For + realtime communication, this would include user location bindings and + other routing information. We describe such data integrity issues in + Section 7. + +6.1. Data Integrity + + For file-sharing applications, insertion of wrong content (e.g., + files not matching their names or descriptions) and introduction of + corrupt data chunks (often referred to as poisoning and pollution) + are a significant problem. BitTorrent uses voluntary moderators to + weed out bogus files and the SHA-1 algorithm to determine the hash of + each piece of a file to allow verification of integrity. If a peer + detects a bad chunk, it can download that chunk from another peer. + With this strategy, different peers download different pieces of a + file before the original peer disappears from the network. However, + if a malicious peer modifies the pieces that are only available on it + and the original peer disappears, then the object distribution will + fail [Zhang]. An analysis of BitTorrent in terms of integrity and + performance can be found in the work of Pouwelse et al. [Pouwelse]. + +6.2. Routing Integrity + + To enhance the integrity of routing, it is important to reduce the + number of queries forwarded to malicious nodes. Marti et al. + [Marti] developed a system that uses social network information to + route queries over trusted nodes. Their algorithm uses trusted nodes + + + +Schulzrinne, et al. Informational [Page 15] + +RFC 5765 Security in P2P Realtime Communications February 2010 + + + to forward queries (if one exists and is closer to the required ID in + the ID space). Otherwise, they use the regular Chord [Stoica] + routing table to forward queries. While their results indicate good + average performance, it cannot guarantee log(N) hops for all cases. + Danezis et al. [Danezis] suggest a method for routing in the + presence of a large number of Sybil nodes. Their method is to ensure + that a peer queries a diverse set of nodes and does not place too + much trust in a node. Both the above works have been described based + on Chord. However, unlike Chord, in DHTs like Pastry [Rowstron] and + Kademlia [Maymounkov] there is flexibility in selecting nodes for any + row in a peer's routing table. Potentially many nodes have a common + ID prefix of a given length and are candidates for routing a given + query. To exploit the social network information and still guarantee + log(N) hops, a peer should select its friends to route a query, but + only when they are present in the appropriate row selected by the DHT + algorithm. + +7. Peer-to-Peer in Realtime Communication + + The idea of using P2P in realtime communication essentially implies + distributing centralized entities from conventional architectures + over P2P overlays and thus reducing the costs of deployment and + increasing reliability of the different services. Initiatives such + as the P2PSIP working group in IETF [P2PSIP] are currently + concentrating on achieving this by using a DHT for services such as + registration, location lookup, and support for NAT traversal, which + are normally handled by dedicated servers. + + Even if based on the same technology, overlays used for realtime + communication differ from those used for file-sharing in at least two + aspects: + + o Resource consumption. Contrary to file-sharing systems where the + DHT is used to store huge amounts of data (even if the distributed + database is used only for storing file locations, each user + usually indexes hundreds or thousands of files), realtime + communication overlays only require a subset of the resources + available at any given time as users only register a limited + number of locations (rarely more than one). + + o Confidentiality. In file-sharing applications, eavesdropping and + identity theft do not constitute real threats; after all, files + are supposed to be made publicly available. This is not true in + realtime communications, where the privacy and confidentiality of + the participants are of paramount importance. Furthermore, the + notion of identity plays an important role in realtime + + + + + +Schulzrinne, et al. Informational [Page 16] + +RFC 5765 Security in P2P Realtime Communications February 2010 + + + communications since it is the basis for starting a communication + session. As such, it is essential to have mechanisms to + unequivocally assert identities in realtime communication systems. + + In this section we go over the admission issues and security problems + discussed in previous sections, and discuss solutions that would be + applicable to realtime communication in P2P. + +7.1. Peer Promotion + + In order to remain compatible with existing user agents, P2P + communication architectures would have to allow certain nodes to use + their services without actually using overlay-specific semantics. + One way to achieve this would be for overlay-agnostic nodes to + register with an existing peer or a dedicated proxy via a standard + protocol like SIP [RFC3261]. Through the rest of this document, we + will refer to nodes that access the service without actually joining + the overlay as "clients". + + In most cases, users would be able to benefit from the overlay by + only acting as clients. However, in order to keep the solution + scalable, at some point clients would have to be promoted to peers + (admission to the DHT). This requires addressing the following + issues. + +7.1.1. Active vs. Passive Upgrades + + Most existing P2P networks [KAZAA] [BITTORRENT] [PPLIVE] would + generally leave it to the clients to determine if and when they would + apply for becoming peers. A well-known exception to this trend is + the Skype network [SKYPE], arguably one of the most popular overlay + networks used for realtime communications today. Instances of the + Skype application are supposed to operate as either super-nodes, + directly contributing to the distributed provision of the service, or + ordinary-nodes, simply using the service, and the "promotions" are + decided by the higher levels of the hierarchy [Baset]. Even if there + is not much difference for a client whether it has to actively ask + for authorization to join an overlay or passively wait for an + invitation, the latter approach has some advantages that fit well in + overlays where only a subset of the peers is required to provide the + service (as in realtime communication): + + o An attacker cannot estimate in advance when and if it would be + invited to join the overlay as a peer. + + o It allows peers to perform long-lasting measurements on sets of + candidates, in order to accurately select the most appropriate for + upgrading and only invite it when they are "ready" to do so. The + + + +Schulzrinne, et al. Informational [Page 17] + +RFC 5765 Security in P2P Realtime Communications February 2010 + + + opposite approach, that is, when clients initiate the join + themselves, adds an extra constraint for the peer that has to act + upon the request since it doesn't know if and when the peer would + attempt to join again. + + o It discourages malicious peers from attempting Sybil and, more + generally, brute force attacks, as only a small ratio of clients + has chances to join the overlay (possibly after an accurate + examination). + +7.1.2. When to Upgrade + + In order to answer this question, one would have to define some + criteria that would allow determination of the load on a peer and a + reasonable threshold. When the load exceeds this threshold, a client + is invited to become a peer and share the load. Several mechanisms + to diagnose the status of P2P systems have recently been proposed + [P2PSIP-DIAG]; in general, reasonable criteria for determining load + can be: + + o Number of clients attached. + + o Bandwidth usage for DHT maintenance, forwarding requests, and + responses to and from peers and from the attached clients. + + o Memory usage for DHT routing table, DHT neighborhood table, + application-specific data, and information about the attached + clients. + +7.1.3. Which Clients to Upgrade + + Selecting which clients to upgrade would require defining and keeping + track of new metrics. The exact set of metrics and how they + influence decisions should be the subject of serious analysis and + experimentation. These could be based on the following observations: + + o Uptime. A peer could easily record the amount of time that it has + been maintaining a connection with a client and take it into + account when trying to determine whether or not to upgrade it. + + o Level of activity. It is reasonable to assume that the more a + client uses the service (e.g., making phone calls), the less they + would be willing to degrade it. + + o Keeping track of history. Peers could record history of the + clients they invite and the way they contribute to the overlay. + + + + + +Schulzrinne, et al. Informational [Page 18] + +RFC 5765 Security in P2P Realtime Communications February 2010 + + + Other metrics such as public vs. private IP addresses, computation + power, and bandwidth should also be taken into account even though + they do not necessarily have a direct impact on security. + + Note however that a set of colluded malicious peers can manufacture + basically any criteria considered for the upgrade. Furthermore, + sophisticated peers can overload the system or run denial-of-service + attacks against existing super-nodes in order to improve their + chances of being upgraded. + +7.1.4. Incentives for Clients + + Clients need to have incentives for accepting upgrades in order to + prevent excessive burden on existing peers. One way to handle this + would be to maintain separate incentive management through the use of + currency or credits. Another option would involve embedding these + incentives inside the protocol itself: + + o Peers share with clients only a fraction of their bandwidth + (uplink and downlink). This would result in higher latency when + using the services of the overlay as a client and better service + quality for peers. + + o Peers could restrict the number or types of calls that they allow + clients to make. + + Introducing such incentives, however, may turn out to be somewhat + risky. Differences in quality would probably be perceptible for end + users who would not always be able to understand the difference + between the roles that their user agent is playing in the overlay. + Such behavior may therefore be interpreted as arbitrary and make the + service look unreliable. + +7.2. Security + +7.2.1. Targeted Denial of Service + + In addition to bombardment with queries as described in Section 2, + the denial-of-service attack against an individual node can be + conducted in DHTs if the peers that surround a particular ID are + compromised. These peers that act as proxy servers for the victim + can fake the responses from the victim by sending fictitious error + messages back to peers trying to establish a session. Danezis et + al.'s solution [Danezis] can also provide protection against such + attacks, as in their solution peers vary the nodes used in queries. + + + + + + +Schulzrinne, et al. Informational [Page 19] + +RFC 5765 Security in P2P Realtime Communications February 2010 + + +7.2.2. Man-in-the-Middle Attack + + The man-in-the-middle attack is well described by Seedorf [Seedorf1] + in the particular case of P2PSIP [P2PSIP] and consists of an attack + that exploits the lack of integrity when routing information. A + malicious node could return IP addresses of other malicious nodes + when queried for a particular ID. The requesting peer would then + establish a session with a second malicious node, which would again + return a "poisoned" reply. This could go on until the Time to Live + (TTL) expires and the requester gives up the "wild goose chase" + [Danezis]. A simple way for entities to verify the correctness of + the routing lookup is to employ iterative routing and to check the + node-ID of every routing hop that is returned, and it should get + closer to the desired ID with every hop. However, this is not a + strong check and can be defeated [Seedorf1]. + +7.2.3. Trust between Peers + + The effect of malicious peers could be mitigated by introducing the + concept of trust within an overlay. This can be done in different + ways: + + o Using certificates assigned by an external authority. The + drawback with this approach is that it requires a centralized + element. + + o Using certificates reciprocally signed by peers. This mechanism + is quite similar to PGP [Zimmermann]; every peer signs + certificates of "friend" peers and trusts any other peer with a + certificate signed by one of its friends. However, even though it + might be theoretically possible, in reality it is extremely + difficult to obtain long enough trust chains. + +7.2.4. Routing Call Signaling + + One way for implementing realtime communication overlays (as we have + mentioned in earlier sections) would be to simply replace centralized + entities in signaling protocols like SIP [RFC3261] with distributed + services. In some cases, this might imply reusing existing protocol + mechanisms for routing signaling messages. In the case of SIP, this + would imply regarding peers as SIP proxies. However, the design of + SIP supposes that such proxies are trusted, and makes it possible for + them to fork requests or change their destination, add or remove + header fields, act as the remote party, and generally manipulate + message content and semantics. + + + + + + +Schulzrinne, et al. Informational [Page 20] + +RFC 5765 Security in P2P Realtime Communications February 2010 + + + However, in a P2P environment where messages may be routed through + numerous successive peers, some of which might be compromised, it is + important not to treat them as trusted proxies. One way to limit + what peers can do is by protecting signaling with some kind of end- + to-end encryption. + + Another option would be to extend existing signaling protocols and + modify the way they route messages in order to guarantee secure end- + to-end transmission. Gurbani et al. [Gurbani] define a similar + mechanism for SIP that allows nodes to establish a secure channel by + sending a CONNECT SIP request, and then tunnel all SIP messages + through it, adopting a similar mechanism to the one used for + upgrading from HTTP to HTTPS [RFC2818]. + +7.2.5. Integrity of Location Bindings + + It is important to ensure that the location that a user registers, + usually a (URI, IP) pair, is what is returned to the requesting + party. Or the entities that issue the lookup request must be able to + verify the integrity of this pair. A pure P2P approach to allow + verification of the integrity of location binding information is + presented in [Seedorf2]. The idea is for an entity to choose an + asymmetric key pair and hash its public key to generate its URI. The + entity then signs its present location with its private key and + registers with the quadruple (URI, IP, signature, public key). Any + entity that looks up the URI and receives such a quadruple can then + verify its integrity by using the public key and the certificate. + Another possible merit of such an approach could be that it is + possible to identify the malicious nodes and maintain a black list. + However, the resulting URIs are not easy to remember and associate + with entities. Discovering these URIs and associating them with + entities would therefore require some sort of a directory service. + The authors suggest using existing authentication infrastructure for + this such as a certified web service using SSL that can publish an + "online phone book" mapping users to URIs. + +7.2.6. Encrypting Content + + Using P2P overlays for realtime communication implies that content is + likely to traverse numerous intermediate peers before reaching its + destination. A typical example could be the use of peers as media + relays as a way of traversing NATs in VoIP calls. + + Contrary to publicly shared files, communication sessions are in most + cases expected to be private. It is therefore very important to make + sure that no media leaves the client application without being + encrypted and securely transported through a protocol like SRTP + [RFC3711]. However, the processing required by the encryption + + + +Schulzrinne, et al. Informational [Page 21] + +RFC 5765 Security in P2P Realtime Communications February 2010 + + + algorithms and the extra resources necessary for managing the keying + material (e.g., for retrieving public keys when interacting with + unknown peers) may be expensive, especially for mobile devices. + +7.2.7. Other Issues + + Details on cost and payment regimes could help identify further + threats. Such details could also be important when determining the + impact of a potential attack in the context of the specific business + models associated with particular overlays. In many cases, answers + to the following simple questions significantly aid the design of + protection mechanisms: + + o Whom do the users pay? + + o Do the users only pay when accessing the public telephone network? + + o Is the billing done per call or is it fixed? + + For instance, the implications of an attack such as taking control + over another's user agent or its identity and using it for outbound + calls would depend on whether or not this would be economically + advantageous for the attacker. Baumann et al. [Baumann] suggest + that to prevent unwanted communication costs, gateways for the public + telephone network should only be accessible via authenticated servers + and dialing authorizations should be enforced. Also, it seems that + it would be difficult to do billing in a pure P2P manner as it would + mean keeping the billing details with untrusted peers. + +8. Open Issues + + Existing systems used for file-sharing, media streaming, and realtime + communications all achieve a reasonable level of security relying on + centralized components (e.g., login servers in Skype [Baset], + moderators and trackers in BitTorrent [Pouwelse]). Securing pure P2P + networks is therefore still a very active research field; at the time + of writing the main open issues fall in five areas: + + o Secure assignment of node IDs. + + o Entity-identity association. + + o Distributed trust among peers. + + o Resistance against malicious peer collusion. + + o Robustness and damage recovery. + + + + +Schulzrinne, et al. Informational [Page 22] + +RFC 5765 Security in P2P Realtime Communications February 2010 + + + In general, P2P overlays are designed to work when the vast majority + of their peers are interested in the service provided by the system + and act benevolently. Understanding how operations in different + overlays are perturbed as the number of malicious or compromised + peers grows is another interesting area of research. Also, a widely + adopted methodology for the evaluation and classification of security + solutions would be likely to help research in the field of P2P + security progress more efficiently. + +9. Security Considerations + + This document, tutorial in nature, discusses some of the security + issues of P2P systems used for realtime communications. It does not + aim at identifying all possible threats and the corresponding + solutions; instead, starting from an analysis of the attackers, it + delves into some important aspects of P2P security, referencing the + most relevant works published at the time of writing and discussing + how they apply (or could apply) to the case of realtime + communications. + +10. Acknowledgments + + The authors are particularly grateful to Dhruv Chopra, who + contributed to the writing of the article "Peer-to-peer Overlays for + Real-Time Communication: Security Issues and Solutions" (IEEE Surveys + & Tutorials, Vol. 11, No. 1) from which this work is partially + derived. + + The authors would also like to thank Vijay Gurbani and Song Haibin + for reviewing the document and the many others who provided useful + comments. + +11. Informative References + + [Ahn] Ahn, L., Blum, M., and J. Langford, "Telling humans + and computers apart automatically", Communications of + the ACM, vol. 47, no. 2, February 2004. + + [Androutsellis-Theotokis] + Androutsellis-Theotokis, S. and D. Spinellis, "A + survey of peer-to-peer content distribution + technologies", ACM CSUR, vol. 36, no. 4, + December 2004. + + [BITTORRENT] "BitTorrent", <http://www.bittorrent.com/>. + + + + + + +Schulzrinne, et al. Informational [Page 23] + +RFC 5765 Security in P2P Realtime Communications February 2010 + + + [Baset] Baset, S. and H. Schulzrinne, "An analysis of the + skype peer-to-peer internet telephony protocol", + Proceedings of IEEE INFOCOM 2006, April 2006. + + [Baumann] Baumann, R., Cavin, S., and S. Schmid, "Voice Over IP + - Security and SPIT", Technical Report, University of + Berne, September 2006. + + [COOLSTREAM] "COOLSTREAMING", <http://www.coolstreaming.us>. + + [Castro] Castro, M., Druschel, P., Ganesh, A., Rowstron, A., + and D. Wallach, "Secure routing for structured + peer-to-peer overlay networks", Proceedings of 5th + symposium on Operating systems design and + implementation, December 2002. + + [Chellapilla] Chellapilla, K. and P. Simard, "Using Machine Learning + to Break Visual Human Interaction Proofs (HIPs)", + Proceedings of Advances in Neural Information + Processing Systems, December 2004. + + [Condie] Condie, T., Kacholia, V., Sankararaman, S., + Hellerstein, J., and P. Maniatis, "Maelstorm: Churn as + Shelter", Proceedings of 13th Annual Network and + Distributed System Security Symposium, November 2005. + + [Damiani] Damiani, E., Vimercati, D., Paraboschi, S., Samarati, + P., and F. Violante, "A Reputation-Based Approach for + Choosing Reliable Resources in Peer-to-Peer Networks", + Proceedings of Conference on Computer and + Communications Security, November 2002. + + [Danezis] Danezis, G., Lesniewski-Laas, C., Kaashoek, M., and R. + Anderson, "Sybil-resistant DHT routing", Proceedings + of 10th European Symposium on Research in Computer + Security, September 2005. + + [Douceur] Douceur, J., "The Sybil Attack", Revised Papers + from First International Workshop on Peer-to-Peer + Systems, March 2002. + + [Gurbani] Gurbani, V., Willis, D., and F. Audet, + "Cryptographically Transparent Session Initiation + Protocol (SIP) Proxies", Proceedings of IEEE ICC '07, + June 2007. + + [KAZAA] "KaZaa", <http://www.kazaa.com/>. + + + + +Schulzrinne, et al. Informational [Page 24] + +RFC 5765 Security in P2P Realtime Communications February 2010 + + + [Kamvar] Kamvar, S., Garcia-Molina, H., and M. Schlosser, "The + EigenTrust Algorithm for Reputation Management in P2P + Networks", Proceedings of 12th international + conference on World Wide Web, May 2003. + + [Kim] Kim, Y., Mazzocchi, D., and G. Tsudik, "Admission + Control in Peer Groups", Proceedings of Second IEEE + International Symposium on Network Computing and + Applications, April 2003. + + [Kong] Kong, J., Zerfos, P., Luo, H., Lu, S., and L. Zhang, + "Providing robust and ubiquitous security support for + MANET", Proceedings of 9th International Conference on + Network Protocols, November 2001. + + [Lee] Lee, S., Kwon, O., Kim, J., and S. Hong, "A Reputation + Management System in Structured Peer-to-Peer + Networks", Proceedings of 14th IEEE International + Workshops on Enabling Technologies: Infrastructure for + Collaborative Enterprise, June 2005. + + [Liang] Liang, J., Kumar, R., Xi, Y., and K. Ross, "Pollution + in p2p file sharing systems", Proceedings of IEEE + INFOCOM 2005, March 2005. + + [Marti] Marti, S., Ganesan, P., and H. Garcia-Molina, "SPROUT: + P2P Routing with Social Networks", Proceedings + of First International Workshop on Peer-to-Peer and + Databases, March 2004. + + [Maymounkov] Maymounkov, P. and D. Mazi, "Kademlia: A Peer-to-peer + Information System Based on the XOR Metric", + Proceedings of First International Workshop on + Peer-to-peer Systems, March 2002. + + [McCue] McCue, Andy., "Bookie reveals 100,000 cost of + denial-of-service extortion attacks", available from + http://www.silicon.com, June 2004. + + [NAPSTER] "Napster", <http://www.napster.com/>. + + [Ohta] Ohta, K., Micali, S., and L. Reyzin, "Accountable + Subgroup Multisignatures", Proceedings of 8th ACM + conference on Computer and Communications Security, + November 2001. + + + + + + +Schulzrinne, et al. Informational [Page 25] + +RFC 5765 Security in P2P Realtime Communications February 2010 + + + [P2PSIP] "Peer-to-Peer Session Initiation Protocol (P2PSIP) + IETF Working Group", + <http://www.ietf.org/html.charters/ + p2psip-charter.html>. + + [P2PSIP-DIAG] Yongchao, S., Jiang, X., Even, R., and D. Bryan, + "P2PSIP Overlay Diagnostics", Work in Progress, + December 2009. + + [PPLIVE] "PPLive", <http://www.pplive.com>. + + [Poon] Poon, W. and R. Chang, "Robust Forwarding in + Structured Peer-to-Peer Overlay Networks", Proceedings + of ACM SIGCOMM 2004, August 2004. + + [Pouwelse] Pouwelse, J., Garbacki, P., Epema, D., and H. Sips, + "The Bittorent P2P File-Sharing System: Measurements + and Analysis", Proceedings of 4th International + Workshop of Peer-to-peer Systems, February 2005. + + [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., + Johnston, A., Peterson, J., Sparks, R., Handley, M., + and E. Schooler, "SIP: Session Initiation Protocol", + RFC 3261, June 2002. + + [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and + K. Norrman, "The Secure Real-time Transport Protocol + (SRTP)", RFC 3711, March 2004. + + [RFC4981] Risson, J. and T. Moors, "Survey of Research towards + Robust Peer-to-Peer Networks: Search Methods", + RFC 4981, September 2007. + + [Ratnasamy] Ratnasamy, S., Francis, P., Handley, M., Karp, R., and + S. Shenker, "A Scalable Content-Addressable Network", + Proceedings of ACM SIGCOMM 2001, January 2001. + + [Rowaihy] Rowaihy, H., Enck, W., McDaniel, P., and T. Porta, + "Limiting Sybil attacks in structured peer-to-peer + networks", Proceedings of IEEE INFOCOM 2007, May 2007. + + [Rowstron] Rowstron, A. and P. Druschel, "Pastry: Scalable, + distributed object location and routing for + large-scale peer-to-peer systems", Proceedings of 18th + IFIP/ACM International Conference on Distributed + Systems Platforms (Middleware 2001), November 2001. + + + +Schulzrinne, et al. Informational [Page 26] + +RFC 5765 Security in P2P Realtime Communications February 2010 + + + [SHA1] 180-1, FIPS., "Secure Hash Standard", April 2005. + + [SKYPE] "Skype", <http://www.skype.com/>. + + [Saxena] Saxena, N., Tsudik, G., and J. Yi, "Admission Control + in Peer-to-Peer: Design and Performance Evaluation", + Proceedings of 1st ACM workshop on Security of ad hoc + and sensor networks, October 2003. + + [Scheideler] Scheideler, C., "How to Spread Adversarial Nodes?: + Rotate!", Proceedings of 37th Annual ACM Symposium on + Theory of Computing, May 2005. + + [Seedorf1] Seedorf, J., "Security Challenges for Peer-to-Peer + SIP", IEEE Network, vol. 20, no. 5, September 2006. + + [Seedorf2] Seedorf, J., "Using Cryptographically Generated + SIP-URIs to Protect the Integrity of Content in + P2P-SIP", Proceedings of 3rd Annual VoIP Security + Workshop, June 2006. + + [Singh] Singh, K. and H. Schulzrinne, "Peer-to-Peer Internet + Telephony using SIP", Proceedings of International + Workshop on Network and Operating System Support for + Digital Audio and Video, June 2005. + + [Sit] Sit, E. and R. Morris, "Security considerations for + peer- to-peer distributed hash tables", Revised Papers + from First International Workshop on Peer-to-Peer + Systems, March 2002. + + [Stoica] Stoica, I., Morris, R., Karger, D., Kaashoek, M., and + H. Balakrishnan, "Chord: A Scalable Peer-to-peer + Lookup Service for Internet Applications", Proceedings + of Applications, Technologies, Architectures, and + Protocols for Computer Communication 2001, May 2001. + + [Tam] Tam, J., Simsa, J., Hyde, S., and L. Ahn, "Breaking + Audio CAPTCHAs with Machine Learning Techniques", + Proceedings of Advances in Neural Information + Processing Systems, December 2009. + + [Uzun] Uzun, E., Pariente, M., and A. Selpk, "A + Reputation-Based Trust Management System for P2P + Networks", Proceedings of International Symposium on + Cluster Computing and the Grids, April 2004. + + + + + +Schulzrinne, et al. Informational [Page 27] + +RFC 5765 Security in P2P Realtime Communications February 2010 + + + [Wallach] Wallach, D., "A Survey of Peer-to-Peer Security + Issues", Proceedings of International Symposium of + Software Security 2002, November 2002, + <http://www.cs.rice.edu/~dwallach/pub/ + tokyo-p2p2002.pdf>. + + [Yu] Yu, H., Kaminsky, M., Gibbons, P., and A. Flaxman, + "SybilGuard: Defending Against Sybil Attacks via + Social Networks", Proceedings of ACM SIGCOMM 2006, + September 2006. + + [Zhang] Zhang, X., Chen, S., and R. Sandhu, "Enhancing Data + Authenticity and Integrity in P2P Systems", IEEE + Internet Computing, vol. 9, no. 6, September 2005. + + [Zimmermann] Zimmermann, Philip., "Pretty good privacy: public key + encryption for the masses", Building in big brother: + the cryptographic policy debate pag. 103-107, 1995. + +Authors' Addresses + + Henning Schulzrinne + Columbia University + 1214 Amsterdam Avenue + New York, NY 10027 + USA + + EMail: hgs@cs.columbia.edu + + + Enrico Marocco + Telecom Italia + Via G. Reiss Romoli, 274 + Turin 10148 + Italy + + EMail: enrico.marocco@telecomitalia.it + + + Emil Ivov + SIP Communicator / University of Strasbourg + 4 rue Blaise Pascal + Strasbourg Cedex F-67070 + France + + EMail: emcho@sip-communicator.org + + + + + +Schulzrinne, et al. Informational [Page 28] + |