idnits 2.17.1
draft-schulzrinne-p2prg-rtc-security-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
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 (February 22, 2009) is 5542 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: 'SHA1' is defined on line 945, but no explicit
reference was found in the text
-- Obsolete informational reference (is this intentional?): RFC 2818
(Obsoleted by RFC 9110)
Summary: 1 error (**), 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: August 26, 2009 Telecom Italia
6 E. Ivov
7 SIP Communicator
8 February 22, 2009
10 Security Issues and Solutions in Peer-to-peer Systems for Realtime
11 Communications
12 draft-schulzrinne-p2prg-rtc-security-00
14 Status of this Memo
16 This Internet-Draft is submitted to IETF in full conformance with the
17 provisions of BCP 78 and BCP 79. This document may not be modified,
18 and derivative works of it may not be created, except to format it
19 for publication as an RFC and to translate it into languages other
20 than English.
22 Internet-Drafts are working documents of the Internet Engineering
23 Task Force (IETF), its areas, and its working groups. Note that
24 other groups may also distribute working documents as Internet-
25 Drafts.
27 Internet-Drafts are draft documents valid for a maximum of six months
28 and may be updated, replaced, or obsoleted by other documents at any
29 time. It is inappropriate to use Internet-Drafts as reference
30 material or to cite them other than as "work in progress."
32 The list of current Internet-Drafts can be accessed at
33 http://www.ietf.org/ietf/1id-abstracts.txt.
35 The list of Internet-Draft Shadow Directories can be accessed at
36 http://www.ietf.org/shadow.html.
38 This Internet-Draft will expire on August 26, 2009.
40 Copyright Notice
42 Copyright (c) 2009 IETF Trust and the persons identified as the
43 document authors. All rights reserved.
45 This document is subject to BCP 78 and the IETF Trust's Legal
46 Provisions Relating to IETF Documents
47 (http://trustee.ietf.org/license-info) in effect on the date of
48 publication of this document. Please review these documents
49 carefully, as they describe your rights and restrictions with respect
50 to this document.
52 Abstract
54 Peer-to-peer (P2P) networks offer higher robustness against failure,
55 easier configuration and are generally more economical than their
56 client-server counterparts. It has therefore become reasonable for
57 resource consuming and typically centralized applications like Voice
58 over IP (VoIP) and, in general, realtime communication to adapt and
59 exploit the benefits of P2P. Such a migration needs to address a new
60 set of P2P specific security problems. This document describes some
61 of the known issues found in common P2P networks, analyzing the
62 relevance of such issues and the applicability of existing solutions
63 when using P2P architectures for realtime communication.
65 Table of Contents
67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
68 1.1. Purpose of this document . . . . . . . . . . . . . . . . . 6
69 2. The attackers . . . . . . . . . . . . . . . . . . . . . . . . 6
70 2.1. Incentive of the attacker . . . . . . . . . . . . . . . . 6
71 2.2. Resources available to the attacker . . . . . . . . . . . 7
72 2.3. Victim of the attack . . . . . . . . . . . . . . . . . . . 7
73 2.4. Time of attack . . . . . . . . . . . . . . . . . . . . . . 7
74 3. Admission control . . . . . . . . . . . . . . . . . . . . . . 8
75 4. Determining the position in the overlay . . . . . . . . . . . 9
76 5. Resilience against malicious peers . . . . . . . . . . . . . . 10
77 5.1. Identification of malicious peers . . . . . . . . . . . . 10
78 5.1.1. Proactive identification . . . . . . . . . . . . . . . 10
79 5.1.2. Reactive identification . . . . . . . . . . . . . . . 11
80 5.2. Reputation management systems . . . . . . . . . . . . . . 11
81 5.2.1. Unstructured reputation management . . . . . . . . . . 11
82 5.2.2. Structured reputation management . . . . . . . . . . . 12
83 6. Routing and data integrity . . . . . . . . . . . . . . . . . . 12
84 6.1. Data integrity . . . . . . . . . . . . . . . . . . . . . . 12
85 6.2. Routing integrity . . . . . . . . . . . . . . . . . . . . 13
86 7. Peer-to-peer in realtime communication . . . . . . . . . . . . 13
87 7.1. Admission . . . . . . . . . . . . . . . . . . . . . . . . 14
88 7.1.1. Active vs. passive upgrades . . . . . . . . . . . . . 14
89 7.1.2. When to upgrade . . . . . . . . . . . . . . . . . . . 15
90 7.1.3. Which clients to upgrade . . . . . . . . . . . . . . . 15
91 7.1.4. Incentives for clients . . . . . . . . . . . . . . . . 15
92 7.2. Security . . . . . . . . . . . . . . . . . . . . . . . . . 16
93 7.2.1. Targeted denial of service . . . . . . . . . . . . . . 16
94 7.2.2. Man in the middle attack . . . . . . . . . . . . . . . 16
95 7.2.3. Trust between peers . . . . . . . . . . . . . . . . . 16
96 7.2.4. Routing call signalization . . . . . . . . . . . . . . 17
97 7.2.5. Integrity of location bindings . . . . . . . . . . . . 17
98 7.2.6. Encrypting content . . . . . . . . . . . . . . . . . . 18
99 7.2.7. Other issues . . . . . . . . . . . . . . . . . . . . . 18
100 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
101 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
102 10. Informative references . . . . . . . . . . . . . . . . . . . . 19
103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
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 [JOOST] [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]. P2P overlays can be
117 broadly classified as structured and unstructured. Unstructured
118 overlays are often relatively simple but search operations in them
119 tend to be inefficient. Structured P2P overlays use distributed hash
120 tables (DHT) to perform directed searches which make lookups more
121 efficient in locating data. This document will mostly focus on DHT-
122 based P2P overlays.
124 When analyzing the various attacks that are possible on P2P systems,
125 it is important to first understand the motivation of the attackers
126 as well as the resources (i.e. computation power, access to different
127 IP subnets) that they would have at their disposal.
129 Once the threat has been identified, admission control is the first
130 step towards security [Kim]. Most solutions rely on the assumption
131 that malicious nodes represent a small fraction of all peers. It is
132 therefore important to restrict their number in the overlay.
134 Other P2P specific security problems discussed here include attacks
135 on the routing of queries, targeted denial of service attacks and
136 attacks on data integrity.
138 This document, after discussing some of the main security issues and
139 proposed solutions for P2P systems in general, focuses on one
140 particular application -- realtime communication. The idea behind
141 P2P realtime communication is using the DHTs employed by file-sharing
142 applications, in order to implement services such as registration,
143 user location lookup, and assistance with NAT and firewall traversal.
144 Even if, from a technical point of view, P2P communication services
145 may seem similar to file-sharing, Table 1 shows that some important
146 differences, mostly related to privacy and availability,
147 significantly increase security requirements.
149 +-----------------+-----------------------+-------------------------+
150 | | File-sharing | Realtime communication |
151 +-----------------+-----------------------+-------------------------+
152 | Distributed | Shared file locations | User locations are |
153 | database | are indexed in a | indexed in a table |
154 | | table distributed | distributed among |
155 | | among peers; often | peers; rarely more than |
156 | | hundreds or thousands | one per user. |
157 | | per user. | |
158 | Availability | Same files are | Users are unique; |
159 | | usually available at | attacks targeting |
160 | | multiple locations | single users may be |
161 | | and failures | addressed both to the |
162 | | involving single | distributed index and |
163 | | istances are overcame | to the user's device |
164 | | by abundancy of | directly. |
165 | | resources; attacks | |
166 | | targeting single | |
167 | | files need to be | |
168 | | addressed to the | |
169 | | distributed index. | |
170 | Integrity | Attackers may want to | Attackers may want to |
171 | | share corrupted files | impersonate different |
172 | | in place of popular | users in order to |
173 | | content, e.g. to | handle calls directed |
174 | | discourage users from | to them; constitute a |
175 | | acquiring copyrighted | particular threat for |
176 | | material; constitute | the user as, in case of |
177 | | a threat for the | success, the attacker |
178 | | service, but not for | acquires full control |
179 | | the users. | on the victim's |
180 | | | personal |
181 | | | communications. |
182 | Confidentiality | Shared files are, by | Communications are |
183 | | definition, readable | usually meant to be |
184 | | by all users; in some | private and need to be |
185 | | cases encryption is | encrypted; evesdropping |
186 | | used to avoid | may reveal sensitive |
187 | | elements not involved | data and is a serious |
188 | | in the service to | threat for users. |
189 | | detect traffic. | |
190 +-----------------+-----------------------+-------------------------+
192 Main differences between P2P applications used for file-sharing and
193 for realtime communication.
195 Table 1
197 The rest of the document is organized as follows. In Section 2, we
198 discuss P2P security attackers. We try to elaborate on their
199 motivation, the resources that would generally be available to them,
200 their victims and the timing of their attacks. In Section 3, we
201 discuss admission control problems. In Section 4, we identify the
202 problem of where a node joins in the overlay. In Section 5, we
203 describe problems related to identification of malicious nodes and
204 the dissemination of this information. In Section 6, we describe the
205 issues of routing and data integrity in P2P networks. Finally, in
206 Section 7 we discuss how issues and solutions previously presented
207 apply in P2P overlays for realtime communication.
209 1.1. Purpose of this document
211 This document is partially derived from the article "Peer-to-peer
212 Overlays for Real-Time Communications: Issues and Solutions,"
213 published in IEEE Surveys & Tutorials, Vol. 11, No. 1 and originally
214 authored by Dhruv Chopra, Henning Schulzrinne, Enrico Marocco and
215 Emil Ivov. Its goal is to collect feedback from the IRTF community
216 in order to document the advances in the field of security of P2P
217 systems for realtime communications, for the benefit of related
218 standardization activities going on in IETF.
220 2. The attackers
222 2.1. Incentive of the attacker
224 Attacks on networks happen for a variety of reasons such as monetary
225 gain, personal enmity or even for fame in the hacker community.
226 There are quite a few well known cases of denial of service attacks
227 for extortion in the client-server model [McCue]. One of the salient
228 points of the P2P model is that the services it provides have higher
229 robustness against failure. However, such attacks are still possible
230 against individuals within the overlay if the attackers possess
231 sufficient resources. For instance, a network of worm-affected
232 malicious nodes spread across the Internet and controlled by an
233 attacker (often referred as botnet), could simultaneously bombard
234 lookup queries for a particular key in the DHT. The peer responsible
235 for this key would then come under a lot of load and could crash
236 [Sit]. However with replication of key-value pairs at multiple
237 locations, such threats can be mitigated.
239 Attackers may also have other incentives apart from money. With the
240 growth of illegal usage of sharing files with copyrights, record
241 companies have been known to attempt polluting content in the
242 overlays by putting up nodes with corrupt chunks of data but with
243 correct file names to degrade the service [Liang] and in hope that
244 users would get frustrated and stop using the service. Attacks can
245 also be launched by novice attackers who are there attacking the
246 overlay for fun or fame in a community. These are perhaps less
247 likely to be successful or cause damage, since their resources tend
248 to be relatively limited.
250 2.2. Resources available to the attacker
252 Resource constraints play an important role in determining the nature
253 of the attack. An attacker who controls a botnet can use an Internet
254 relay channel and launch distributed denial of service attacks
255 against another node. With respect to attacks where a single node
256 impersonates multiple identities, as in the case of the sybil attack
257 [Douceur] described in Section 4, IP addresses are also an important
258 resource for the attacker since in DHTs such as Chord [Stoica], the
259 position in the overlay is determined by using a base hash function
260 such as SHA-1 [SHA1]on the node's IP address. The cryptographic
261 puzzles [Rowaihy] that are sometimes suggested as a way to deter
262 sybil attacks by making the join process harder are futile against an
263 attacker with a botnet and virtually unlimited computation power.
264 Doucer [Douceur] proves that even with the assumption that attackers
265 only have minimum resources at their disposal, it is not possible to
266 defend against them in a pure P2P system.
268 2.3. Victim of the attack
270 The victim of an attack could be an individual node, a particular
271 content entry or the entire overlay service. If malicious nodes are
272 strategically placed in the overlay, they can block a node from using
273 its services. Attacks could also be launched against specific
274 content [Sit] or even the entire overlay service. For example, if
275 the malicious nodes are randomly placed in the overlay and drop
276 packets or upload malcontent, then the quality of the overlay would
277 deteriorate.
279 2.4. Time of attack
281 A malicious node could start misbehaving as soon as it enters the
282 overlay or it could follow the rules of the overlay for a finite
283 amount of time and then attack. The latter could prove to be more
284 harmful if the overlay design suggests accumulating trust in peers
285 based on the amount of time they have been present and/or not
286 misbehaving. In Kademlia [KADEMLIA], for instance, the routing
287 tables are populated with nodes that have been up for a certain
288 amount of time. While this provides some robustness from attacks in
289 which the malicious nodes start dropping routing requests from the
290 moment they enter, it would take time for the algorithm to adapt to
291 nodes which start misbehaving in a later stage (i.e., after they have
292 been recorded in routing tables). Similarly for reputation
293 management systems, it is important that they adapt to the current
294 behavior of a peer.
296 3. Admission control
298 Admission control depends on who decides whether or not to admit a
299 node and how this permission is granted. Kim et. al [Kim] answer
300 these questions independently of any particular environment or
301 application. They define two basic elements for admission in a peer
302 group, a group charter, which is an electronic document that
303 specifies the procedure of admission into the overlay, and a group
304 authority, which is an entity that can certify group admission. A
305 prospective member first gets a copy of the group charter, satisfies
306 the requirements and approaches the group authority. The group
307 authority then verifies the admission request and grants a group
308 membership certificate.
310 The group charter and authority verification can be provided by a
311 centralized certificate authority or a trusted third party, or it
312 could be provided by the peers themselves (by voting). The former is
313 more practical and tends to make the certification process simpler
314 although it is in violation of the pure P2P model and exposes the
315 system to attacks typical for server-based solutions (e.g., denial of
316 service attacks targeted to the central authority). The latter, the
317 group authority could either be a fixed number of peers or it could
318 be a dynamic number based on the total membership of the group. The
319 authors argue that even if the group charter requires a prospective
320 member to get votes from peers, the group membership certificate must
321 be issued by a distinct entity. The reason for this is that voters
322 need to accompany their votes with a certificate that proves their
323 own membership. Possible signature schemes that could be used in
324 voting such as plain digital signature, threshold signature and
325 accountable subgroup multisignature are also described. Saxena et.
326 al [Saxena] performed experiments with the different signature
327 schemes and suggest the use of plain signatures for groups of
328 moderate size and where bandwidth is not a concern. For larger
329 groups and where bandwidth is a concern, they suggest threshold
330 signature [Kong] and multisignature schemes [Ohta].
332 Another way of handling admission would be to use mechanisms based on
333 trust and recommendation where each new applicant has to be known and
334 vouched for by at least N existing members. The difficulties that
335 such models represent include identity assertion and preventing bot/
336 worm attacks. A compromised node could have a valid certificate
337 identifying a trustworthy peer and it would be difficult to detect
338 this. Possible solutions include sending graphic or logic puzzles
339 easily addressed by humans but hard to solve by computers, also known
340 as CAPTCHA [Ahn].
342 4. Determining the position in the overlay
344 For ring based DHT overlays such as Chord [Stoica], Kademlia
345 [KADEMLIA] and Pastry [PASTRY], when a node joins the overlay, it
346 uses a numeric identifier (ID) to determine its position in the ring.
347 The positioning of a node determines what information it stores and
348 which nodes it serves. To provide a degree of robustness, content
349 and services are often replicated across multiple nodes. However it
350 is possible for an adversary with sufficient resources to undermine
351 the redundancy deployed in the overlay by representing multiple
352 identities. Such an attack is called a sybil attack [Douceur]. This
353 makes the assignment of IDs very important. One possible scheme to
354 tackle such attacks on the ID mapping is to have a temporal mechanism
355 in which nodes need to re-join the network after some time [Condie]
356 [Scheideler]. Such temporal solutions, however have the drawback
357 that they increase the maintenance traffic and possibly deteriorate
358 the efficiency of caching. Danezis et. al [Danezis] suggest
359 mechanisms to mitigate the effect of sybil attacks by reducing the
360 amount of information received from malicious nodes. Their idea is
361 to vary the nodes used for routing with time and thus avoid a trust
362 bottleneck. Other solutions suggest making the joining process
363 harder by introducing cryptographic puzzles as suggested by Rowaihy
364 et. al [Rowaihy]. The assumption is that the adversary has limited
365 computational resources which may not be true if the adversary has
366 control over a botnet. Another drawback of such methods is that non-
367 malicious nodes would also have to perform the extra computations
368 before they can join the overlay.
370 A possible heuristic to hamper sybil attacks is to employ redundancy
371 at nodes with diametrically opposite IDs (in the DHT ID space)
372 instead of successive IDs as in Chord. The idea behind choosing
373 diametrically opposite nodes is based on the fact that a malicious
374 peer can grant admission to others as its successor without them
375 actually possessing the required IP address (whose hash is adjacent
376 to the former's), and then they can cooperate to control access to
377 that part of the ring. If however admission decisions and redundant
378 content (for robustness), also involve nodes which are the furthest
379 away (diametrically opposite) from a given position, then the
380 adversary would require double resources (IP addresses) to attack.
381 This happens because the adversary would need presence in the overlay
382 at two independent positions in the ring.
384 Another approach proposed by Yu et al [Yu]. to limit sybil attacks is
385 based on the usage of the social relations between users. Authors
386 use the fact that as a result of sybil attacks, affected P2P overlays
387 end up containing a large set of sybil nodes connected to the rest of
388 the peers through an irregularly small number of edges. The
389 SybilGuard protocol [Yu] defines a method that allows to discover
390 such kind of discontinuities in the topology by using a special kind
391 of a verifiable random walk and hence without the need of one node
392 having a global vision of the graph.
394 It is also worth mentioning that in DHT overlays using different
395 geometric concepts, (e.g., hypercubes instead of rings), peer
396 positions are usually not related to identifiers. In the content
397 addressable network (CAN) [Ratnasamy], for example, the position of
398 an entering node may be either selected by the node itself, or, with
399 little modification to the original algorithm, assigned by peers
400 already in the overlay. However, even when malicious nodes do not
401 know their position before joining, the overlay is still vulnerable
402 to sybil attacks.
404 5. Resilience against malicious peers
406 Making overlays robust against even a small percentage of malicious
407 nodes is difficult [Castro]. It is therefore important for other
408 peers to identify such nodes and keep track of their number. There
409 are two aspects to this problem. One is the identification itself
410 and the second is the dissemination of this information amongst the
411 peers. Different metrics need to be defined depending on the peer
412 group for the former and reputation management systems are needed for
413 the latter.
415 5.1. Identification of malicious peers
417 For identifying a node as malicious, malicious activity has to be
418 observed first. This could be done in either a proactive way, or a
419 reactive way.
421 5.1.1. Proactive identification
423 When acting proactively, peers perform periodic operations with the
424 purpose of detecting malicious activity. A malicious node could
425 prevent access to content it is responsible for (e.g., by claiming
426 the object doesn't exist), or return references to content that does
427 not match the original queries [Sit]. With this approach, publishers
428 of content can later perform lookups for it at periodic intervals and
429 verify the integrity of whatever is returned. Any inconsistencies
430 could then be interpreted as malicious activity. The problem with
431 proactive identification is the management of the overhead it
432 implies: if checks are performed too often, they may actually hinder
433 scalability, while, if they are performed too rarely, they would
434 probably be useless.
436 5.1.2. Reactive identification
438 In a reactive strategy, the peers perform normal operations and if
439 they happen to detect some malicious activity, then they can label
440 the responsible node as malicious. In a file-sharing application for
441 example, after downloading content from a node, if the peer observes
442 that data does not match its original query it can identify the
443 corresponding node as malicious. Poon et. al [Poon] suggest a
444 strategy based on the forwarding of queries. If routing is done in
445 an iterative way, then dropping of packets, forwarding to an
446 incorrect node and delay in forwarding arouse suspicion and the
447 corresponding peer is identified as malicious.
449 5.2. Reputation management systems
451 Reputation management systems are used to allow peers to share
452 information about other peers based on their own experience and thus
453 help in making better judgments. Most reputation management systems
454 proposed in the literature [Uzun] [Damiani] [Lee] [Kamvar] are for
455 file-sharing applications. In reputation systems, it should not be
456 possible for a misbehaving peer with low reputation to simply rejoin
457 the network with a different ID and therefore start from a clean
458 slate. To counter this, Kwon et. al [Lee] store not only the
459 reputation of a peer but also the reputation of files based on file
460 name and content to avoid spreading of a bad file. Another method is
461 to make the reputation of a new peer the minimum possible [Kamvar].
462 Kamvar et. al [Kamvar] define five design considerations for
463 reputation management systems;
464 o Self policing.
465 o Anonymity.
466 o No profit to new comers.
467 o Minimal overhead.
468 o Robustness to malicious peers.
470 5.2.1. Unstructured reputation management
472 Unstructured reputation management systems have been proposed by Uzun
473 et. al [Uzun] and Damiani et. al [Damiani]. The basic idea of these
474 is that each peer maintains information about its own experience with
475 other peers and resources, and shares it with others on demand. In
476 the system proposed by Uzun et. al [Uzun], each node maintains trust
477 and distrust vectors for every other node that it has interacted
478 with. When reputation information about a peer is required, a node
479 first checks its local database, and if insufficient information is
480 present, it sends a query to its neighbors just as it would when
481 looking up content. However, such an approach requires peers to get
482 reputation information from as many sources as possible; otherwise,
483 malicious nodes may succesfully place targeted attacks returning
484 false values for their victims.
486 5.2.2. Structured reputation management
488 One of the problems with unstructured reputation management systems
489 is that they either take the feedback from few peers, or if they do
490 from all, then the they incur large traffic overhead. Systems such
491 as those proposed by [Lee] [Kamvar] try to resolve it in a structured
492 manner. The idea of the eigen trust algorithm [Kamvar] for example,
493 is transitivity of trust. If a node trusts peer X then it would also
494 trust the feedback it gives about other peers. A node builds such
495 information in an iterative way. The algorithm has fast convergence
496 properties [Haveliwala]. For maintaining this information in a
497 structured way, the authors use a content addressable network (CAN)
498 DHT [Ratnasamy]. The information of each peer is stored and
499 replicated on different peers to provide robustness against malicious
500 nodes. They also suggest favoring peers probabilistically with high
501 trust values instead of doing it deterministically, to allow new
502 peers to slowly develop a reputation. Eventually, they suggest the
503 use of incentives for peers with high reputation values.
505 6. Routing and data integrity
507 Preserving integrity of routing and data, or, in other words,
508 preventing peers from returning corrupt responses to queries and
509 routing through malicious peers, is an important security issue in
510 P2P networks. The data stored on a P2P overlay depends on the
511 applications that are using it. For file-sharing, this data would be
512 the files themselves, their location, and owner information. For
513 realtime communication, this would include user location bindings and
514 other routing information. We describe such data integrity issues
515 separately in Section 7.
517 6.1. Data integrity
519 For file-sharing applications, insertion of wrong content (e.g. files
520 not matching their names or descriptions) or introduction of corrupt
521 data chunks (often referred to as poisoning and pollution) are a
522 significant problem. Bit-Torrent uses voluntary moderators to weed
523 out bogus files and the SHA-1 algorithm to determine the hash of each
524 piece of a file to allow verification of integrity. If a peer
525 detects a bad chunk, it can download that chunk from another peer.
526 With this strategy, different peers download different pieces of a
527 file before the original peer disappears from the network. However,
528 if a malicious peer modifies the pieces that are only available on it
529 and the original peer disappears, then the object distribution will
530 fail [Zhang]. An analysis of BitTorrent in terms of integrity and
531 performance can be found in the work of Pouwelse et. al [Pouwelse].
533 6.2. Routing integrity
535 To enhance the integrity of routing, it is important to reduce the
536 number of queries forwarded to malicious nodes. Marti et. al [Marti]
537 developed a system that uses social network information to route
538 queries over trusted nodes. Their algorithm uses trusted nodes to
539 forward queries (if one exists and is closer to the required ID in
540 the ID space). Otherwise they use the regular Chord [Stoica] routing
541 table to forward queries. While their results indicate good average
542 performance, it can not guarantee log$N$ hops for all cases. Danezis
543 et. al [Danezis] suggest a method for routing in the presence of a
544 large number of sybil nodes. Their method is to ensure that a peer
545 queries a diverse set of nodes and does not place too much trust in a
546 node. Both the above works have been described based on Chord.
547 However, unlike Chord, in DHTs like Pastry [PASTRY] and Kademlia
548 [KADEMLIA] there is flexibility in selecting nodes for any row in a
549 peer's routing table. Potentially many nodes have a common ID prefix
550 of a given length and are candidates for routing a given query. To
551 exploit the social network information and still guarantee log(N)
552 hops, a peer should select its friends to route a query, but only
553 when they are present in the appropriate row selected by the DHT
554 algorithm.
556 7. Peer-to-peer in realtime communication
558 The idea of using P2P in realtime communication boils down to
559 distributing centralized entities from conventional architectures
560 over peer-to-peer overlays and thus reducing the costs of deployment
561 and increasing reliability of the different services. Initiatives
562 such as the P2PSIP working group in IETF [P2PSIP] are currently
563 concentrating on achieving this by using a DHT for services such as
564 registration, location lookup, and support for NAT traversal, which
565 are normally handled by dedicated servers.
567 Even if based on the same technology, overlays used for realtime
568 communication differ from those used for file sharing in at least two
569 aspects:
570 o Resource consumption. Contrary to file sharing systems where the
571 DHT is used to store huge amounts of data (even if the distributed
572 database is used only for storing file locations, each user
573 usually indexes hundreds or thousands of files), realtime
574 communication overlays only require a subset of the resources
575 available at any given time as users only register a limited
576 number of locations (rarely more than one).
577 o Confidentiality. While in file sharing applications, where shared
578 files are supposed to be made publicly available, eavesdropping
579 and identity theft do not constitute real threats, in realtime
580 communication, since exchanges of data are usually meant to happen
581 privately, it is essential to have mechanisms to assert identities
582 and to guarantee confidentiality.
584 In this section we go over the admission issues, and security
585 problems discussed in previous sections, and discuss solutions that
586 would be applicable to realtime communication in P2P.
588 7.1. Admission
590 In order to keep as much compatibility with existing user agents as
591 possible, nodes in P2P communication architectures would probably
592 have to participate as either peers or clients. If a node
593 participates as a client, then it would use the overlay network by
594 simply attaching to a peer or a proxy instead of registering with a
595 server. In most cases users would be able to benefit from the
596 overlay by only acting as clients. However, in order to keep the
597 solution scalable, at some point clients would have to be promoted to
598 peers (admission to the DHT). This requires addressing the following
599 issues.
601 7.1.1. Active vs. passive upgrades
603 Most existing P2P networks [KAZAA] [BITTORRENT] [JOOST] would
604 generally make it the responsibility of clients to determine if and
605 when they would apply for becoming peers. A well known exception to
606 this trend is the Skype network [SKYPE], arguably one of the most
607 popular overlay networks used for realtime communications today.
608 Instances of the Skype application are supposed to operate as either
609 super-nodes, directly contributing to the distributed provision of
610 the service, or ordinary-nodes, simply using the service, and the
611 ``promotions'' are decided by the higher levels of the hierarchy
612 [Baset]. Even if there is not much difference for a client whether
613 it has to actively ask for authorization to join an overlay, or
614 passively wait for an invitation, the latter approach has some
615 advantages which fit well in overlays where only a subset of the
616 peers is required to provide the service (as in realtime
617 communication):
618 o An attacker cannot estimate in advance when and if it would be
619 invited to join the overlay as a peer.
620 o Allows peers to perform long-lasting measurements on sets of
621 candidates, in order to accurately select the most appropriate for
622 upgrading and only invite it when they are ``ready'' to do so.
624 The opposite approach, that is when clients initiate the join
625 themselves, adds an extra constraint for the peer that has to act
626 upon the request since it doesn't know if and when the peer would
627 attempt to join again.
628 o Discourages malicious peers from attempting sybil and, more
629 generally, brute force attacks, as only a small ratio of clients
630 has chances to join the overlay (possibly after an accurate
631 examination).
633 7.1.2. When to upgrade
635 In order to answer this question one would have to define some
636 criteria that would allow to determine the load on a peer and a
637 reasonable threshold. When the load exceeds this threshold, a client
638 is invited to become a peer and share the load. The criteria for
639 determining load can be:
640 o Number of clients attached.
641 o Bandwidth usage for DHT maintenance, forwarding requests and
642 responses to and from peers and from the attached clients.
643 o Memory usage for DHT routing table, DHT neighborhood table,
644 application specific data and information about the attached
645 clients.
647 7.1.3. Which clients to upgrade
649 Selecting which clients to upgrade would require defining and keeping
650 track of new metrics. The exact set of metrics and how they
651 influence decisions should be the subject of serious analysis and
652 experimentation. These could be based on the following observations:
653 o Uptime. A peer could easily record the amount of time that it has
654 been maintaining a connection with a client and take it into
655 account when trying to determine whether or not to upgrade it.
656 o Level of activity. It is reasonable to assume that the more a
657 client uses the service (e.g. making phone calls), the less they
658 would be willing to degrade it.
659 o Keeping track of history. Peers could record history of the
660 clients they invite and the way they contribute to the overlay.
661 Other metrics such as public vs. private IP addresses, computation
662 power, and bandwidth should also be taken into account even though
663 they do not necessarily have a direct impact on security.
665 7.1.4. Incentives for clients
667 Clients need to have incentives for accepting upgrades in order to
668 prevent excessive burden on existing peers. One way to handle this
669 would be to maintain separate incentive management through the use of
670 currency or credits. Another option would involve embedding these
671 incentives inside the protocol itself:
673 o Peers share with clients only a fraction of their bandwidth
674 (uplink and downlink). This would result in higher latency when
675 using the services of the overlay as a client and better service
676 quality for peers.
677 o Peers could restrict the number or types of calls that they allow
678 clients to make.
679 Introducing such incentives, however, may turn out to be somewhat
680 risky. Differences in quality would probably be perceptible for end
681 users who would not always be able to understand the difference
682 between the roles that their user agent is playing in the overlay.
683 Such behavior may therefore be interpreted as arbitrary and make the
684 service look unreliable.
686 7.2. Security
688 7.2.1. Targeted denial of service
690 In addition to bombardment with queries as described in Section 2,
691 the denial of service attack against an individual node can be
692 conducted in DHTs used for realtime communications if the peers which
693 surround a particular ID are compromised. These peers which act as
694 proxy servers for the victim, can fake the responses from the victim
695 by sending fictitious error messages back to peers trying to
696 establish a session. Danezis et al.'s solution [Danezis] can also
697 provide protection against such attacks as in their solution peers
698 vary the nodes used in queries.
700 7.2.2. Man in the middle attack
702 The man in the middle attack is well described by Seedorf [Seedorf06]
703 in the particular case of P2PSIP [P2PSIP] and consist of an attack
704 that exploits the lack of integrity when routing information. A
705 malicious node could return IP addresses of other malicious nodes
706 when queried for a particular ID. The requesting peer would then
707 establish a session with a second malicious node which would again
708 return a ``poisoned'' reply. This could go on until the TTL expires
709 and the requester gives up the ``wild goose chase'' [Danezis]. A
710 simple way for entities to verify the correctness of the routing
711 lookup is to employ iterative routing and to check the node-ID of
712 every routing hop that it is returned and it should get closer to the
713 desired ID with every hop. However, this is not a strong check and
714 can be defeated [Seedorf06].
716 7.2.3. Trust between peers
718 The effect of malicious peers could be mitigated by introducing the
719 concept of trust within an overlay. This can be done in different
720 ways:
722 o Using certificates assigned by an external authority. The
723 drawback with this approach is that it requires a centralized
724 element.
725 o Using certificates reciprocally signed by peers. This mechanism
726 is quite similar to PGP [Zimmermann]; every peer signs
727 certificates of ``friend'' peers and trusts any other peer with a
728 certificate signed by one of its friends. However even though it
729 might be theoretically possible, in reality it is extremely
730 difficult to obtain long enough trust chains.
732 7.2.4. Routing call signalization
734 One way for implementing realtime communication overlays (as we have
735 mentioned in earlier sections) would be to simply replace centralized
736 entities in signalling protocols like SIP [RFC3261] with distributed
737 services. In some cases this might imply reusing existing protocol
738 mechanisms for routing signalling messages. In the case of SIP this
739 would imply regarding peers as SIP proxies. However the design of
740 SIP supposes that such proxies are trusted, and makes it possible for
741 them to fork requests or change their destination, add or remove
742 header fields, act as the remote party, and generally manipulate
743 message content and semantics
745 However, in a P2P environment where messages may be routed through
746 numerous successive peers, some of which might be compromised, it is
747 important not to treat them as trusted proxies. One way to limit
748 what peers can do is by protecting signalling with some kind of end-
749 to-end encryption.
751 Another option would be to extend existing signalling protocols and
752 modify the way they route messages in order to guarantee secure end-
753 to-end transmission. Gurbani et al. define a similar mechanism for
754 SIP called SIPSEC [I-D.gurbani-sip-sipsec]. It allows nodes to
755 establish a secure channel by sending a CONNECT SIP request, and then
756 tunnel all SIP messages through it, adopting a similar mechanism to
757 the one used for upgrading from HTTP to HTTPS [RFC2818].
759 7.2.5. Integrity of location bindings
761 It is important to ensure that the location that a user registers,
762 usually a (URI, IP) pair, is what is returned to the requesting
763 party. Or the entities that issue the lookup request must be able to
764 verify the integrity of this pair. A pure P2P approach to allow
765 verification of the integrity of location binding information is
766 presented in [Seedorf08]. The idea is for an entity to choose an
767 asymmetric key pair and hash its public key to generate its URI. The
768 entity then signs its present location with its private key and
769 registers with the quadruple (URI, IP, signature, public key). Any
770 entity which looks up for the URI and receives such a quadruple can
771 then verify its integrity by using the public key and the
772 certificate. Another possible merit of such an approach could be
773 that it is possible to identify the malicious nodes and maintain a
774 black list. However, the resulting URIs are not easy to remember and
775 associate with entities. Discovering these URIs and associating them
776 with entities would therefore require some sort of a directory
777 service. The authors suggest using existing authentication
778 infrastructure for this such as a certified web service using SSL
779 which can publish an ``online phone book'' mapping users to URIs.
781 7.2.6. Encrypting content
783 Using P2P overlays for realtime communication implies that content is
784 likely to traverse numerous intermediate peers before reaching its
785 destination. A typical example could be the use of peers as media
786 relays as a way of traversing NATs in VoIP calls.
788 Contrary to publicly shared files, communication sessions are in most
789 cases expected to be private. It is therefore very important to make
790 sure that no media leaves the client application without being
791 encrypted and securely transported through a protocol like SRTP
792 [RFC3711]. However, the extra processing resources required by the
793 encryption algorithms, the management of keying material (e.g.,
794 retrieving public keys when interacting with unknown peers) may
795 constitute an expensive task, especially for mobile devices.
797 7.2.7. Other issues
799 Identifying more specific threats related to the P2P realtime
800 communications, would require a clearly defined economic model.
801 Answers to the following questions would be helpful.
802 o To whom do the users pay?
803 o Do the users only pay when accessing the public telephone network?
804 o Is the billing done per call or is it fixed?
805 For instance, the implications of an attack such as taking control
806 over another's user agent or its identity and using it for outbound
807 calls would depend on whether or not this would be economically
808 advantageous for the attacker. Baumann et. al [Baumann] suggests
809 that to prevent unwanted communication costs, gateways for the public
810 telephone network should only be accessible via authenticated servers
811 and dialing authorizations should be enforced. Also it seems that it
812 would be difficult to do billing in a pure P2P manner as it would
813 mean keeping the billing details with untrusted peers.
815 8. Security Considerations
817 This document, informative in nature, discusses some of the security
818 issues of peer-to-peer systems used for realtime communications.
820 9. Acknowledgments
822 The authors are particularly grateful to Dhruv Chopra who contributed
823 to the writing of the article "Peer-to-peer Overlays for Real-Time
824 Communications: Issues and Solutions" (IEEE Surveys & Tutorials, Vol.
825 11, No. 1) this work is partially derived from.
827 10. Informative references
829 [Ahn] Ahn, Luis., Blum, Manuel., and John. Langford, "Telling
830 humans and computers apart automatically".
832 [Androutsellis-Theotokis]
833 Androutsellis-Theotokis, S. and D. Spinellis, "A survey of
834 peer-to-peer content distribution technologies".
836 [BITTORRENT]
837 "BitTorrent", .
839 [Baset] Baset, S. and H. Schulzrinne, "An analysis of the skype
840 peer-to-peer internet telephony protocol".
842 [Baumann] Baumann, R., Cavin, S., and S. Schmid, "Voice Over IP -
843 Security and SPIT".
845 [COOLSTREAM]
846 "COOLSTREAMING", .
848 [Castro] Castro, M., Druschel, P., Ganesh, A., Rowstron, A., and D.
849 Wallach, "Secure routing for structured peer-to-peer
850 overlay networks".
852 [Condie] Condie, T., Kacholia, V., Sankararaman, S., Hellerstein,
853 J., and P. Maniatis, "Maelstorm: Churn as Shelter".
855 [Damiani] Damiani, E., Vimercati, D., Paraboschi, S., Samarati, P.,
856 and F. Violante, "A Reputation-Based Approach for Choosing
857 Reliable Resources in Peer-to-Peer Networks".
859 [Danezis] Danezis, G., Lesniewski-Laas, C., Kaashoek, M., and R.
860 Anderson, "Sybil-resistant DHT routing".
862 [Douceur] Douceur, J., "The Sybil Attack".
864 [Haveliwala]
865 Haveliwala, T. and S. Kamvar, "The second value eigenvalue
866 of the google matrix".
868 [I-D.gurbani-sip-sipsec]
869 Gurbani, V., Audet, F., and D. Willis, "The SIPSEC Uniform
870 Resource Identifier (URI)", draft-gurbani-sip-sipsec-01
871 (work in progress), June 2007.
873 [JOOST] "Joost", .
875 [KADEMLIA]
876 Maymounkov, P. and D. Mazi, "Kademlia: A Peer-to-peer
877 Information System Based on the XOR Metric".
879 [KAZAA] "KaZaa", .
881 [Kamvar] Kamvar, S., Garcia-Molina, H., and M. Schlosser, "The
882 EigenTrust Algorithm for Reputation Management in P2P
883 Networks".
885 [Kim] Kim, Y., Mazzocchi, D., and G. Tsudik, "Admission Control
886 in Peer Groups".
888 [Kong] Kong, J., Zerfos, P., Luo, H., Lu, S., and L. Zhang,
889 "Providing robust and ubiquitous security support for
890 MANET".
892 [Lee] Lee, S., Kwon, O., Kim, J., and S. Hong, "A Reputation
893 Management System in Structured Peer-to-Peer Networks".
895 [Liang] Liang, J., Kumar, R., Xi, Y., and K. Ross, "Pollution in
896 p2p file sharing systems".
898 [Marti] Marti, S., Ganesan, P., and H. Garcia-Molina, "SPROUT: P2P
899 Routing with Social Networks".
901 [McCue] McCue, Andy., "Bookie reveals 100,000 cost of denial-of-
902 service extortion attacks", .
905 [NAPSTER] "Napster", .
907 [Ohta] Ohta, K., Micali, S., and L. Reyzin, "Accountable Subgroup
908 Multisignatures".
910 [P2PSIP] "Peer-to-Peer Session Initiation Protocol (P2PSIP) IETF
911 Working Group",
912 .
914 [PASTRY] Rowstron, A. and P. Druschel, "Pastry: Scalable,
915 distributed object location and routing for large-scale
916 peer-to-peer systems".
918 [Poon] Poon, W. and R. Chang, "Robust Forwarding in Structured
919 Peer-to-Peer Overlay Networks".
921 [Pouwelse]
922 Pouwelse, J., Garbacki, P., Epema, D., and H. Sips, "The
923 Bittorent P2P File-Sharing System: Measurements and
924 Analysis".
926 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
928 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
929 A., Peterson, J., Sparks, R., Handley, M., and E.
930 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
931 June 2002.
933 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
934 Norrman, "The Secure Real-time Transport Protocol (SRTP)",
935 RFC 3711, March 2004.
937 [Ratnasamy]
938 Ratnasamy, S., Francis, P., Handley, M., Karp, R., and S.
939 Shenker, "A Scalable Content-Addressable Network".
941 [Rowaihy] Rowaihy, H., Enck, W., McDaniel, P., and T. Porta,
942 "Limiting Sybil attacks in structured peer-to-peer
943 networks".
945 [SHA1] 180-1, FIPS., "Secure Hash Standard".
947 [SKYPE] "Skype", .
949 [Saxena] Saxena, N., Tsudik, G., and J. Yi, "Admission Control in
950 Peer-to-Peer: Design and Performance Evaluation".
952 [Scheideler]
953 Scheideler, C., "How to Spread Adversarial Nodes?:
954 Rotate!".
956 [Seedorf06]
957 Seedorf, J., "Security Challenges for Peer-to-Peer SIP".
959 [Seedorf08]
960 Seedorf, J., "Using Cryptographically Generated SIP-URIs
961 to Protect the Integrity of Content in P2P-SIP".
963 [Singh] Singh, K. and H. Schulzrinne, "Peer-to-Peer Internet
964 Telephony using SIP".
966 [Sit] Sit, E. and R. Morris, "Security considerations for peer-
967 to-peer distributed hash tables".
969 [Stoica] Stoica, I., Morris, R., Karger, D., Kaashoek, M., and H.
970 Balakrishnan, "Chord: A Scalable Peer-to-peer Lookup
971 Service for Internet Applications".
973 [Uzun] Uzun, E., Pariente, M., and A. Selpk, "A Reputation-Based
974 Trust Management System for P2P Networks".
976 [Wallach] Wallach, D., "A Survey of Peer-to-Peer Security Issues",
977 .
979 [Yu] Yu, H., Kaminsky, M., Gibbons, P., and A. Flaxman,
980 "SybilGuard: Defending Against Sybil Attacks via Social
981 Networks".
983 [Zhang] Zhang, X., Chen, S., and R. Sandhu, "Enhancing Data
984 Authenticity and Integrity in P2P Systems".
986 [Zimmermann]
987 Zimmermann, Philip., "Pretty good privacy: public key
988 encryption for the masses".
990 Authors' Addresses
992 Henning Schulzrinne
993 Columbia University
994 1214 Amsterdam Avenue
995 New York, NY 10027
996 USA
998 Email: hgs@cs.columbia.edu
999 Enrico Marocco
1000 Telecom Italia
1001 Via G. Reiss Romoli, 274
1002 Turin 10148
1003 Italy
1005 Email: enrico.marocco@telecomitalia.it
1007 Emil Ivov
1008 SIP Communicator
1009 4 rue Blaise Pascal
1010 Strasbourg Cedex F-67070
1011 France
1013 Email: emcho@sip-communicator.org