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