idnits 2.17.1 draft-irtf-p2prg-rtc-security-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 18, 2009) is 5333 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-22) exists of draft-ietf-p2psip-diagnostics-00 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Schulzrinne 3 Internet-Draft Columbia University 4 Intended status: Informational E. Marocco 5 Expires: March 22, 2010 Telecom Italia 6 E. Ivov 7 SIP Communicator / University of 8 Strasbourg 9 September 18, 2009 11 Security Issues and Solutions in Peer-to-peer Systems for Realtime 12 Communications 13 draft-irtf-p2prg-rtc-security-05 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on March 22, 2010. 38 Copyright Notice 40 Copyright (c) 2009 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents in effect on the date of 45 publication of this document (http://trustee.ietf.org/license-info). 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. 49 Abstract 51 Peer-to-peer networks have become popular for certain applications 52 and deployments for a variety of reasons, including fault tolerance, 53 economics, and legal issues. It has therefore become reasonable for 54 resource consuming and typically centralized applications like Voice 55 over IP (VoIP) and, in general, realtime communication to adapt and 56 exploit the benefits of P2P. Such a migration needs to address a new 57 set of P2P specific security problems. This document describes some 58 of the known issues found in common P2P networks, analyzing the 59 relevance of such issues and the applicability of existing solutions 60 when using P2P architectures for realtime communication. This 61 document is a product of the P2P Research Group. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.1. Purpose of this document . . . . . . . . . . . . . . . . . 6 67 1.2. Structure of this document . . . . . . . . . . . . . . . . 7 68 2. The attackers . . . . . . . . . . . . . . . . . . . . . . . . 8 69 2.1. Incentive of the attacker . . . . . . . . . . . . . . . . 9 70 2.2. Resources available to the attacker . . . . . . . . . . . 9 71 2.3. Victim of the attack . . . . . . . . . . . . . . . . . . . 10 72 2.4. Time of attack . . . . . . . . . . . . . . . . . . . . . . 10 73 3. Admission control . . . . . . . . . . . . . . . . . . . . . . 10 74 4. Determining the position in the overlay . . . . . . . . . . . 11 75 5. Resilience against malicious peers . . . . . . . . . . . . . . 13 76 5.1. Identification of malicious peers . . . . . . . . . . . . 13 77 5.1.1. Proactive identification . . . . . . . . . . . . . . . 13 78 5.1.2. Reactive identification . . . . . . . . . . . . . . . 13 79 5.2. Reputation management systems . . . . . . . . . . . . . . 14 80 5.2.1. Unstructured reputation management . . . . . . . . . . 14 81 5.2.2. Structured reputation management . . . . . . . . . . . 14 82 6. Routing and data integrity . . . . . . . . . . . . . . . . . . 15 83 6.1. Data integrity . . . . . . . . . . . . . . . . . . . . . . 15 84 6.2. Routing integrity . . . . . . . . . . . . . . . . . . . . 15 85 7. Peer-to-peer in realtime communication . . . . . . . . . . . . 16 86 7.1. Peer promotion . . . . . . . . . . . . . . . . . . . . . . 17 87 7.1.1. Active vs. passive upgrades . . . . . . . . . . . . . 17 88 7.1.2. When to upgrade . . . . . . . . . . . . . . . . . . . 18 89 7.1.3. Which clients to upgrade . . . . . . . . . . . . . . . 18 90 7.1.4. Incentives for clients . . . . . . . . . . . . . . . . 18 91 7.2. Security . . . . . . . . . . . . . . . . . . . . . . . . . 19 92 7.2.1. Targeted denial of service . . . . . . . . . . . . . . 19 93 7.2.2. Man in the middle attack . . . . . . . . . . . . . . . 19 94 7.2.3. Trust between peers . . . . . . . . . . . . . . . . . 19 95 7.2.4. Routing call signaling . . . . . . . . . . . . . . . . 20 96 7.2.5. Integrity of location bindings . . . . . . . . . . . . 20 97 7.2.6. Encrypting content . . . . . . . . . . . . . . . . . . 21 98 7.2.7. Other issues . . . . . . . . . . . . . . . . . . . . . 21 99 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 22 100 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 101 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 102 11. Informative references . . . . . . . . . . . . . . . . . . . . 23 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 105 1. Introduction 107 Peer-to-peer (P2P) overlays have become quite popular with the advent 108 of file-sharing applications such as Napster [NAPSTER], KaZaa [KAZAA] 109 and BitTorrent [BITTORRENT]. After their success in file-sharing and 110 content distribution [Androutsellis-Theotokis], P2P networks are now 111 also being used for applications such as Voice over IP (VoIP) [SKYPE] 112 [Singh] and television [PPLIVE] [COOLSTREAM]. However most of these 113 systems are not purely P2P and have centralized components like the 114 login server in Skype [Baset] or moderators and trackers in 115 BitTorrent [Pouwelse]. Securing pure P2P networks is therefore still 116 a field of very active research [Wallach]. 118 P2P overlays can be broadly classified as structured and unstructured 119 [RFC4981], depending on their routing model. Unstructured overlays 120 are often relatively simple but search operations in them, usually 121 based on flooding, tend to be inefficient. Structured P2P overlays 122 use distributed hash tables (DHT) [Stoica] [Maymounkov] [Rowstron] to 123 perform directed searches which make lookups more efficient in 124 locating data. This document will mostly focus on DHT-based P2P 125 overlays. 127 When analyzing the various attacks that are possible on P2P systems, 128 it is important to first understand the motivation of the attackers 129 as well as the resources (e.g. computation power, access to different 130 IP subnets, etc.) that they would have at their disposal. 132 Once the threat has been identified, admission control is a first 133 step towards security that can help avoid a substantial number of 134 attacks [Kim]. Most solutions rely on the assumption that malicious 135 nodes represent a small fraction of all peers. It is therefore 136 important to restrict their number in the overlay. 138 Other P2P specific security problems discussed here include attacks 139 on the routing of queries, targeted denial of service attacks and 140 attacks on data integrity. 142 In the remainder of this document, we outline the main security 143 issues and proposed solutions for P2P systems. Following this, we 144 focus on a particular class of P2P applications that provide realtime 145 communications. Realtime communications use the same DHTs used by 146 file-sharing applications, however, the data that is saved in these 147 DHTs is different. In realtime communications, the contents stored 148 in the DHTs comprises of user location, the DHT being the substitute 149 for a centralized registration server. 151 At first glance, it may appear that requirements on peer-to-peer 152 systems for realtime communications services are no different than 153 those for file-sharing services. Table 1 demonstrates that there are 154 sizeable differences related to privacy, availability, and a marked 155 increase in the general security requirements. 157 +-----------------+-----------------------+-------------------------+ 158 | | File-sharing | Realtime communication | 159 +-----------------+-----------------------+-------------------------+ 160 | Distributed | Shared file locations | User locations are | 161 | database | are indexed in a | indexed in a table | 162 | | table distributed | distributed among | 163 | | among peers; often | peers; rarely more than | 164 | | hundreds or thousands | one per peer. | 165 | | per peer. | | 166 | Availability | Same files are | Users are unique; | 167 | | usually available at | attacks targeting | 168 | | multiple locations | single users may be | 169 | | and failures | addressed both to the | 170 | | involving single | distributed index and | 171 | | instances are | to the user's device | 172 | | overcome by abundancy | directly. | 173 | | of resources; attacks | | 174 | | targeting single | | 175 | | files need to be | | 176 | | addressed to the | | 177 | | distributed index. | | 178 | Integrity | Attackers may want to | Attackers may want to | 179 | | share corrupted files | impersonate different | 180 | | in place of popular | users in order to | 181 | | content, e.g. to | handle calls directed | 182 | | discourage users from | to them; constitute a | 183 | | acquiring copyrighted | particular threat for | 184 | | material; constitute | the user as, in case of | 185 | | a threat for the | success, the attacker | 186 | | service, but not for | acquires full control | 187 | | the users. | on the victim's | 188 | | | personal | 189 | | | communications. | 190 | Confidentiality | Shared files are, by | Communications are | 191 | | definition, readable | usually meant to be | 192 | | by all users; in some | private and need to be | 193 | | cases encryption is | encrypted; | 194 | | used to avoid | eavesdropping may | 195 | | elements not involved | reveal sensitive data | 196 | | in the service to | and is a serious threat | 197 | | detect traffic. | for users. | 198 | Bitrate and | The file-transfer use | Realtime traffic almost | 199 | latency | case is particularly | always requires a | 200 | | tolerant to unstable | constant minimum | 201 | | bitrates and ability | bitrate and low latency | 202 | | to burst on and off | in order to avoid | 203 | | as peers disappear or | problems like jitter. | 204 | | new ones become | While this is not | 205 | | available. | directly related to a | 206 | | | specific sort of | 207 | | | attacks it is a | 208 | | | significant constraint | 209 | | | to the design of | 210 | | | certain design | 211 | | | solutions, and in | 212 | | | particular those that | 213 | | | somehow affect routing. | 214 | Peer lifetime | File-sharing users do | Realtime communication | 215 | | not need to stay in | applications need not | 216 | | the overlay more than | to leave the overlay | 217 | | the time required for | for as long as the user | 218 | | downloading the | wants to stay connected | 219 | | content they are | and be reachable. This | 220 | | looking for. | gives the attackers | 221 | | | longer time for | 222 | | | conducting successful | 223 | | | targeted attacks. | 224 +-----------------+-----------------------+-------------------------+ 226 Main differences between P2P applications used for file-sharing and 227 for realtime communication. 229 Table 1 231 1.1. Purpose of this document 233 The goal of this document is to provide authors of P2P protocols for 234 realtime communications with background that they may find useful 235 while designing security mechanisms for specific cases. The document 236 has been extensively discussed during face to face meetings and on 237 the P2PRG mailing list; it has been reviewed both substantially and 238 editorially by two members of the research group and reflects the 239 consensus of the group. 241 The content of this document was partially derived from the article 242 "Peer-to-peer Overlays for Real-Time Communications: Issues and 243 Solutions," published in IEEE Surveys & Tutorials, Vol. 11, No. 1 and 244 originally authored by Dhruv Chopra, Henning Schulzrinne, Enrico 245 Marocco, and Emil Ivov. 247 It is important to note that this document considers "security" from 248 the perspective of application developers and protocol architects. 249 It is hence entirely agnostic to potential legislation issues that 250 may apply when protecting applications against a specific attack, as, 251 for example, in the case of lawful interception. 253 1.2. Structure of this document 255 The document is organized as follows. In Section 2, we discuss P2P 256 security attackers. We try to elaborate on their motivation, the 257 resources that would generally be available to them, their victims 258 and the timing of their attacks. In Section 3, we discuss admission 259 control problems. In Section 4, we identify the problem of where a 260 node joins in the overlay. In Section 5, we describe problems 261 related to identification of malicious nodes and the dissemination of 262 this information. In Section 6, we describe the issues of routing 263 and data integrity in P2P networks. Finally, in Section 7 we discuss 264 how issues and solutions previously presented apply in P2P overlays 265 for realtime communication. 267 Table 2 and Table 3 provide an index of the attacks and the solutions 268 discussed in the rest of this document. 270 +---------------------------------------+---------------------------+ 271 | Attack name | Referring sections | 272 +---------------------------------------+---------------------------+ 273 | botnets (use of) | Section 2.1, Section 2.2 | 274 | denial of service (DoS) | Section 2.1, | 275 | | Section 7.2.1 | 276 | man in the middle (MITM) | Section 7.2.2 | 277 | poisoning | Section 2.1, Section 2.2 | 278 | pollution | Section 2.1, Section 2.2 | 279 | sybil | Section 2.2, Section 4 | 280 | targeted denial of service | Section 7.2.1 | 281 +---------------------------------------+---------------------------+ 283 Index of some of the more popular attacks and problems discussed in 284 this document. 286 Table 2 288 +---------------------------------------+---------------------------+ 289 | Solution name | Referring sections | 290 +---------------------------------------+---------------------------+ 291 | admission control | Section 3 | 292 | anonymity | Section 5.2 | 293 | asymmetric key pair | Section 7.2.5 | 294 | CAPTCHA | Section 3 | 295 | certificates | Section 7.2.3 | 296 | CONNECT (SIP method) | Section 7.2.4 | 297 | cryptographic puzzles | Section 4 | 298 | diametrically opposite IDs | Section 4 | 299 | end-to-end encryption | Section 7.2.4 | 300 | group authority | Section 3 | 301 | group charter | Section 3 | 302 | iterative routing | Section 7.2.2 | 303 | no profit for newcomers | Section 5.2 | 304 | online phone book | Section 7.2.5 | 305 | passive upgrades | Section 7.1.1 | 306 | peer promotion | Section 7.1 | 307 | proactive identification | Section 5.1.1 | 308 | reactive identification | Section 5.1.2 | 309 | recommendation | Section 3 | 310 | reputation management systems | Section 5.2 | 311 | self-policing | Section 5.2 | 312 | signatures | Section 3 | 313 | social networks (using) | Section 6.2, Section 4 | 314 | SRTP | Section 7.2.6 | 315 | structured reputation management | Section 5.2.2 | 316 | SybilGuard (protocol) | Section 4 | 317 | transitivity of trust | Section 5.2.2 | 318 | trust and distrust vectors | Section 5.2.1 | 319 | trust and trusted nodes | Section 3, Section 6.2, | 320 | | Section 7.2.3 | 321 | unstructured reputation management | Section 5.2.1 | 322 | voluntary moderators | Section 6.1 | 323 +---------------------------------------+---------------------------+ 325 Index of some of the more popular solutions discussed in this 326 document. 328 Table 3 330 2. The attackers 331 2.1. Incentive of the attacker 333 Attacks on networks happen for a variety of reasons such as monetary 334 gain, personal enmity or even for fame in the hacker community. 335 There are quite a few well known cases of denial of service attacks 336 for extortion in the client-server model [McCue]. One of the salient 337 points of the P2P model is that the services it provides have higher 338 robustness against failure. However, denial of service attacks are 339 still possible against individuals within the overlay if the 340 attackers possess sufficient resources. For instance, a network of 341 worm-infected malicious nodes spread across the Internet and 342 controlled by an attacker (often referred to as botnet) could 343 simultaneously bombard lookup queries for a particular key in the 344 DHT. The peer responsible for this key would then come under a lot 345 of load and could crash [Sit]. However with replication of key-value 346 pairs at multiple locations, such threats can be mitigated. 348 Attackers may also have other incentives indirectly related to money. 349 With the growth of illegal usage of sharing files with copyrights, 350 record companies have been known to pollute content in the overlays 351 by putting up nodes with corrupt chunks of data but with correct file 352 names to degrade the service [Liang] and in hope that users would get 353 frustrated and stop using it. Similarly, competition between 354 different communications service providers, either or both based on 355 P2P technologies, and the low level of traceability of attacks 356 targeted to single users could be considered as motivation for 357 attemping service disruption. 359 Attacks can also be launched by novice attackers who are attacking 360 the overlay for fun or fame in a community. These are perhaps less 361 likely to be successful or cause damage, since their resources tend 362 to be relatively limited. 364 2.2. Resources available to the attacker 366 Resource constraints play an important role in determining the nature 367 of the attack. An attacker who controls a botnet can use an Internet 368 relay channel and launch distributed denial of service attacks 369 against another node. With respect to attacks where a single node 370 impersonates multiple identities, as in the case of the Sybil attack 371 [Douceur] described in Section 4, IP addresses are also an important 372 resource for the attacker since in DHTs such as Chord [Stoica], the 373 position in the overlay is determined by using a base hash function 374 such as SHA-1 [SHA1] on the node's IP address. The cryptographic 375 puzzles [Rowaihy] that are sometimes suggested as a way to deter 376 Sybil attacks by making the join process harder are futile against an 377 attacker with a botnet and virtually unlimited computation power. 378 Doucer [Douceur] proves that even with the assumption that attackers 379 only have minimum resources at their disposal, it is not possible to 380 defend against them in a pure P2P system. 382 2.3. Victim of the attack 384 The victim of an attack could be an individual node, a particular 385 content entry or the entire overlay service. If malicious nodes are 386 strategically placed in the overlay, they can block a node from using 387 its services. Attacks could also be launched against specific 388 content [Sit] or even the entire overlay service. For example, if 389 the malicious nodes are randomly placed in the overlay and drop 390 packets or upload malicious content, then the quality of the overlay 391 would deteriorate. 393 2.4. Time of attack 395 A malicious node could start misbehaving as soon as it enters the 396 overlay or it could follow the rules of the overlay for a finite 397 amount of time and then attack. The latter could prove to be more 398 harmful if the overlay design suggests accumulating trust in peers 399 based on the amount of time they have been present and/or not 400 misbehaving. In Kademlia [Maymounkov], for instance, the routing 401 tables are populated with nodes that have been up for a certain 402 amount of time. While this provides some robustness from attacks in 403 which the malicious nodes start dropping routing requests from the 404 moment they enter, it would take time for the algorithm to adapt to 405 nodes which start misbehaving in a later stage (i.e., after they have 406 been recorded in routing tables). Similarly for reputation 407 management systems, it is important that they adapt to the current 408 behavior of a peer. 410 3. Admission control 412 Admission control depends on who decides whether or not to admit a 413 node and how this permission is granted. Kim et al. [Kim] answer 414 these questions independently of any particular environment or 415 application. They define two basic elements for admission in a peer 416 group, a group charter, which is an electronic document that 417 specifies the procedure of admission into the overlay, and a group 418 authority, which is an entity that can certify group admission. A 419 prospective member first gets a copy of the group charter, satisfies 420 the requirements and approaches the group authority. The group 421 authority then verifies the admission request and grants a group 422 membership certificate. 424 The group charter and authority verification can be provided by a 425 centralized certificate authority or a trusted third party, or it 426 could be provided by the peers themselves (by voting). The former is 427 more practical and tends to make the certification process simpler 428 although it is in violation of the pure P2P model and exposes the 429 system to attacks typical for server-based solutions (e.g., denial of 430 service attacks targeted to the central authority). In the latter 431 case, the group authority could either be a fixed number of peers or 432 it could be a dynamic number based on the total membership of the 433 group. The authors argue that even if the group charter requires a 434 prospective member to get votes from peers, the group membership 435 certificate must be issued by a distinct entity. The reason for this 436 is that voters need to accompany their votes with a certificate that 437 proves their own membership. Possible signature schemes that could 438 be used in voting such as plain digital signature, threshold 439 signature and accountable subgroup multisignature are also described. 440 Saxena et al. [Saxena] performed experiments with the different 441 signature schemes and suggest the use of plain signatures for groups 442 of moderate size and where bandwidth is not a concern. For larger 443 groups and where bandwidth is a concern, they suggest threshold 444 signature [Kong] and multisignature schemes [Ohta]. 446 Another way of handling admission would be to use mechanisms based on 447 trust and recommendation where each new applicant has to be known and 448 vouched for by at least N existing members. The difficulties that 449 such models represent include identity assertion and preventing bot/ 450 worm attacks. A compromised node could have a valid certificate 451 identifying a trustworthy peer and it would be difficult to detect 452 this. Possible solutions include sending graphic or logic puzzles 453 easily addressed by humans but hard to solve by computers, also known 454 as CAPTCHA [Ahn]; however, reliability of such mechanisms is at the 455 time of writing a topic of lively debate [Tam] [Chellapilla]. 457 4. Determining the position in the overlay 459 For ring based DHT overlays such as Chord [Stoica], Kademlia 460 [Maymounkov] and Pastry [Rowstron], when a node joins the overlay, it 461 uses a numeric identifier (ID) to determine its position in the ring. 462 The positioning of a node determines what information it stores and 463 which nodes it serves. To provide a degree of robustness, content 464 and services are often replicated across multiple nodes. However it 465 is possible for an adversary with sufficient resources to undermine 466 the redundancy deployed in the overlay by representing multiple 467 identities. Such an attack is called a Sybil attack [Douceur]. This 468 makes the assignment of IDs very important. One possible scheme to 469 tackle such attacks on the ID mapping is to have a temporal mechanism 470 in which nodes need to re-join the network after some time [Condie] 471 [Scheideler]. Such temporal solutions, however have the drawback 472 that they increase the maintenance traffic and possibly deteriorate 473 the efficiency of caching. Danezis et al. [Danezis] suggest 474 mechanisms to mitigate the effect of Sybil attacks by reducing the 475 amount of information received from malicious nodes. Their idea is 476 to vary the nodes used for routing with time. This helps avoiding 477 trust bottlenecks that may occur when applications only route traffic 478 through a limited set of highly trusted nodes. Other solutions 479 suggest making the joining process harder by introducing 480 cryptographic puzzles as suggested by Rowaihy et al. [Rowaihy]. The 481 assumption is that the adversary has limited computational resources 482 which may not be true if the adversary has control over a botnet. 483 Another drawback of such methods is that non-malicious nodes would 484 also have to perform the extra computations before they can join the 485 overlay. 487 A possible heuristic to hamper Sybil attacks is to employ redundancy 488 at nodes with diametrically opposite IDs (in the DHT ID space) 489 instead of successive IDs as in Chord. The idea behind choosing 490 diametrically opposite nodes is based on the fact that a malicious 491 peer can grant admission to others as its successor without them 492 actually possessing the required IP address (whose hash is adjacent 493 to the former's), and then they can cooperate to control access to 494 that part of the ring. If however admission decisions and redundant 495 content (for robustness), also involve nodes which are the furthest 496 away (diametrically opposite) from a given position, then the 497 adversary would require double resources (IP addresses) to attack. 498 This happens because the adversary would need presence in the overlay 499 at two independent positions in the ring. 501 Another approach proposed by Yu et al. [Yu]. to limit Sybil attacks 502 is based on the usage of the social relations between users. The 503 solutions exploits the fact that as a result of Sybil attacks, 504 affected P2P overlays end up containing a large set of Sybil nodes 505 connected to the rest of the peers through an irregularly small 506 number of edges. The SybilGuard protocol [Yu] defines a method that 507 allows to discover such kind of discontinuities in the topology by 508 using a special kind of a verifiable random walk and hence without 509 the need of one node having a global vision of the graph. 511 It is also worth mentioning that in DHT overlays using different 512 geometric concepts, (e.g., hypercubes instead of rings), peer 513 positions are usually not related to identifiers. In the content 514 addressable network (CAN) [Ratnasamy], for example, the position of 515 an entering node may be either selected by the node itself, or, with 516 little modification to the original algorithm, assigned by peers 517 already in the overlay. However, even when malicious nodes do not 518 know their position before joining, the overlay is still vulnerable 519 to Sybil attacks. 521 5. Resilience against malicious peers 523 Making overlays robust against even a small percentage of malicious 524 nodes is difficult [Castro]. It is therefore important for other 525 peers to identify such nodes and keep track of their number. There 526 are two aspects to this problem. One is the identification itself 527 and the second is the dissemination of this information amongst the 528 peers. Different metrics need to be defined depending on the peer 529 group for the former and reputation management systems are needed for 530 the latter. 532 5.1. Identification of malicious peers 534 For identifying a node as malicious, malicious activity has to be 535 observed first. This could be done in either a proactive way, or a 536 reactive way. 538 5.1.1. Proactive identification 540 When acting proactively, peers perform periodic operations with the 541 purpose of detecting malicious activity. A malicious node could 542 prevent access to content it is responsible for (e.g., by claiming 543 the object doesn't exist), or return references to content that does 544 not match the original queries [Sit]. With this approach, publishers 545 of content can later perform lookups for it at periodic intervals and 546 verify the integrity of whatever is returned. Any inconsistencies 547 could then be interpreted as malicious activity. The problem with 548 proactive identification is the management of the overhead it 549 implies: if checks are performed too often, they may actually hinder 550 scalability, while, if they are performed too rarely, they would 551 probably be useless. 553 An additional approach for mitigating routing attacks and identifying 554 malicious peers consists in sending multiple copies of the same 555 message on different paths. With such an approach, implemented for 556 example in Kademlia [Maymounkov], the sending peer can identify 557 anomalies comparing responses coming in from different paths. 559 5.1.2. Reactive identification 561 In a reactive strategy, the peers perform normal operations and if 562 they happen to detect some malicious activity, then they can label 563 the responsible node as malicious and avoid sending any further 564 message to it. In a file-sharing application for example, after 565 downloading content from a node, if the peer observes that data does 566 not match its original query it can identify the corresponding node 567 as malicious. Poon et al. [Poon] suggest a strategy based on the 568 forwarding of queries. If routing is done in an iterative way, then 569 dropping of packets, forwarding to an incorrect node and delay in 570 forwarding arouse suspicion and the corresponding peer is identified 571 as malicious. 573 5.2. Reputation management systems 575 Reputation management systems are used to allow peers to share 576 information about other peers based on their own experience and thus 577 help in making better judgments. Most reputation management systems 578 proposed in the literature for file-sharing applications [Uzun] 579 [Damiani] [Lee] [Kamvar] aim at preventing misbehaving peers with low 580 reputation to rejoin the network with a different ID and therefore 581 start from a clean slate. To achieve this, Lee et al. [Lee] store 582 not only the reputation of a peer but also the reputation of files 583 based on file name and content to avoid spreading of a bad file. 584 Another method is to make the reputation of a new peer the minimum 585 possible. Kamvar et al. [Kamvar] define five design considerations 586 for reputation management systems: 587 o The system should be self-policing. 588 o The system should maintain anonymity. 589 o The system should not assign any profit to newcomers. 590 o The system should have minimal overhead in terms of computation, 591 infrastructure, storage, and message complexity. 592 o The system should be robust to malicious collectives of peers who 593 know one another and attempt to collectively subvert the system. 595 5.2.1. Unstructured reputation management 597 Unstructured reputation management systems have been proposed by Uzun 598 et al. [Uzun] and Damiani et al. [Damiani]. The basic idea of 599 these is that each peer maintains information about its own 600 experience with other peers and resources, and shares it with others 601 on demand. In the system proposed by Uzun et al. [Uzun], each node 602 maintains trust and distrust vectors for every other node that it has 603 interacted with. When reputation information about a peer is 604 required, a node first checks its local database, and if insufficient 605 information is present, it sends a query to its neighbors just as it 606 would when looking up content. However, such an approach requires 607 peers to get reputation information from as many sources as possible; 608 otherwise, malicious nodes may successfully place targeted attacks 609 returning false values for their victims. 611 5.2.2. Structured reputation management 613 One of the problems with unstructured reputation management systems 614 is that they either take the feedback from few peers, or if they do 615 so from all, then they incur large traffic overhead. Systems such as 616 those proposed by [Lee] [Kamvar] try to resolve it in a structured 617 manner. The idea of the eigen trust algorithm [Kamvar] for example, 618 is transitivity of trust. If a node trusts peer X then it would also 619 trust the feedback it gives about other peers. A node builds such 620 information in an iterative way; for maintaining it in a structured 621 way, the authors propose to use a content addressable network (CAN) 622 DHT [Ratnasamy]. The information about each peer is stored and 623 replicated on different peers to provide robustness against malicious 624 nodes. They also suggest favoring peers probabilistically with high 625 trust values instead of doing it deterministically, to allow new 626 peers to slowly develop a reputation. Eventually, they suggest the 627 use of incentives for peers with high reputation values. 629 6. Routing and data integrity 631 Preserving integrity of routing and data, or, in other words, 632 preventing peers from returning corrupt responses to queries and 633 routing through malicious peers, is an important security issue in 634 P2P networks. The data stored on a P2P overlay depends on the 635 applications that are using it. For file-sharing, this data would be 636 the files themselves, their location, and owner information. For 637 realtime communication, this would include user location bindings and 638 other routing information. We describe such data integrity issues 639 separately in Section 7. 641 6.1. Data integrity 643 For file-sharing applications, insertion of wrong content (e.g. files 644 not matching their names or descriptions) or introduction of corrupt 645 data chunks (often referred to as poisoning and pollution) are a 646 significant problem. Bit-Torrent uses voluntary moderators to weed 647 out bogus files and the SHA-1 algorithm to determine the hash of each 648 piece of a file to allow verification of integrity. If a peer 649 detects a bad chunk, it can download that chunk from another peer. 650 With this strategy, different peers download different pieces of a 651 file before the original peer disappears from the network. However, 652 if a malicious peer modifies the pieces that are only available on it 653 and the original peer disappears, then the object distribution will 654 fail [Zhang]. An analysis of BitTorrent in terms of integrity and 655 performance can be found in the work of Pouwelse et al. [Pouwelse]. 657 6.2. Routing integrity 659 To enhance the integrity of routing, it is important to reduce the 660 number of queries forwarded to malicious nodes. Marti et al. 661 [Marti] developed a system that uses social network information to 662 route queries over trusted nodes. Their algorithm uses trusted nodes 663 to forward queries (if one exists and is closer to the required ID in 664 the ID space). Otherwise they use the regular Chord [Stoica] routing 665 table to forward queries. While their results indicate good average 666 performance, it can not guarantee log(N) hops for all cases. Danezis 667 et al. [Danezis] suggest a method for routing in the presence of a 668 large number of Sybil nodes. Their method is to ensure that a peer 669 queries a diverse set of nodes and does not place too much trust in a 670 node. Both the above works have been described based on Chord. 671 However, unlike Chord, in DHTs like Pastry [Rowstron] and Kademlia 672 [Maymounkov] there is flexibility in selecting nodes for any row in a 673 peer's routing table. Potentially many nodes have a common ID prefix 674 of a given length and are candidates for routing a given query. To 675 exploit the social network information and still guarantee log(N) 676 hops, a peer should select its friends to route a query, but only 677 when they are present in the appropriate row selected by the DHT 678 algorithm. 680 7. Peer-to-peer in realtime communication 682 The idea of using P2P in realtime communication essentially implies 683 distributing centralized entities from conventional architectures 684 over P2P overlays and thus reducing the costs of deployment and 685 increasing reliability of the different services. Initiatives such 686 as the P2PSIP working group in IETF [P2PSIP] are currently 687 concentrating on achieving this by using a DHT for services such as 688 registration, location lookup, and support for NAT traversal, which 689 are normally handled by dedicated servers. 691 Even if based on the same technology, overlays used for realtime 692 communication differ from those used for file-sharing in at least two 693 aspects: 694 o Resource consumption. Contrary to file-sharing systems where the 695 DHT is used to store huge amounts of data (even if the distributed 696 database is used only for storing file locations, each user 697 usually indexes hundreds or thousands of files), realtime 698 communication overlays only require a subset of the resources 699 available at any given time as users only register a limited 700 number of locations (rarely more than one). 701 o Confidentiality. In file-sharing applications, eavesdropping and 702 identity theft do not constitute real threats; after all, files 703 are supposed to be made publicly available. This is not true in 704 realtime communications, where the privacy and confidentiality of 705 the participants is of paramount importance. Furthermore, the 706 notion of identity plays an important role in realtime 707 communications since it is the basis for starting a communication 708 session. As such, it is essential to have mechanisms to 709 unequivocally assert identities in realtime communication systems. 711 In this section we go over the admission issues and security problems 712 discussed in previous sections, and discuss solutions that would be 713 applicable to realtime communication in P2P. 715 7.1. Peer promotion 717 In order to remain compatible with existing user agents, P2P 718 communication architectures would have to allow certain nodes to use 719 their services without actually using overlay specific semantics. 720 One way to achieve this would be for overlay agnostic nodes to 721 register with an existing peer or a dedicated proxy via a standard 722 protocol like SIP [RFC3261]. Through the rest of this document we 723 will refer to nodes that access the service without actually joining 724 the overlay as "clients". 726 In most cases users would be able to benefit from the overlay by only 727 acting as clients. However, in order to keep the solution scalable, 728 at some point clients would have to be promoted to peers (admission 729 to the DHT). This requires addressing the following issues. 731 7.1.1. Active vs. passive upgrades 733 Most existing P2P networks [KAZAA] [BITTORRENT] [PPLIVE] would 734 generally leave it to the clients to determine if and when they would 735 apply for becoming peers. A well known exception to this trend is 736 the Skype network [SKYPE], arguably one of the most popular overlay 737 networks used for realtime communications today. Instances of the 738 Skype application are supposed to operate as either super-nodes, 739 directly contributing to the distributed provision of the service, or 740 ordinary-nodes, simply using the service, and the "promotions" are 741 decided by the higher levels of the hierarchy [Baset]. Even if there 742 is not much difference for a client whether it has to actively ask 743 for authorization to join an overlay, or passively wait for an 744 invitation, the latter approach has some advantages which fit well in 745 overlays where only a subset of the peers is required to provide the 746 service (as in realtime communication): 747 o An attacker cannot estimate in advance when and if it would be 748 invited to join the overlay as a peer. 749 o Allows peers to perform long-lasting measurements on sets of 750 candidates, in order to accurately select the most appropriate for 751 upgrading and only invite it when they are "ready" to do so. The 752 opposite approach, that is when clients initiate the join 753 themselves, adds an extra constraint for the peer that has to act 754 upon the request since it doesn't know if and when the peer would 755 attempt to join again. 756 o Discourages malicious peers from attempting Sybil and, more 757 generally, brute force attacks, as only a small ratio of clients 758 has chances to join the overlay (possibly after an accurate 759 examination). 761 7.1.2. When to upgrade 763 In order to answer this question one would have to define some 764 criteria that would allow determination of the load on a peer and a 765 reasonable threshold. When the load exceeds this threshold, a client 766 is invited to become a peer and share the load. Several mechanisms 767 to diagnose the status of P2P systems have recently been proposed 768 [I-D.ietf-p2psip-diagnostics]; in general, reasonable criteria for 769 determining load can be: 770 o Number of clients attached. 771 o Bandwidth usage for DHT maintenance, forwarding requests and 772 responses to and from peers and from the attached clients. 773 o Memory usage for DHT routing table, DHT neighborhood table, 774 application specific data and information about the attached 775 clients. 777 7.1.3. Which clients to upgrade 779 Selecting which clients to upgrade would require defining and keeping 780 track of new metrics. The exact set of metrics and how they 781 influence decisions should be the subject of serious analysis and 782 experimentation. These could be based on the following observations: 783 o Uptime. A peer could easily record the amount of time that it has 784 been maintaining a connection with a client and take it into 785 account when trying to determine whether or not to upgrade it. 786 o Level of activity. It is reasonable to assume that the more a 787 client uses the service (e.g. making phone calls), the less they 788 would be willing to degrade it. 789 o Keeping track of history. Peers could record history of the 790 clients they invite and the way they contribute to the overlay. 791 Other metrics such as public vs. private IP addresses, computation 792 power, and bandwidth should also be taken into account even though 793 they do not necessarily have a direct impact on security. 795 Note however that a set of colluded malicious peers can manufacture 796 basically any criteria considered for the upgrade. Furthermore, 797 sophisticated peers can overload the system or run denial of service 798 attacks against existing super-nodes in order to improve their 799 chances of being upgraded. 801 7.1.4. Incentives for clients 803 Clients need to have incentives for accepting upgrades in order to 804 prevent excessive burden on existing peers. One way to handle this 805 would be to maintain separate incentive management through the use of 806 currency or credits. Another option would involve embedding these 807 incentives inside the protocol itself: 808 o Peers share with clients only a fraction of their bandwidth 809 (uplink and downlink). This would result in higher latency when 810 using the services of the overlay as a client and better service 811 quality for peers. 812 o Peers could restrict the number or types of calls that they allow 813 clients to make. 814 Introducing such incentives, however, may turn out to be somewhat 815 risky. Differences in quality would probably be perceptible for end 816 users who would not always be able to understand the difference 817 between the roles that their user agent is playing in the overlay. 818 Such behavior may therefore be interpreted as arbitrary and make the 819 service look unreliable. 821 7.2. Security 823 7.2.1. Targeted denial of service 825 In addition to bombardment with queries as described in Section 2, 826 the denial of service attack against an individual node can be 827 conducted in DHTs if the peers that surround a particular ID are 828 compromised. These peers that act as proxy servers for the victim, 829 can fake the responses from the victim by sending fictitious error 830 messages back to peers trying to establish a session. Danezis et 831 al.'s solution [Danezis] can also provide protection against such 832 attacks as in their solution peers vary the nodes used in queries. 834 7.2.2. Man in the middle attack 836 The man in the middle attack is well described by Seedorf [Seedorf1] 837 in the particular case of P2PSIP [P2PSIP] and consist of an attack 838 that exploits the lack of integrity when routing information. A 839 malicious node could return IP addresses of other malicious nodes 840 when queried for a particular ID. The requesting peer would then 841 establish a session with a second malicious node which would again 842 return a "poisoned" reply. This could go on until the TTL expires 843 and the requester gives up the "wild goose chase" [Danezis]. A 844 simple way for entities to verify the correctness of the routing 845 lookup is to employ iterative routing and to check the node-ID of 846 every routing hop that it is returned and it should get closer to the 847 desired ID with every hop. However, this is not a strong check and 848 can be defeated [Seedorf1]. 850 7.2.3. Trust between peers 852 The effect of malicious peers could be mitigated by introducing the 853 concept of trust within an overlay. This can be done in different 854 ways: 856 o Using certificates assigned by an external authority. The 857 drawback with this approach is that it requires a centralized 858 element. 859 o Using certificates reciprocally signed by peers. This mechanism 860 is quite similar to PGP [Zimmermann]; every peer signs 861 certificates of "friend" peers and trusts any other peer with a 862 certificate signed by one of its friends. However even though it 863 might be theoretically possible, in reality it is extremely 864 difficult to obtain long enough trust chains. 866 7.2.4. Routing call signaling 868 One way for implementing realtime communication overlays (as we have 869 mentioned in earlier sections) would be to simply replace centralized 870 entities in signalling protocols like SIP [RFC3261] with distributed 871 services. In some cases this might imply reusing existing protocol 872 mechanisms for routing signalling messages. In the case of SIP this 873 would imply regarding peers as SIP proxies. However the design of 874 SIP supposes that such proxies are trusted, and makes it possible for 875 them to fork requests or change their destination, add or remove 876 header fields, act as the remote party, and generally manipulate 877 message content and semantics 879 However, in a P2P environment where messages may be routed through 880 numerous successive peers, some of which might be compromised, it is 881 important not to treat them as trusted proxies. One way to limit 882 what peers can do is by protecting signalling with some kind of end- 883 to-end encryption. 885 Another option would be to extend existing signalling protocols and 886 modify the way they route messages in order to guarantee secure end- 887 to-end transmission. Gurbani et al. define a similar mechanism for 888 SIP [Gurbani] that allows nodes to establish a secure channel by 889 sending a CONNECT SIP request, and then tunnel all SIP messages 890 through it, adopting a similar mechanism to the one used for 891 upgrading from HTTP to HTTPS [RFC2818]. 893 7.2.5. Integrity of location bindings 895 It is important to ensure that the location that a user registers, 896 usually a (URI, IP) pair, is what is returned to the requesting 897 party. Or the entities that issue the lookup request must be able to 898 verify the integrity of this pair. A pure P2P approach to allow 899 verification of the integrity of location binding information is 900 presented in [Seedorf2]. The idea is for an entity to choose an 901 asymmetric key pair and hash its public key to generate its URI. The 902 entity then signs its present location with its private key and 903 registers with the quadruple (URI, IP, signature, public key). Any 904 entity which looks up for the URI and receives such a quadruple can 905 then verify its integrity by using the public key and the 906 certificate. Another possible merit of such an approach could be 907 that it is possible to identify the malicious nodes and maintain a 908 black list. However, the resulting URIs are not easy to remember and 909 associate with entities. Discovering these URIs and associating them 910 with entities would therefore require some sort of a directory 911 service. The authors suggest using existing authentication 912 infrastructure for this such as a certified web service using SSL 913 which can publish an "online phone book" mapping users to URIs. 915 7.2.6. Encrypting content 917 Using P2P overlays for realtime communication implies that content is 918 likely to traverse numerous intermediate peers before reaching its 919 destination. A typical example could be the use of peers as media 920 relays as a way of traversing NATs in VoIP calls. 922 Contrary to publicly shared files, communication sessions are in most 923 cases expected to be private. It is therefore very important to make 924 sure that no media leaves the client application without being 925 encrypted and securely transported through a protocol like SRTP 926 [RFC3711]. However, the extra processing resources required by the 927 encryption algorithms, the management of keying material (e.g., 928 retrieving public keys when interacting with unknown peers) may 929 constitute an expensive task, especially for mobile devices. 931 7.2.7. Other issues 933 Details on cost and payment regimes could help identifying further 934 threats. Such details could also be important when determining the 935 impact of a potential attack in the context of the specific business 936 models associated with particular overlays. In many cases answers to 937 the following simple questions significantly aid the design of 938 protection mechanisms: 939 o To whom do the users pay? 940 o Do the users only pay when accessing the public telephone network? 941 o Is the billing done per call or is it fixed? 942 For instance, the implications of an attack such as taking control 943 over another's user agent or its identity and using it for outbound 944 calls would depend on whether or not this would be economically 945 advantageous for the attacker. Baumann et al. [Baumann] suggests 946 that to prevent unwanted communication costs, gateways for the public 947 telephone network should only be accessible via authenticated servers 948 and dialing authorizations should be enforced. Also it seems that it 949 would be difficult to do billing in a pure P2P manner as it would 950 mean keeping the billing details with untrusted peers. 952 8. Open Issues 954 Existing systems used for file-sharing, media streaming and realtime 955 communications all achieve a reasonable level of security relying on 956 centralized components (e.g. login servers in Skype [Baset], 957 moderators and trackers in BitTorrent [Pouwelse]). Securing pure P2P 958 networks is therefore still a very active research field; at the time 959 of writing the main open issues fall in five areas: 960 o Secure assignment of node IDs. 961 o Entity-identity association. 962 o Distributed trust among peers. 963 o Resistance against malicious peer collusion. 964 o Robustness and damage recovery. 966 In general, P2P overlays are designed to work when the vast majority 967 of their peers are interested in the service provided by the system 968 and act benevolently. Understanding how operations in different 969 overlays are perturbed as the number of malicious or compromised 970 peers grows is another interesting area of research. Also, a widely 971 adopted methodology for the evaluation and classification of security 972 solutions would be likely to help research in the field of P2P 973 security progress more efficiently. 975 9. Security Considerations 977 This document, tutorial in nature, discusses some of the security 978 issues of P2P systems used for realtime communications. It does not 979 aim at identifying all possible threats and the corresponding 980 solutions; instead, starting from an analysis of the attackers, it 981 delves into some important aspects of P2P security, referencing the 982 most relevant works published at the time of writing and discussing 983 how they apply (or could apply) to the case of realtime 984 communications. 986 10. Acknowledgments 988 The authors are particularly grateful to Dhruv Chopra who contributed 989 to the writing of the article "Peer-to-peer Overlays for Real-Time 990 Communications: Issues and Solutions" (IEEE Surveys & Tutorials, Vol. 991 11, No. 1) this work is partially derived from. 993 The authors would also like to thank Vijay Gurbani and Song Haibin 994 for reviewing the document and the many others who provided useful 995 comments. 997 11. Informative references 999 [Ahn] Ahn, L., Blum, M., and J. Langford, "Telling humans and 1000 computers apart automatically", Communications of the 1001 ACM vol. 47, no. 2, February 2004. 1003 [Androutsellis-Theotokis] 1004 Androutsellis-Theotokis, S. and D. Spinellis, "A survey of 1005 peer-to-peer content distribution technologies", ACM 1006 CSUR vol. 36, no. 4, December 2004. 1008 [BITTORRENT] 1009 "BitTorrent", . 1011 [Baset] Baset, S. and H. Schulzrinne, "An analysis of the skype 1012 peer-to-peer internet telephony protocol", Proceedings 1013 of IEEE INFOCOM 2006, April 2006. 1015 [Baumann] Baumann, R., Cavin, S., and S. Schmid, "Voice Over IP - 1016 Security and SPIT", Technical Report, University of Berne, 1017 September 2006. 1019 [COOLSTREAM] 1020 "COOLSTREAMING", . 1022 [Castro] Castro, M., Druschel, P., Ganesh, A., Rowstron, A., and D. 1023 Wallach, "Secure routing for structured peer-to-peer 1024 overlay networks", Proceedings of 5th symposium on 1025 Operating systems design and implementation, 1026 December 2002. 1028 [Chellapilla] 1029 Chellapilla, K. and P. Simard, "Using Machine Learning to 1030 Break Visual Human Interaction Proofs (HIPs)", Proceedings 1031 of Advances in Neural Information Processing Systems, 1032 December 2004. 1034 [Condie] Condie, T., Kacholia, V., Sankararaman, S., Hellerstein, 1035 J., and P. Maniatis, "Maelstorm: Churn as Shelter", 1036 Proceedings of 13th Annual Network and Distributed System 1037 Security Symposium, November 2005. 1039 [Damiani] Damiani, E., Vimercati, D., Paraboschi, S., Samarati, P., 1040 and F. Violante, "A Reputation-Based Approach for Choosing 1041 Reliable Resources in Peer-to-Peer Networks", Proceedings 1042 of Conference on Computer and Communications Security, 1043 November 2002. 1045 [Danezis] Danezis, G., Lesniewski-Laas, C., Kaashoek, M., and R. 1046 Anderson, "Sybil-resistant DHT routing", Proceedings 1047 of 10th European Symposium on Research in Computer 1048 Security, September 2005. 1050 [Douceur] Douceur, J., "The Sybil Attack", Revised Papers from First 1051 International Workshop on Peer-to-Peer Systems, 1052 March 2002. 1054 [Gurbani] Gurbani, V., Willis, D., and F. Audet, "Cryptographically 1055 Transparent Session Initiation Protocol (SIP) Proxies", 1056 Proceedings of IEEE ICC '07, June 2007. 1058 [I-D.ietf-p2psip-diagnostics] 1059 Yongchao, S. and X. Jiang, "Diagnose P2PSIP Overlay 1060 Network", draft-ietf-p2psip-diagnostics-00 (work in 1061 progress), January 2009. 1063 [KAZAA] "KaZaa", . 1065 [Kamvar] Kamvar, S., Garcia-Molina, H., and M. Schlosser, "The 1066 EigenTrust Algorithm for Reputation Management in P2P 1067 Networks", Proceedings of 12th international conference on 1068 World Wide Web, May 2003. 1070 [Kim] Kim, Y., Mazzocchi, D., and G. Tsudik, "Admission Control 1071 in Peer Groups", Proceedings of Second IEEE International 1072 Symposium on Network Computing and Applications, 1073 April 2003. 1075 [Kong] Kong, J., Zerfos, P., Luo, H., Lu, S., and L. Zhang, 1076 "Providing robust and ubiquitous security support for 1077 MANET", Proceedings of 9th International Conference on 1078 Network Protocols, November 2001. 1080 [Lee] Lee, S., Kwon, O., Kim, J., and S. Hong, "A Reputation 1081 Management System in Structured Peer-to-Peer Networks", 1082 Proceedings of 14th IEEE International Workshops on 1083 Enabling Technologies: Infrastructure for Collaborative 1084 Enterprise, June 2005. 1086 [Liang] Liang, J., Kumar, R., Xi, Y., and K. Ross, "Pollution in 1087 p2p file sharing systems", Proceedings of IEEE INFOCOM 1088 2005, March 2005. 1090 [Marti] Marti, S., Ganesan, P., and H. Garcia-Molina, "SPROUT: P2P 1091 Routing with Social Networks", Proceedings of First 1092 International Workshop on Peer-to-Peer and Databases, 1093 March 2004. 1095 [Maymounkov] 1096 Maymounkov, P. and D. Mazi, "Kademlia: A Peer-to-peer 1097 Information System Based on the XOR Metric", Proceedings 1098 of First International Workshop on Peer-to-peer Systems, 1099 March 2002. 1101 [McCue] McCue, Andy., "Bookie reveals 100,000 cost of denial-of- 1102 service extortion attacks", June 2004, . 1105 [NAPSTER] "Napster", . 1107 [Ohta] Ohta, K., Micali, S., and L. Reyzin, "Accountable Subgroup 1108 Multisignatures", Proceedings of 8th ACM conference on 1109 Computer and Communications Security, November 2001. 1111 [P2PSIP] "Peer-to-Peer Session Initiation Protocol (P2PSIP) IETF 1112 Working Group", 1113 . 1115 [PPLIVE] "PPLive", . 1117 [Poon] Poon, W. and R. Chang, "Robust Forwarding in Structured 1118 Peer-to-Peer Overlay Networks", Proceedings of ACM SIGCOMM 1119 2004, August 2004. 1121 [Pouwelse] 1122 Pouwelse, J., Garbacki, P., Epema, D., and H. Sips, "The 1123 Bittorent P2P File-Sharing System: Measurements and 1124 Analysis", Proceedings of 4th International Workshop of 1125 Peer-to-peer Systems, February 2005. 1127 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1129 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1130 A., Peterson, J., Sparks, R., Handley, M., and E. 1131 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1132 June 2002. 1134 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1135 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1136 RFC 3711, March 2004. 1138 [RFC4981] Risson, J. and T. Moors, "Survey of Research towards 1139 Robust Peer-to-Peer Networks: Search Methods", RFC 4981, 1140 September 2007. 1142 [Ratnasamy] 1143 Ratnasamy, S., Francis, P., Handley, M., Karp, R., and S. 1144 Shenker, "A Scalable Content-Addressable Network", 1145 Proceedings of ACM SIGCOMM 2001, January 2001. 1147 [Rowaihy] Rowaihy, H., Enck, W., McDaniel, P., and T. Porta, 1148 "Limiting Sybil attacks in structured peer-to-peer 1149 networks", Proceedings of IEEE INFOCOM 2007, May 2007. 1151 [Rowstron] 1152 Rowstron, A. and P. Druschel, "Pastry: Scalable, 1153 distributed object location and routing for large-scale 1154 peer-to-peer systems", Proceedings of 18th IFIP/ACM 1155 International Conference on Distributed Systems Platforms 1156 (Middleware 2001), November 2001. 1158 [SHA1] 180-1, FIPS., "Secure Hash Standard", April 2005. 1160 [SKYPE] "Skype", . 1162 [Saxena] Saxena, N., Tsudik, G., and J. Yi, "Admission Control in 1163 Peer-to-Peer: Design and Performance Evaluation", 1164 Proceedings of 1st ACM workshop on Security of ad hoc and 1165 sensor networks, October 2003. 1167 [Scheideler] 1168 Scheideler, C., "How to Spread Adversarial Nodes?: 1169 Rotate!", Proceedings of 37th Annual ACM Symposium on 1170 Theory of Computing, May 2005. 1172 [Seedorf1] 1173 Seedorf, J., "Security Challenges for Peer-to-Peer SIP", 1174 IEEE Network vol. 20, no. 5, September 2006. 1176 [Seedorf2] 1177 Seedorf, J., "Using Cryptographically Generated SIP-URIs 1178 to Protect the Integrity of Content in P2P-SIP", 1179 Proceedings of 3rd Annual VoIP Security Workshop, 1180 June 2006. 1182 [Singh] Singh, K. and H. Schulzrinne, "Peer-to-Peer Internet 1183 Telephony using SIP", Proceedings of International 1184 Workshop on Network and Operating System Support for 1185 Digital Audio and Video, June 2005. 1187 [Sit] Sit, E. and R. Morris, "Security considerations for peer- 1188 to-peer distributed hash tables", Revised Papers 1189 from First International Workshop on Peer-to-Peer Systems, 1190 March 2002. 1192 [Stoica] Stoica, I., Morris, R., Karger, D., Kaashoek, M., and H. 1193 Balakrishnan, "Chord: A Scalable Peer-to-peer Lookup 1194 Service for Internet Applications", Proceedings 1195 of Applications, Technologies, Architectures, and 1196 Protocols for Computer Communication 2001, May 2001. 1198 [Tam] Tam, J., Simsa, J., Hyde, S., and L. Ahn, "Breaking Audio 1199 CAPTCHAs with Machine Learning Techniques", Proceedings 1200 of Advances in Neural Information Processing Systems, 1201 December 2009. 1203 [Uzun] Uzun, E., Pariente, M., and A. Selpk, "A Reputation-Based 1204 Trust Management System for P2P Networks", Proceedings 1205 of International Symposium on Cluster Computing and the 1206 Grids, April 2004. 1208 [Wallach] Wallach, D., "A Survey of Peer-to-Peer Security Issues", 1209 Proceedings of International Symposium of Software 1210 Security 2002, November 2002, 1211 . 1213 [Yu] Yu, H., Kaminsky, M., Gibbons, P., and A. Flaxman, 1214 "SybilGuard: Defending Against Sybil Attacks via Social 1215 Networks", Proceedings of ACM SIGCOMM 2006, 1216 September 2006. 1218 [Zhang] Zhang, X., Chen, S., and R. Sandhu, "Enhancing Data 1219 Authenticity and Integrity in P2P Systems", IEEE Internet 1220 Computing vol. 9, no. 6, September 2005. 1222 [Zimmermann] 1223 Zimmermann, Philip., "Pretty good privacy: public key 1224 encryption for the masses", Building in big brother: the 1225 cryptographic policy debate pag. 103-107, 1995. 1227 Authors' Addresses 1229 Henning Schulzrinne 1230 Columbia University 1231 1214 Amsterdam Avenue 1232 New York, NY 10027 1233 USA 1235 Email: hgs@cs.columbia.edu 1236 Enrico Marocco 1237 Telecom Italia 1238 Via G. Reiss Romoli, 274 1239 Turin 10148 1240 Italy 1242 Email: enrico.marocco@telecomitalia.it 1244 Emil Ivov 1245 SIP Communicator / University of Strasbourg 1246 4 rue Blaise Pascal 1247 Strasbourg Cedex F-67070 1248 France 1250 Email: emcho@sip-communicator.org