GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5765

Internet Research Task Force (IRTF) H. Schulzrinne Request for Comments: 5765 Columbia University Category: Informational E. Marocco ISSN: 2070-1721 Telecom Italia

                                                               E. Ivov
                                                      SIP Communicator
                                                         February 2010
       Security Issues and Solutions in Peer-to-Peer Systems
                    for Realtime Communications

Abstract

 Peer-to-peer (P2P) networks have become popular for certain
 applications and deployments for a variety of reasons, including
 fault tolerance, economics, and legal issues.  It has therefore
 become reasonable for resource consuming and typically centralized
 applications like Voice over IP (VoIP) and, in general, realtime
 communication to adapt and exploit the benefits of P2P.  Such a
 migration needs to address a new set of P2P-specific security
 problems.  This document describes some of the known issues found in
 common P2P networks, analyzing the relevance of such issues and the
 applicability of existing solutions when using P2P architectures for
 realtime communication.  This document is a product of the P2P
 Research Group.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This document is a product of the Internet Research Task Force
 (IRTF).  The IRTF publishes the results of Internet-related research
 and development activities.  These results might not be suitable for
 deployment.  This RFC represents the consensus of the Peer-to-Peer
 Research Group of the Internet Research Task Force (IRTF).  Documents
 approved for publication by the IRSG are not a candidate for any
 level of Internet Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc5765.

Schulzrinne, et al. Informational [Page 1] RFC 5765 Security in P2P Realtime Communications February 2010

Copyright Notice

 Copyright (c) 2010 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.

Schulzrinne, et al. Informational [Page 2] RFC 5765 Security in P2P Realtime Communications February 2010

Table of Contents

 1. Introduction ....................................................4
    1.1. Purpose of This Document ...................................6
    1.2. Structure of This Document .................................7
 2. The Attackers ...................................................8
    2.1. Incentive of the Attacker ..................................8
    2.2. Resources Available to the Attacker ........................9
    2.3. Victim of the Attack ......................................10
    2.4. Time of Attack ............................................10
 3. Admission Control ..............................................10
 4. Determining the Position in the Overlay ........................11
 5. Resilience against Malicious Peers .............................12
    5.1. Identification of Malicious Peers .........................13
         5.1.1. Proactive Identification ...........................13
         5.1.2. Reactive Identification ............................13
    5.2. Reputation Management Systems .............................14
         5.2.1. Unstructured Reputation Management .................14
         5.2.2. Structured Reputation Management ...................14
 6. Routing and Data Integrity .....................................15
    6.1. Data Integrity ............................................15
    6.2. Routing Integrity .........................................15
 7. Peer-to-Peer in Realtime Communication .........................16
    7.1. Peer Promotion ............................................17
         7.1.1. Active vs. Passive Upgrades ........................17
         7.1.2. When to Upgrade ....................................18
         7.1.3. Which Clients to Upgrade ...........................18
         7.1.4. Incentives for Clients .............................19
    7.2. Security ..................................................19
         7.2.1. Targeted Denial of Service .........................19
         7.2.2. Man-in-the-Middle Attack ...........................20
         7.2.3. Trust between Peers ................................20
         7.2.4. Routing Call Signaling .............................20
         7.2.5. Integrity of Location Bindings .....................21
         7.2.6. Encrypting Content .................................21
         7.2.7. Other Issues .......................................22
 8. Open Issues ....................................................22
 9. Security Considerations ........................................23
 10. Acknowledgments ...............................................23
 11. Informative References ........................................23

Schulzrinne, et al. Informational [Page 3] RFC 5765 Security in P2P Realtime Communications February 2010

1. Introduction

 Peer-to-peer (P2P) overlays have become quite popular with the advent
 of file-sharing applications such as Napster [NAPSTER], KaZaa
 [KAZAA], and BitTorrent [BITTORRENT].  After their success in file-
 sharing and content distribution [Androutsellis-Theotokis], P2P
 networks are now also being used for applications such as Voice over
 IP (VoIP) [SKYPE] [Singh] and television [PPLIVE] [COOLSTREAM].
 However, most of these systems are not purely P2P and have
 centralized components like the login server in Skype [Baset] or
 moderators and trackers in BitTorrent [Pouwelse].  Securing pure P2P
 networks is therefore still a field of very active research
 [Wallach].
 P2P overlays can be broadly classified as structured and unstructured
 [RFC4981], depending on their routing model.  Unstructured overlays
 are often relatively simple, but search operations in them, usually
 based on flooding, tend to be inefficient.  Structured P2P overlays
 use distributed hash tables (DHTs) [Stoica] [Maymounkov] [Rowstron]
 to perform directed searches, which make lookups more efficient in
 locating data.  This document will mostly focus on DHT-based P2P
 overlays.
 When analyzing the various attacks that are possible on P2P systems,
 it is important to first understand the motivation of the attackers
 as well as the resources (e.g., computation power, access to
 different IP subnets) that they would have at their disposal.
 Once the threat has been identified, admission control is a first
 step towards security that can help avoid a substantial number of
 attacks [Kim].  Most solutions rely on the assumption that malicious
 nodes represent a small fraction of all peers.  It is therefore
 important to restrict their number in the overlay.
 Other P2P-specific security problems discussed here include attacks
 on the routing of queries, targeted denial-of-service attacks, and
 attacks on data integrity.
 In the remainder of this document, we outline the main security
 issues and proposed solutions for P2P systems.  Following this, we
 focus on a particular class of P2P applications that provide realtime
 communications.  Realtime communications use the same DHTs used by
 file-sharing applications; however, the data that is saved in these
 DHTs is different.  In realtime communications, the contents stored
 in the DHTs comprises user location, the DHT being the substitute for
 a centralized registration server.

Schulzrinne, et al. Informational [Page 4] RFC 5765 Security in P2P Realtime Communications February 2010

 At first glance, it may appear that requirements on peer-to-peer
 systems for realtime communication services are no different than
 those for file-sharing services.  Table 1 demonstrates that there are
 sizeable differences related to privacy, availability, and a marked
 increase in the general security requirements.
 +-----------------+-----------------------+-------------------------+
 |                 | File-sharing          | Realtime communication  |
 +-----------------+-----------------------+-------------------------+
 | Distributed     | Shared file locations | User locations are      |
 | database        | are indexed in a      | indexed in a table      |
 |                 | table distributed     | distributed among       |
 |                 | among peers; often    | peers; rarely more than |
 |                 | hundreds or thousands | one per peer.           |
 |                 | per peer.             |                         |
 | Availability    | Same files are        | Users are unique;       |
 |                 | usually available at  | attacks targeting       |
 |                 | multiple locations    | single users may be     |
 |                 | and failures          | addressed both to the   |
 |                 | involving single      | distributed index and   |
 |                 | instances are         | to the user's device    |
 |                 | overcome by abundancy | directly.               |
 |                 | of resources; attacks |                         |
 |                 | targeting single      |                         |
 |                 | files need to be      |                         |
 |                 | addressed to the      |                         |
 |                 | distributed index.    |                         |
 | Integrity       | Attackers may want to | Attackers may want to   |
 |                 | share corrupted files | impersonate different   |
 |                 | in place of popular   | users in order to       |
 |                 | content, e.g., to     | handle calls directed   |
 |                 | discourage users from | to them; constitute a   |
 |                 | acquiring copyrighted | particular threat for   |
 |                 | material; constitute  | the user as, in case of |
 |                 | a threat for the      | success, the attacker   |
 |                 | service, but not for  | acquires full control   |
 |                 | the users.            | on the victim's         |
 |                 |                       | personal                |
 |                 |                       | communications.         |
 | Confidentiality | Shared files are, by  | Communications are      |
 |                 | definition, readable  | usually meant to be     |
 |                 | by all users; in some | private and need to be  |
 |                 | cases, encryption is  | encrypted;              |
 |                 | used to avoid         | eavesdropping may       |
 |                 | elements not involved | reveal sensitive data   |
 |                 | in the service to     | and is a serious threat |
 |                 | detect traffic.       | for users.              |

Schulzrinne, et al. Informational [Page 5] RFC 5765 Security in P2P Realtime Communications February 2010

 | Bitrate and     | The file-transfer use | Realtime traffic almost |
 | latency         | case is particularly  | always requires a       |
 |                 | tolerant to unstable  | constant minimum        |
 |                 | bitrates and ability  | bitrate and low latency |
 |                 | to burst on and off   | in order to avoid       |
 |                 | as peers disappear or | problems like jitter.   |
 |                 | new ones become       | While this is not       |
 |                 | available.            | directly related to a   |
 |                 |                       | specific sort of        |
 |                 |                       | attacks, it is a        |
 |                 |                       | significant constraint  |
 |                 |                       | to the design of        |
 |                 |                       | certain design          |
 |                 |                       | solutions, and in       |
 |                 |                       | particular those that   |
 |                 |                       | somehow affect routing. |
 | Peer lifetime   | File-sharing users do | Realtime communication  |
 |                 | not need to stay in   | applications need not   |
 |                 | the overlay more than | leave the overlay for   |
 |                 | the time required for | as long as the user     |
 |                 | downloading the       | wants to stay connected |
 |                 | content they are      | and be reachable.  This |
 |                 | looking for.          | gives the attackers     |
 |                 |                       | longer time for         |
 |                 |                       | conducting successful   |
 |                 |                       | targeted attacks.       |
 +-----------------+-----------------------+-------------------------+
 Table 1: Main differences between P2P applications used for
             file-sharing and for realtime communication.

1.1. Purpose of This Document

 The goal of this document is to provide authors of P2P protocols for
 realtime communications with background that they may find useful
 while designing security mechanisms for specific cases.  The document
 has been extensively discussed during face-to-face meetings and on
 the P2PRG mailing list; it has been reviewed both substantially and
 editorially by two members of the research group and reflects the
 consensus of the group.
 The content of this document was partially derived from the article
 "Peer-to-peer Overlays for Real-Time Communication: Security Issues
 and Solutions," published in IEEE Surveys & Tutorials, Vol. 11, No.
 1, and originally authored by Dhruv Chopra, Henning Schulzrinne,
 Enrico Marocco, and Emil Ivov.

Schulzrinne, et al. Informational [Page 6] RFC 5765 Security in P2P Realtime Communications February 2010

 It is important to note that this document considers "security" from
 the perspective of application developers and protocol architects.
 It is hence entirely agnostic to potential legislation issues that
 may apply when protecting applications against a specific attack, as,
 for example, in the case of lawful interception.

1.2. Structure of This Document

 The document is organized as follows.  In Section 2, we discuss P2P
 security attackers.  We try to elaborate on their motivation, the
 resources that would generally be available to them, their victims,
 and the timing of their attacks.  In Section 3, we discuss admission
 control problems.  In Section 4, we identify the problem of where a
 node joins in the overlay.  In Section 5, we describe problems
 related to identification of malicious nodes and the dissemination of
 this information.  In Section 6, we describe the issues of routing
 and data integrity in P2P networks.  Finally, in Section 7 we discuss
 how issues and solutions previously presented apply in P2P overlays
 for realtime communication.
 Table 2 and Table 3 provide an index of the attacks and the solutions
 discussed in the rest of this document.
 +---------------------------------------+---------------------------+
 | Attack name                           | Referring sections        |
 +---------------------------------------+---------------------------+
 | botnets (use of)                      | Section 2.1, Section 2.2  |
 | denial of service (DoS)               | Section 2.1,              |
 |                                       | Section 7.2.1             |
 | man in the middle (MITM)              | Section 7.2.2             |
 | poisoning                             | Section 6.1,              |
 |                                       | Section 7.2.2             |
 | pollution                             | Section 2.1, Section 6.1  |
 | sybil                                 | Section 2.2, Section 4    |
 | targeted denial of service            | Section 7.2.1             |
 +---------------------------------------+---------------------------+
 Table 2: Index of some of the more popular attacks and problems
                      discussed in this document.

Schulzrinne, et al. Informational [Page 7] RFC 5765 Security in P2P Realtime Communications February 2010

 +---------------------------------------+---------------------------+
 | Solution name                         | Referring sections        |
 +---------------------------------------+---------------------------+
 | admission control                     | Section 3                 |
 | anonymity                             | Section 5.2               |
 | asymmetric key pair                   | Section 7.2.5             |
 | CAPTCHA                               | Section 3                 |
 | certificates                          | Section 7.2.3             |
 | CONNECT (SIP method)                  | Section 7.2.4             |
 | cryptographic puzzles                 | Section 4                 |
 | diametrically opposite IDs            | Section 4                 |
 | end-to-end encryption                 | Section 7.2.4             |
 | group authority                       | Section 3                 |
 | group charter                         | Section 3                 |
 | iterative routing                     | Section 7.2.2             |
 | no profit for newcomers               | Section 5.2               |
 | online phone book                     | Section 7.2.5             |
 | passive upgrades                      | Section 7.1.1             |
 | peer promotion                        | Section 7.1               |
 | proactive identification              | Section 5.1.1             |
 | reactive identification               | Section 5.1.2             |
 | recommendation                        | Section 3                 |
 | reputation management systems         | Section 5.2               |
 | self-policing                         | Section 5.2               |
 | signatures                            | Section 3                 |
 | social networks (using)               | Section 4, Section 6.2,   |
 | SRTP                                  | Section 7.2.6             |
 | structured reputation management      | Section 5.2.2             |
 | SybilGuard (protocol)                 | Section 4                 |
 | transitivity of trust                 | Section 5.2.2             |
 | trust and distrust vectors            | Section 5.2.1             |
 | trust and trusted nodes               | Section 3, Section 6.2,   |
 |                                       | Section 7.2.3             |
 | unstructured reputation management    | Section 5.2.1             |
 | voluntary moderators                  | Section 6.1               |
 +---------------------------------------+---------------------------+
 Table 3: Index of some of the more popular solutions discussed in
                            this document.

2. The Attackers

2.1. Incentive of the Attacker

 Attacks on networks happen for a variety of reasons such as monetary
 gain, personal enmity, or even for fame in the hacker community.

Schulzrinne, et al. Informational [Page 8] RFC 5765 Security in P2P Realtime Communications February 2010

 There are quite a few well-known cases of denial-of-service attacks
 for extortion in the client-server model [McCue].  One of the salient
 points of the P2P model is that the services it provides have higher
 robustness against failure.  However, denial-of-service attacks are
 still possible against individuals within the overlay if the
 attackers possess sufficient resources.  For instance, a network of
 worm-infected malicious nodes spread across the Internet and
 controlled by an attacker (often referred to as botnet) could
 simultaneously bombard lookup queries for a particular key in the
 DHT.  The peer responsible for this key would then come under a lot
 of load and could crash [Sit].  However, with replication of key-
 value pairs at multiple locations, such threats can be mitigated.
 Attackers may also have other incentives indirectly related to money.
 With the growth of illegal usage of sharing files with copyrights,
 record companies have been known to pollute content in the overlays
 by putting up nodes with corrupt chunks of data but with correct file
 names to degrade the service [Liang] and in hope that users would get
 frustrated and stop using it.  Similarly, competition between
 different communication service providers, either or both based on
 P2P technologies, and the low level of traceability of attacks
 targeted to single users could be considered as motivation for
 attempting service disruption.
 Attacks can also be launched by novice attackers who are attacking
 the overlay for fun or fame in a community.  These are perhaps less
 likely to be successful or cause damage, since their resources tend
 to be relatively limited.

2.2. Resources Available to the Attacker

 Resource constraints play an important role in determining the nature
 of the attack.  An attacker who controls a botnet can use an Internet
 relay channel and launch distributed denial-of-service attacks
 against another node.  With respect to attacks where a single node
 impersonates multiple identities, as in the case of the Sybil attack
 [Douceur] described in Section 4, IP addresses are also an important
 resource for the attacker since in DHTs such as Chord [Stoica], the
 position in the overlay is determined by using a base hash function
 such as SHA-1 [SHA1] on the node's IP address.  The cryptographic
 puzzles [Rowaihy] that are sometimes suggested as a way to deter
 Sybil attacks by making the join process harder are futile against an
 attacker with a botnet and virtually unlimited computation power.
 Douceur [Douceur] proves that even with the assumption that attackers
 only have minimum resources at their disposal, it is not possible to
 defend against them in a pure P2P system.

Schulzrinne, et al. Informational [Page 9] RFC 5765 Security in P2P Realtime Communications February 2010

2.3. Victim of the Attack

 The victim of an attack could be an individual node, a particular
 content entry, or the entire overlay service.  If malicious nodes are
 strategically placed in the overlay, they can block a node from using
 its services.  Attacks could also be launched against specific
 content [Sit] or even the entire overlay service.  For example, if
 the malicious nodes are randomly placed in the overlay and drop
 packets or upload malicious content, then the quality of the overlay
 would deteriorate.

2.4. Time of Attack

 A malicious node could start misbehaving as soon as it enters the
 overlay or it could follow the rules of the overlay for a finite
 amount of time and then attack.  The latter could prove to be more
 harmful if the overlay design suggests accumulating trust in peers
 based on the amount of time they have been present and/or not
 misbehaving.  In Kademlia [Maymounkov], for instance, the routing
 tables are populated with nodes that have been up for a certain
 amount of time.  While this provides some robustness from attacks in
 which the malicious nodes start dropping routing requests from the
 moment they enter, it would take time for the algorithm to adapt to
 nodes that start misbehaving in a later stage (i.e., after they have
 been recorded in routing tables).  Similarly for reputation
 management systems, it is important that they adapt to the current
 behavior of a peer.

3. Admission Control

 Admission control depends on who decides whether or not to admit a
 node and how this permission is granted.  Kim et al.  [Kim] answer
 these questions independently of any particular environment or
 application.  They define two basic elements for admission in a peer
 group, a group charter, which is an electronic document that
 specifies the procedure of admission into the overlay, and a group
 authority, which is an entity that can certify group admission.  A
 prospective member first gets a copy of the group charter, satisfies
 the requirements, and approaches the group authority.  The group
 authority then verifies the admission request and grants a group
 membership certificate.
 The group charter and authority verification can be provided by a
 centralized certificate authority or a trusted third party, or it
 could be provided by the peers themselves (by voting).  The former is
 more practical and tends to make the certification process simpler
 although it is in violation of the pure P2P model and exposes the
 system to attacks typical for server-based solutions (e.g., denial-

Schulzrinne, et al. Informational [Page 10] RFC 5765 Security in P2P Realtime Communications February 2010

 of-service attacks targeted to the central authority).  In the latter
 case, the group authority could either be a fixed number of peers or
 it could be a dynamic number based on the total membership of the
 group.  The authors argue that even if the group charter requires a
 prospective member to get votes from peers, the group membership
 certificate must be issued by a distinct entity.  The reason for this
 is that voters need to accompany their votes with a certificate that
 proves their own membership.  Possible signature schemes that could
 be used in voting such as plain digital signature, threshold
 signature, and accountable subgroup multisignature are also
 described.  Saxena et al.  [Saxena] performed experiments with the
 different signature schemes and suggest the use of plain signatures
 for groups of moderate size and where bandwidth is not a concern.
 For larger groups and where bandwidth is a concern, they suggest
 threshold signature [Kong] and multisignature schemes [Ohta].
 Another way of handling admission would be to use mechanisms based on
 trust and recommendation where each new applicant has to be known and
 vouched for by at least N existing members.  The difficulties that
 such models represent include identity assertion and preventing bot/
 worm attacks.  A compromised node could have a valid certificate
 identifying a trustworthy peer, and it would be difficult to detect
 this.  Possible solutions include sending graphic or logic puzzles
 easily addressed by humans but hard to solve by computers, also known
 as CAPTCHA [Ahn]; however, reliability of such mechanisms is at the
 time of writing a topic of lively debate [Tam] [Chellapilla].

4. Determining the Position in the Overlay

 For ring-based DHT overlays such as Chord [Stoica], Kademlia
 [Maymounkov], and Pastry [Rowstron], when a node joins the overlay,
 it uses a numeric identifier (ID) to determine its position in the
 ring.  The positioning of a node determines what information it
 stores and which nodes it serves.  To provide a degree of robustness,
 content and services are often replicated across multiple nodes.
 However, it is possible for an adversary with sufficient resources to
 undermine the redundancy deployed in the overlay by representing
 multiple identities.  Such an attack is called a Sybil attack
 [Douceur].  This makes the assignment of IDs very important.  One
 possible scheme to tackle such attacks on the ID mapping is to have a
 temporal mechanism in which nodes need to re-join the network after
 some time [Condie] [Scheideler].  Such temporal solutions, however,
 have the drawback that they increase the maintenance traffic and
 possibly deteriorate the efficiency of caching.  Danezis et al.
 [Danezis] suggest mechanisms to mitigate the effect of Sybil attacks
 by reducing the amount of information received from malicious nodes.
 Their idea is to vary the nodes used for routing with time.  This
 helps avoiding trust bottlenecks that may occur when applications

Schulzrinne, et al. Informational [Page 11] RFC 5765 Security in P2P Realtime Communications February 2010

 only route traffic through a limited set of highly trusted nodes.
 Other solutions suggest making the joining process harder by
 introducing cryptographic puzzles as suggested by Rowaihy et al.
 [Rowaihy].  The assumption is that the adversary has limited
 computational resources, which may not be true if the adversary has
 control over a botnet.  Another drawback of such methods is that non-
 malicious nodes would also have to perform the extra computations
 before they can join the overlay.
 A possible heuristic to hamper Sybil attacks is to employ redundancy
 at nodes with diametrically opposite IDs (in the DHT ID space)
 instead of successive IDs as in Chord.  The idea behind choosing
 diametrically opposite nodes is based on the fact that a malicious
 peer can grant admission to others as its successor without them
 actually possessing the required IP address (whose hash is adjacent
 to the former's), and then they can cooperate to control access to
 that part of the ring.  If, however, admission decisions and
 redundant content (for robustness) also involve nodes that are the
 farthest away (diametrically opposite) from a given position, then
 the adversary would require double resources (IP addresses) to
 attack.  This happens because the adversary would need presence in
 the overlay at two independent positions in the ring.
 Another approach proposed by Yu et al.  [Yu] to limit Sybil attacks
 is based on the usage of the social relations between users.  The
 solution exploits the fact that as a result of Sybil attacks,
 affected P2P overlays end up containing a large set of Sybil nodes
 connected to the rest of the peers through an irregularly small
 number of edges.  The SybilGuard protocol [Yu] defines a method that
 allows to discover such kinds of discontinuities in the topology by
 using a special kind of a verifiable random walk and hence without
 the need of one node having a global vision of the graph.
 It is also worth mentioning that in DHT overlays using different
 geometric concepts (e.g., hypercubes instead of rings), peer
 positions are usually not related to identifiers.  In the content
 addressable network (CAN) [Ratnasamy], for example, the position of
 an entering node may be either selected by the node itself or, with
 little modification to the original algorithm, assigned by peers
 already in the overlay.  However, even when malicious nodes do not
 know their position before joining, the overlay is still vulnerable
 to Sybil attacks.

5. Resilience against Malicious Peers

 Making overlays robust against even a small percentage of malicious
 nodes is difficult [Castro].  It is therefore important for other
 peers to identify such nodes and keep track of their number.  There

Schulzrinne, et al. Informational [Page 12] RFC 5765 Security in P2P Realtime Communications February 2010

 are two aspects to this problem.  One is the identification itself,
 and the second is the dissemination of this information amongst the
 peers.  Different metrics need to be defined depending on the peer
 group for the former, and reputation management systems are needed
 for the latter.

5.1. Identification of Malicious Peers

 For identifying a node as malicious, malicious activity has to be
 observed first.  This could be done in either a proactive way or a
 reactive way.

5.1.1. Proactive Identification

 When acting proactively, peers perform periodic operations with the
 purpose of detecting malicious activity.  A malicious node could
 prevent access to content for which it is responsible (e.g., by
 claiming the object doesn't exist), or return references to content
 that does not match the original queries [Sit].  With this approach,
 publishers of content can later perform lookups for it at periodic
 intervals and verify the integrity of whatever is returned.  Any
 inconsistencies could then be interpreted as malicious activity.  The
 problem with proactive identification is the management of the
 overhead it implies: if checks are performed too often, they may
 actually hinder scalability, while, if they are performed too rarely,
 they would probably be useless.
 An additional approach for mitigating routing attacks and identifying
 malicious peers consists in sending multiple copies of the same
 message on different paths.  With such an approach, implemented, for
 example, in Kademlia [Maymounkov], the sending peer can identify
 anomalies comparing responses coming in from different paths.

5.1.2. Reactive Identification

 In a reactive strategy, the peers perform normal operations and if
 they happen to detect some malicious activity, then they can label
 the responsible node as malicious and avoid sending any further
 message to it.  In a file-sharing application, for example, after
 downloading content from a node, if the peer observes that data does
 not match its original query it can identify the corresponding node
 as malicious.  Poon et al.  [Poon] suggest a strategy based on the
 forwarding of queries.  If routing is done in an iterative way, then
 dropping of packets, forwarding to an incorrect node, and delay in
 forwarding arouse suspicion and the corresponding peer is identified
 as malicious.

Schulzrinne, et al. Informational [Page 13] RFC 5765 Security in P2P Realtime Communications February 2010

5.2. Reputation Management Systems

 Reputation management systems are used to allow peers to share
 information about other peers based on their own experience and thus
 help in making better judgments.  Most reputation management systems
 proposed in the literature for file-sharing applications [Uzun]
 [Damiani] [Lee] [Kamvar] aim at preventing misbehaving peers with low
 reputation to rejoin the network with a different ID and therefore
 start from a clean slate.  To achieve this, Lee et al.  [Lee] store
 not only the reputation of a peer but also the reputation of files
 based on file name and content to avoid spreading of a bad file.
 Another method is to make the reputation of a new peer the minimum
 possible.  Kamvar et al.  [Kamvar] define five design considerations
 for reputation management systems:
 o  The system should be self-policing.
 o  The system should maintain anonymity.
 o  The system should not assign any profit to newcomers.
 o  The system should have minimal overhead in terms of computation,
    infrastructure, storage, and message complexity.
 o  The system should be robust to malicious collectives of peers who
    know one another and attempt to collectively subvert the system.

5.2.1. Unstructured Reputation Management

 Unstructured reputation management systems have been proposed by Uzun
 et al.  [Uzun] and Damiani et al.  [Damiani].  The basic idea of
 these is that each peer maintains information about its own
 experience with other peers and resources, and shares it with others
 on demand.  In the system proposed by Uzun et al.  [Uzun], each node
 maintains trust and distrust vectors for every other node with which
 it has interacted.  When reputation information about a peer is
 required, a node first checks its local database, and if insufficient
 information is present, it sends a query to its neighbors just as it
 would when looking up content.  However, such an approach requires
 peers to get reputation information from as many sources as possible;
 otherwise, malicious nodes may successfully place targeted attacks
 returning false values for their victims.

5.2.2. Structured Reputation Management

 One of the problems with unstructured reputation management systems
 is that they either take the feedback from few peers or, if they do
 so from all, then they incur large traffic overhead.  Systems such as

Schulzrinne, et al. Informational [Page 14] RFC 5765 Security in P2P Realtime Communications February 2010

 those proposed by [Lee] [Kamvar] try to resolve it in a structured
 manner.  The idea of the eigen trust algorithm [Kamvar], for example,
 is transitivity of trust.  If a node trusts peer X, then it would
 also trust the feedback it gives about other peers.  A node builds
 such information in an iterative way; for maintaining it in a
 structured way, the authors propose to use a content addressable
 network (CAN) DHT [Ratnasamy].  The information about each peer is
 stored and replicated on different peers to provide robustness
 against malicious nodes.  They also suggest favoring peers
 probabilistically with high trust values instead of doing it
 deterministically, to allow new peers to slowly develop a reputation.
 Eventually, they suggest the use of incentives for peers with high
 reputation values.

6. Routing and Data Integrity

 Preserving integrity of routing and data, or, in other words,
 preventing peers from returning corrupt responses to queries and
 routing through malicious peers, is an important security issue in
 P2P networks.  The data stored on a P2P overlay depends on the
 applications that are using it.  For file-sharing, this data would be
 the files themselves, their location, and owner information.  For
 realtime communication, this would include user location bindings and
 other routing information.  We describe such data integrity issues in
 Section 7.

6.1. Data Integrity

 For file-sharing applications, insertion of wrong content (e.g.,
 files not matching their names or descriptions) and introduction of
 corrupt data chunks (often referred to as poisoning and pollution)
 are a significant problem.  BitTorrent uses voluntary moderators to
 weed out bogus files and the SHA-1 algorithm to determine the hash of
 each piece of a file to allow verification of integrity.  If a peer
 detects a bad chunk, it can download that chunk from another peer.
 With this strategy, different peers download different pieces of a
 file before the original peer disappears from the network.  However,
 if a malicious peer modifies the pieces that are only available on it
 and the original peer disappears, then the object distribution will
 fail [Zhang].  An analysis of BitTorrent in terms of integrity and
 performance can be found in the work of Pouwelse et al.  [Pouwelse].

6.2. Routing Integrity

 To enhance the integrity of routing, it is important to reduce the
 number of queries forwarded to malicious nodes.  Marti et al.
 [Marti] developed a system that uses social network information to
 route queries over trusted nodes.  Their algorithm uses trusted nodes

Schulzrinne, et al. Informational [Page 15] RFC 5765 Security in P2P Realtime Communications February 2010

 to forward queries (if one exists and is closer to the required ID in
 the ID space).  Otherwise, they use the regular Chord [Stoica]
 routing table to forward queries.  While their results indicate good
 average performance, it cannot guarantee log(N) hops for all cases.
 Danezis et al.  [Danezis] suggest a method for routing in the
 presence of a large number of Sybil nodes.  Their method is to ensure
 that a peer queries a diverse set of nodes and does not place too
 much trust in a node.  Both the above works have been described based
 on Chord.  However, unlike Chord, in DHTs like Pastry [Rowstron] and
 Kademlia [Maymounkov] there is flexibility in selecting nodes for any
 row in a peer's routing table.  Potentially many nodes have a common
 ID prefix of a given length and are candidates for routing a given
 query.  To exploit the social network information and still guarantee
 log(N) hops, a peer should select its friends to route a query, but
 only when they are present in the appropriate row selected by the DHT
 algorithm.

7. Peer-to-Peer in Realtime Communication

 The idea of using P2P in realtime communication essentially implies
 distributing centralized entities from conventional architectures
 over P2P overlays and thus reducing the costs of deployment and
 increasing reliability of the different services.  Initiatives such
 as the P2PSIP working group in IETF [P2PSIP] are currently
 concentrating on achieving this by using a DHT for services such as
 registration, location lookup, and support for NAT traversal, which
 are normally handled by dedicated servers.
 Even if based on the same technology, overlays used for realtime
 communication differ from those used for file-sharing in at least two
 aspects:
 o  Resource consumption.  Contrary to file-sharing systems where the
    DHT is used to store huge amounts of data (even if the distributed
    database is used only for storing file locations, each user
    usually indexes hundreds or thousands of files), realtime
    communication overlays only require a subset of the resources
    available at any given time as users only register a limited
    number of locations (rarely more than one).
 o  Confidentiality.  In file-sharing applications, eavesdropping and
    identity theft do not constitute real threats; after all, files
    are supposed to be made publicly available.  This is not true in
    realtime communications, where the privacy and confidentiality of
    the participants are of paramount importance.  Furthermore, the
    notion of identity plays an important role in realtime

Schulzrinne, et al. Informational [Page 16] RFC 5765 Security in P2P Realtime Communications February 2010

    communications since it is the basis for starting a communication
    session.  As such, it is essential to have mechanisms to
    unequivocally assert identities in realtime communication systems.
 In this section we go over the admission issues and security problems
 discussed in previous sections, and discuss solutions that would be
 applicable to realtime communication in P2P.

7.1. Peer Promotion

 In order to remain compatible with existing user agents, P2P
 communication architectures would have to allow certain nodes to use
 their services without actually using overlay-specific semantics.
 One way to achieve this would be for overlay-agnostic nodes to
 register with an existing peer or a dedicated proxy via a standard
 protocol like SIP [RFC3261].  Through the rest of this document, we
 will refer to nodes that access the service without actually joining
 the overlay as "clients".
 In most cases, users would be able to benefit from the overlay by
 only acting as clients.  However, in order to keep the solution
 scalable, at some point clients would have to be promoted to peers
 (admission to the DHT).  This requires addressing the following
 issues.

7.1.1. Active vs. Passive Upgrades

 Most existing P2P networks [KAZAA] [BITTORRENT] [PPLIVE] would
 generally leave it to the clients to determine if and when they would
 apply for becoming peers.  A well-known exception to this trend is
 the Skype network [SKYPE], arguably one of the most popular overlay
 networks used for realtime communications today.  Instances of the
 Skype application are supposed to operate as either super-nodes,
 directly contributing to the distributed provision of the service, or
 ordinary-nodes, simply using the service, and the "promotions" are
 decided by the higher levels of the hierarchy [Baset].  Even if there
 is not much difference for a client whether it has to actively ask
 for authorization to join an overlay or passively wait for an
 invitation, the latter approach has some advantages that fit well in
 overlays where only a subset of the peers is required to provide the
 service (as in realtime communication):
 o  An attacker cannot estimate in advance when and if it would be
    invited to join the overlay as a peer.
 o  It allows peers to perform long-lasting measurements on sets of
    candidates, in order to accurately select the most appropriate for
    upgrading and only invite it when they are "ready" to do so.  The

Schulzrinne, et al. Informational [Page 17] RFC 5765 Security in P2P Realtime Communications February 2010

    opposite approach, that is, when clients initiate the join
    themselves, adds an extra constraint for the peer that has to act
    upon the request since it doesn't know if and when the peer would
    attempt to join again.
 o  It discourages malicious peers from attempting Sybil and, more
    generally, brute force attacks, as only a small ratio of clients
    has chances to join the overlay (possibly after an accurate
    examination).

7.1.2. When to Upgrade

 In order to answer this question, one would have to define some
 criteria that would allow determination of the load on a peer and a
 reasonable threshold.  When the load exceeds this threshold, a client
 is invited to become a peer and share the load.  Several mechanisms
 to diagnose the status of P2P systems have recently been proposed
 [P2PSIP-DIAG]; in general, reasonable criteria for determining load
 can be:
 o  Number of clients attached.
 o  Bandwidth usage for DHT maintenance, forwarding requests, and
    responses to and from peers and from the attached clients.
 o  Memory usage for DHT routing table, DHT neighborhood table,
    application-specific data, and information about the attached
    clients.

7.1.3. Which Clients to Upgrade

 Selecting which clients to upgrade would require defining and keeping
 track of new metrics.  The exact set of metrics and how they
 influence decisions should be the subject of serious analysis and
 experimentation.  These could be based on the following observations:
 o  Uptime.  A peer could easily record the amount of time that it has
    been maintaining a connection with a client and take it into
    account when trying to determine whether or not to upgrade it.
 o  Level of activity.  It is reasonable to assume that the more a
    client uses the service (e.g., making phone calls), the less they
    would be willing to degrade it.
 o  Keeping track of history.  Peers could record history of the
    clients they invite and the way they contribute to the overlay.

Schulzrinne, et al. Informational [Page 18] RFC 5765 Security in P2P Realtime Communications February 2010

 Other metrics such as public vs. private IP addresses, computation
 power, and bandwidth should also be taken into account even though
 they do not necessarily have a direct impact on security.
 Note however that a set of colluded malicious peers can manufacture
 basically any criteria considered for the upgrade.  Furthermore,
 sophisticated peers can overload the system or run denial-of-service
 attacks against existing super-nodes in order to improve their
 chances of being upgraded.

7.1.4. Incentives for Clients

 Clients need to have incentives for accepting upgrades in order to
 prevent excessive burden on existing peers.  One way to handle this
 would be to maintain separate incentive management through the use of
 currency or credits.  Another option would involve embedding these
 incentives inside the protocol itself:
 o  Peers share with clients only a fraction of their bandwidth
    (uplink and downlink).  This would result in higher latency when
    using the services of the overlay as a client and better service
    quality for peers.
 o  Peers could restrict the number or types of calls that they allow
    clients to make.
 Introducing such incentives, however, may turn out to be somewhat
 risky.  Differences in quality would probably be perceptible for end
 users who would not always be able to understand the difference
 between the roles that their user agent is playing in the overlay.
 Such behavior may therefore be interpreted as arbitrary and make the
 service look unreliable.

7.2. Security

7.2.1. Targeted Denial of Service

 In addition to bombardment with queries as described in Section 2,
 the denial-of-service attack against an individual node can be
 conducted in DHTs if the peers that surround a particular ID are
 compromised.  These peers that act as proxy servers for the victim
 can fake the responses from the victim by sending fictitious error
 messages back to peers trying to establish a session.  Danezis et
 al.'s solution [Danezis] can also provide protection against such
 attacks, as in their solution peers vary the nodes used in queries.

Schulzrinne, et al. Informational [Page 19] RFC 5765 Security in P2P Realtime Communications February 2010

7.2.2. Man-in-the-Middle Attack

 The man-in-the-middle attack is well described by Seedorf [Seedorf1]
 in the particular case of P2PSIP [P2PSIP] and consists of an attack
 that exploits the lack of integrity when routing information.  A
 malicious node could return IP addresses of other malicious nodes
 when queried for a particular ID.  The requesting peer would then
 establish a session with a second malicious node, which would again
 return a "poisoned" reply.  This could go on until the Time to Live
 (TTL) expires and the requester gives up the "wild goose chase"
 [Danezis].  A simple way for entities to verify the correctness of
 the routing lookup is to employ iterative routing and to check the
 node-ID of every routing hop that is returned, and it should get
 closer to the desired ID with every hop.  However, this is not a
 strong check and can be defeated [Seedorf1].

7.2.3. Trust between Peers

 The effect of malicious peers could be mitigated by introducing the
 concept of trust within an overlay.  This can be done in different
 ways:
 o  Using certificates assigned by an external authority.  The
    drawback with this approach is that it requires a centralized
    element.
 o  Using certificates reciprocally signed by peers.  This mechanism
    is quite similar to PGP [Zimmermann]; every peer signs
    certificates of "friend" peers and trusts any other peer with a
    certificate signed by one of its friends.  However, even though it
    might be theoretically possible, in reality it is extremely
    difficult to obtain long enough trust chains.

7.2.4. Routing Call Signaling

 One way for implementing realtime communication overlays (as we have
 mentioned in earlier sections) would be to simply replace centralized
 entities in signaling protocols like SIP [RFC3261] with distributed
 services.  In some cases, this might imply reusing existing protocol
 mechanisms for routing signaling messages.  In the case of SIP, this
 would imply regarding peers as SIP proxies.  However, the design of
 SIP supposes that such proxies are trusted, and makes it possible for
 them to fork requests or change their destination, add or remove
 header fields, act as the remote party, and generally manipulate
 message content and semantics.

Schulzrinne, et al. Informational [Page 20] RFC 5765 Security in P2P Realtime Communications February 2010

 However, in a P2P environment where messages may be routed through
 numerous successive peers, some of which might be compromised, it is
 important not to treat them as trusted proxies.  One way to limit
 what peers can do is by protecting signaling with some kind of end-
 to-end encryption.
 Another option would be to extend existing signaling protocols and
 modify the way they route messages in order to guarantee secure end-
 to-end transmission.  Gurbani et al.  [Gurbani] define a similar
 mechanism for SIP that allows nodes to establish a secure channel by
 sending a CONNECT SIP request, and then tunnel all SIP messages
 through it, adopting a similar mechanism to the one used for
 upgrading from HTTP to HTTPS [RFC2818].

7.2.5. Integrity of Location Bindings

 It is important to ensure that the location that a user registers,
 usually a (URI, IP) pair, is what is returned to the requesting
 party.  Or the entities that issue the lookup request must be able to
 verify the integrity of this pair.  A pure P2P approach to allow
 verification of the integrity of location binding information is
 presented in [Seedorf2].  The idea is for an entity to choose an
 asymmetric key pair and hash its public key to generate its URI.  The
 entity then signs its present location with its private key and
 registers with the quadruple (URI, IP, signature, public key).  Any
 entity that looks up the URI and receives such a quadruple can then
 verify its integrity by using the public key and the certificate.
 Another possible merit of such an approach could be that it is
 possible to identify the malicious nodes and maintain a black list.
 However, the resulting URIs are not easy to remember and associate
 with entities.  Discovering these URIs and associating them with
 entities would therefore require some sort of a directory service.
 The authors suggest using existing authentication infrastructure for
 this such as a certified web service using SSL that can publish an
 "online phone book" mapping users to URIs.

7.2.6. Encrypting Content

 Using P2P overlays for realtime communication implies that content is
 likely to traverse numerous intermediate peers before reaching its
 destination.  A typical example could be the use of peers as media
 relays as a way of traversing NATs in VoIP calls.
 Contrary to publicly shared files, communication sessions are in most
 cases expected to be private.  It is therefore very important to make
 sure that no media leaves the client application without being
 encrypted and securely transported through a protocol like SRTP
 [RFC3711].  However, the processing required by the encryption

Schulzrinne, et al. Informational [Page 21] RFC 5765 Security in P2P Realtime Communications February 2010

 algorithms and the extra resources necessary for managing the keying
 material (e.g., for retrieving public keys when interacting with
 unknown peers) may be expensive, especially for mobile devices.

7.2.7. Other Issues

 Details on cost and payment regimes could help identify further
 threats.  Such details could also be important when determining the
 impact of a potential attack in the context of the specific business
 models associated with particular overlays.  In many cases, answers
 to the following simple questions significantly aid the design of
 protection mechanisms:
 o  Whom do the users pay?
 o  Do the users only pay when accessing the public telephone network?
 o  Is the billing done per call or is it fixed?
 For instance, the implications of an attack such as taking control
 over another's user agent or its identity and using it for outbound
 calls would depend on whether or not this would be economically
 advantageous for the attacker.  Baumann et al.  [Baumann] suggest
 that to prevent unwanted communication costs, gateways for the public
 telephone network should only be accessible via authenticated servers
 and dialing authorizations should be enforced.  Also, it seems that
 it would be difficult to do billing in a pure P2P manner as it would
 mean keeping the billing details with untrusted peers.

8. Open Issues

 Existing systems used for file-sharing, media streaming, and realtime
 communications all achieve a reasonable level of security relying on
 centralized components (e.g., login servers in Skype [Baset],
 moderators and trackers in BitTorrent [Pouwelse]).  Securing pure P2P
 networks is therefore still a very active research field; at the time
 of writing the main open issues fall in five areas:
 o  Secure assignment of node IDs.
 o  Entity-identity association.
 o  Distributed trust among peers.
 o  Resistance against malicious peer collusion.
 o  Robustness and damage recovery.

Schulzrinne, et al. Informational [Page 22] RFC 5765 Security in P2P Realtime Communications February 2010

 In general, P2P overlays are designed to work when the vast majority
 of their peers are interested in the service provided by the system
 and act benevolently.  Understanding how operations in different
 overlays are perturbed as the number of malicious or compromised
 peers grows is another interesting area of research.  Also, a widely
 adopted methodology for the evaluation and classification of security
 solutions would be likely to help research in the field of P2P
 security progress more efficiently.

9. Security Considerations

 This document, tutorial in nature, discusses some of the security
 issues of P2P systems used for realtime communications.  It does not
 aim at identifying all possible threats and the corresponding
 solutions; instead, starting from an analysis of the attackers, it
 delves into some important aspects of P2P security, referencing the
 most relevant works published at the time of writing and discussing
 how they apply (or could apply) to the case of realtime
 communications.

10. Acknowledgments

 The authors are particularly grateful to Dhruv Chopra, who
 contributed to the writing of the article "Peer-to-peer Overlays for
 Real-Time Communication: Security Issues and Solutions" (IEEE Surveys
 & Tutorials, Vol. 11, No. 1) from which this work is partially
 derived.
 The authors would also like to thank Vijay Gurbani and Song Haibin
 for reviewing the document and the many others who provided useful
 comments.

11. Informative References

 [Ahn]          Ahn, L., Blum, M., and J. Langford, "Telling humans
                and computers apart automatically", Communications of
                the ACM, vol. 47, no. 2, February 2004.
 [Androutsellis-Theotokis]
                Androutsellis-Theotokis, S. and D. Spinellis, "A
                survey of peer-to-peer content distribution
                technologies", ACM CSUR, vol. 36, no. 4,
                December 2004.
 [BITTORRENT]   "BitTorrent", <http://www.bittorrent.com/>.

Schulzrinne, et al. Informational [Page 23] RFC 5765 Security in P2P Realtime Communications February 2010

 [Baset]        Baset, S. and H. Schulzrinne, "An analysis of the
                skype peer-to-peer internet telephony protocol",
                Proceedings of IEEE INFOCOM 2006, April 2006.
 [Baumann]      Baumann, R., Cavin, S., and S. Schmid, "Voice Over IP
                - Security and SPIT", Technical Report, University of
                Berne, September 2006.
 [COOLSTREAM]   "COOLSTREAMING", <http://www.coolstreaming.us>.
 [Castro]       Castro, M., Druschel, P., Ganesh, A., Rowstron, A.,
                and D.  Wallach, "Secure routing for structured
                peer-to-peer overlay networks", Proceedings of 5th
                symposium on Operating systems design and
                implementation, December 2002.
 [Chellapilla]  Chellapilla, K. and P. Simard, "Using Machine Learning
                to Break Visual Human Interaction Proofs (HIPs)",
                Proceedings of Advances in Neural Information
                Processing Systems, December 2004.
 [Condie]       Condie, T., Kacholia, V., Sankararaman, S.,
                Hellerstein, J., and P. Maniatis, "Maelstorm: Churn as
                Shelter", Proceedings of 13th Annual Network and
                Distributed System Security Symposium, November 2005.
 [Damiani]      Damiani, E., Vimercati, D., Paraboschi, S., Samarati,
                P., and F. Violante, "A Reputation-Based Approach for
                Choosing Reliable Resources in Peer-to-Peer Networks",
                Proceedings of Conference on Computer and
                Communications Security, November 2002.
 [Danezis]      Danezis, G., Lesniewski-Laas, C., Kaashoek, M., and R.
                Anderson, "Sybil-resistant DHT routing", Proceedings
                of 10th European Symposium on Research in Computer
                Security, September 2005.
 [Douceur]      Douceur, J., "The Sybil Attack", Revised Papers
                from First International Workshop on Peer-to-Peer
                Systems, March 2002.
 [Gurbani]      Gurbani, V., Willis, D., and F. Audet,
                "Cryptographically Transparent Session Initiation
                Protocol (SIP) Proxies", Proceedings of IEEE ICC '07,
                June 2007.
 [KAZAA]        "KaZaa", <http://www.kazaa.com/>.

Schulzrinne, et al. Informational [Page 24] RFC 5765 Security in P2P Realtime Communications February 2010

 [Kamvar]       Kamvar, S., Garcia-Molina, H., and M. Schlosser, "The
                EigenTrust Algorithm for Reputation Management in P2P
                Networks", Proceedings of 12th international
                conference on World Wide Web, May 2003.
 [Kim]          Kim, Y., Mazzocchi, D., and G. Tsudik, "Admission
                Control in Peer Groups", Proceedings of Second IEEE
                International Symposium on Network Computing and
                Applications, April 2003.
 [Kong]         Kong, J., Zerfos, P., Luo, H., Lu, S., and L. Zhang,
                "Providing robust and ubiquitous security support for
                MANET", Proceedings of 9th International Conference on
                Network Protocols, November 2001.
 [Lee]          Lee, S., Kwon, O., Kim, J., and S. Hong, "A Reputation
                Management System in Structured Peer-to-Peer
                Networks", Proceedings of 14th IEEE International
                Workshops on Enabling Technologies: Infrastructure for
                Collaborative Enterprise, June 2005.
 [Liang]        Liang, J., Kumar, R., Xi, Y., and K. Ross, "Pollution
                in p2p file sharing systems", Proceedings of IEEE
                INFOCOM 2005, March 2005.
 [Marti]        Marti, S., Ganesan, P., and H. Garcia-Molina, "SPROUT:
                P2P Routing with Social Networks", Proceedings
                of First International Workshop on Peer-to-Peer and
                Databases, March 2004.
 [Maymounkov]   Maymounkov, P. and D. Mazi, "Kademlia: A Peer-to-peer
                Information System Based on the XOR Metric",
                Proceedings of First International Workshop on
                Peer-to-peer Systems, March 2002.
 [McCue]        McCue, Andy., "Bookie reveals 100,000 cost of
                denial-of-service extortion attacks", available from
                http://www.silicon.com, June 2004.
 [NAPSTER]      "Napster", <http://www.napster.com/>.
 [Ohta]         Ohta, K., Micali, S., and L. Reyzin, "Accountable
                Subgroup Multisignatures", Proceedings of 8th ACM
                conference on Computer and Communications Security,
                November 2001.

Schulzrinne, et al. Informational [Page 25] RFC 5765 Security in P2P Realtime Communications February 2010

 [P2PSIP]       "Peer-to-Peer Session Initiation Protocol (P2PSIP)
                IETF Working Group",
                <http://www.ietf.org/html.charters/
                p2psip-charter.html>.
 [P2PSIP-DIAG] Yongchao, S., Jiang, X., Even, R., and D. Bryan,
                "P2PSIP Overlay Diagnostics", Work in Progress,
                December 2009.
 [PPLIVE]       "PPLive", <http://www.pplive.com>.
 [Poon]         Poon, W. and R. Chang, "Robust Forwarding in
                Structured Peer-to-Peer Overlay Networks", Proceedings
                of ACM SIGCOMM 2004, August 2004.
 [Pouwelse]     Pouwelse, J., Garbacki, P., Epema, D., and H. Sips,
                "The Bittorent P2P File-Sharing System: Measurements
                and Analysis", Proceedings of 4th International
                Workshop of Peer-to-peer Systems, February 2005.
 [RFC2818]      Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
 [RFC3261]      Rosenberg, J., Schulzrinne, H., Camarillo, G.,
                Johnston, A., Peterson, J., Sparks, R., Handley, M.,
                and E.  Schooler, "SIP: Session Initiation Protocol",
                RFC 3261, June 2002.
 [RFC3711]      Baugher, M., McGrew, D., Naslund, M., Carrara, E., and
                K.  Norrman, "The Secure Real-time Transport Protocol
                (SRTP)", RFC 3711, March 2004.
 [RFC4981]      Risson, J. and T. Moors, "Survey of Research towards
                Robust Peer-to-Peer Networks: Search Methods",
                RFC 4981, September 2007.
 [Ratnasamy]    Ratnasamy, S., Francis, P., Handley, M., Karp, R., and
                S.  Shenker, "A Scalable Content-Addressable Network",
                Proceedings of ACM SIGCOMM 2001, January 2001.
 [Rowaihy]      Rowaihy, H., Enck, W., McDaniel, P., and T. Porta,
                "Limiting Sybil attacks in structured peer-to-peer
                networks", Proceedings of IEEE INFOCOM 2007, May 2007.
 [Rowstron]     Rowstron, A. and P. Druschel, "Pastry: Scalable,
                distributed object location and routing for
                large-scale peer-to-peer systems", Proceedings of 18th
                IFIP/ACM International Conference on Distributed
                Systems Platforms (Middleware 2001), November 2001.

Schulzrinne, et al. Informational [Page 26] RFC 5765 Security in P2P Realtime Communications February 2010

 [SHA1]         180-1, FIPS., "Secure Hash Standard", April 2005.
 [SKYPE]        "Skype", <http://www.skype.com/>.
 [Saxena]       Saxena, N., Tsudik, G., and J. Yi, "Admission Control
                in Peer-to-Peer: Design and Performance Evaluation",
                Proceedings of 1st ACM workshop on Security of ad hoc
                and sensor networks, October 2003.
 [Scheideler]   Scheideler, C., "How to Spread Adversarial Nodes?:
                Rotate!", Proceedings of 37th Annual ACM Symposium on
                Theory of Computing, May 2005.
 [Seedorf1]     Seedorf, J., "Security Challenges for Peer-to-Peer
                SIP", IEEE Network, vol. 20, no. 5, September 2006.
 [Seedorf2]     Seedorf, J., "Using Cryptographically Generated
                SIP-URIs to Protect the Integrity of Content in
                P2P-SIP", Proceedings of 3rd Annual VoIP Security
                Workshop, June 2006.
 [Singh]        Singh, K. and H. Schulzrinne, "Peer-to-Peer Internet
                Telephony using SIP", Proceedings of International
                Workshop on Network and Operating System Support for
                Digital Audio and Video, June 2005.
 [Sit]          Sit, E. and R. Morris, "Security considerations for
                peer- to-peer distributed hash tables", Revised Papers
                from First International Workshop on Peer-to-Peer
                Systems, March 2002.
 [Stoica]       Stoica, I., Morris, R., Karger, D., Kaashoek, M., and
                H.  Balakrishnan, "Chord: A Scalable Peer-to-peer
                Lookup Service for Internet Applications", Proceedings
                of Applications, Technologies, Architectures, and
                Protocols for Computer Communication 2001, May 2001.
 [Tam]          Tam, J., Simsa, J., Hyde, S., and L. Ahn, "Breaking
                Audio CAPTCHAs with Machine Learning Techniques",
                Proceedings of Advances in Neural Information
                Processing Systems, December 2009.
 [Uzun]         Uzun, E., Pariente, M., and A. Selpk, "A
                Reputation-Based Trust Management System for P2P
                Networks", Proceedings of International Symposium on
                Cluster Computing and the Grids, April 2004.

Schulzrinne, et al. Informational [Page 27] RFC 5765 Security in P2P Realtime Communications February 2010

 [Wallach]      Wallach, D., "A Survey of Peer-to-Peer Security
                Issues", Proceedings of International Symposium of
                Software Security 2002, November 2002,
                <http://www.cs.rice.edu/~dwallach/pub/
                tokyo-p2p2002.pdf>.
 [Yu]           Yu, H., Kaminsky, M., Gibbons, P., and A. Flaxman,
                "SybilGuard: Defending Against Sybil Attacks via
                Social Networks", Proceedings of ACM SIGCOMM 2006,
                September 2006.
 [Zhang]        Zhang, X., Chen, S., and R. Sandhu, "Enhancing Data
                Authenticity and Integrity in P2P Systems", IEEE
                Internet Computing, vol. 9, no. 6, September 2005.
 [Zimmermann]   Zimmermann, Philip., "Pretty good privacy: public key
                encryption for the masses", Building in big brother:
                the cryptographic policy debate pag. 103-107, 1995.

Authors' Addresses

 Henning Schulzrinne
 Columbia University
 1214 Amsterdam Avenue
 New York, NY  10027
 USA
 EMail: hgs@cs.columbia.edu
 Enrico Marocco
 Telecom Italia
 Via G. Reiss Romoli, 274
 Turin  10148
 Italy
 EMail: enrico.marocco@telecomitalia.it
 Emil Ivov
 SIP Communicator / University of Strasbourg
 4 rue Blaise Pascal
 Strasbourg Cedex  F-67070
 France
 EMail: emcho@sip-communicator.org

Schulzrinne, et al. Informational [Page 28]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5765.txt · Last modified: 2010/02/23 00:16 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki