path: root/doc/rfc/rfc5765.txt

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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L