Network Working Group                                     H. Schulzrinne
Internet-Draft                                       Columbia University
Intended status: Informational                                E. Marocco
Expires: August 26, 2009                                  Telecom Italia
                                                                 E. Ivov
                                                        SIP Communicator
                                                       February 22, 2009

   Security Issues and Solutions in Peer-to-peer Systems for Realtime

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may not be modified,
   and derivative works of it may not be created, except to format it
   for publication as an RFC and to translate it into languages other
   than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on August 26, 2009.

Copyright Notice

   Copyright (c) 2009 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
   ( in effect on the date of
   publication of this document.  Please review these documents

Schulzrinne, et al.      Expires August 26, 2009                [Page 1]

Internet-Draft   Security in P2P Realtime Communications   February 2009

   carefully, as they describe your rights and restrictions with respect
   to this document.


   Peer-to-peer (P2P) networks offer higher robustness against failure,
   easier configuration and are generally more economical than their
   client-server counterparts.  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.

Schulzrinne, et al.      Expires August 26, 2009                [Page 2]

Internet-Draft   Security in P2P Realtime Communications   February 2009

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Purpose of this document . . . . . . . . . . . . . . . . .  6
   2.  The attackers  . . . . . . . . . . . . . . . . . . . . . . . .  6
     2.1.  Incentive of the attacker  . . . . . . . . . . . . . . . .  6
     2.2.  Resources available to the attacker  . . . . . . . . . . .  7
     2.3.  Victim of the attack . . . . . . . . . . . . . . . . . . .  7
     2.4.  Time of attack . . . . . . . . . . . . . . . . . . . . . .  7
   3.  Admission control  . . . . . . . . . . . . . . . . . . . . . .  8
   4.  Determining the position in the overlay  . . . . . . . . . . .  9
   5.  Resilience against malicious peers . . . . . . . . . . . . . . 10
     5.1.  Identification of malicious peers  . . . . . . . . . . . . 10
       5.1.1.  Proactive identification . . . . . . . . . . . . . . . 10
       5.1.2.  Reactive identification  . . . . . . . . . . . . . . . 11
     5.2.  Reputation management systems  . . . . . . . . . . . . . . 11
       5.2.1.  Unstructured reputation management . . . . . . . . . . 11
       5.2.2.  Structured reputation management . . . . . . . . . . . 12
   6.  Routing and data integrity . . . . . . . . . . . . . . . . . . 12
     6.1.  Data integrity . . . . . . . . . . . . . . . . . . . . . . 12
     6.2.  Routing integrity  . . . . . . . . . . . . . . . . . . . . 13
   7.  Peer-to-peer in realtime communication . . . . . . . . . . . . 13
     7.1.  Admission  . . . . . . . . . . . . . . . . . . . . . . . . 14
       7.1.1.  Active vs. passive upgrades  . . . . . . . . . . . . . 14
       7.1.2.  When to upgrade  . . . . . . . . . . . . . . . . . . . 15
       7.1.3.  Which clients to upgrade . . . . . . . . . . . . . . . 15
       7.1.4.  Incentives for clients . . . . . . . . . . . . . . . . 15
     7.2.  Security . . . . . . . . . . . . . . . . . . . . . . . . . 16
       7.2.1.  Targeted denial of service . . . . . . . . . . . . . . 16
       7.2.2.  Man in the middle attack . . . . . . . . . . . . . . . 16
       7.2.3.  Trust between peers  . . . . . . . . . . . . . . . . . 16
       7.2.4.  Routing call signalization . . . . . . . . . . . . . . 17
       7.2.5.  Integrity of location bindings . . . . . . . . . . . . 17
       7.2.6.  Encrypting content . . . . . . . . . . . . . . . . . . 18
       7.2.7.  Other issues . . . . . . . . . . . . . . . . . . . . . 18
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 19
   10. Informative references . . . . . . . . . . . . . . . . . . . . 19
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22

Schulzrinne, et al.      Expires August 26, 2009                [Page 3]

Internet-Draft   Security in P2P Realtime Communications   February 2009

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 [JOOST] [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.  Unstructured
   overlays are often relatively simple but search operations in them
   tend to be inefficient.  Structured P2P overlays use distributed hash
   tables (DHT) 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 (i.e. computation power, access to different
   IP subnets) that they would have at their disposal.

   Once the threat has been identified, admission control is the first
   step towards security [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.

   This document, after discussing some of the main security issues and
   proposed solutions for P2P systems in general, focuses on one
   particular application -- realtime communication.  The idea behind
   P2P realtime communication is using the DHTs employed by file-sharing
   applications, in order to implement services such as registration,
   user location lookup, and assistance with NAT and firewall traversal.
   Even if, from a technical point of view, P2P communication services
   may seem similar to file-sharing, Table 1 shows that some important
   differences, mostly related to privacy and availability,
   significantly increase security requirements.

Schulzrinne, et al.      Expires August 26, 2009                [Page 4]

Internet-Draft   Security in P2P Realtime Communications   February 2009

   |                 | 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 user.           |
   |                 | per user.             |                         |
   | 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   |
   |                 | istances are overcame | to the user's device    |
   |                 | by abundancy of       | directly.               |
   |                 | 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; evesdropping |
   |                 | used to avoid         | may reveal sensitive    |
   |                 | elements not involved | data and is a serious   |
   |                 | in the service to     | threat for users.       |
   |                 | detect traffic.       |                         |

    Main differences between P2P applications used for file-sharing and
                        for realtime communication.

                                  Table 1

Schulzrinne, et al.      Expires August 26, 2009                [Page 5]

Internet-Draft   Security in P2P Realtime Communications   February 2009

   The rest of 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.

1.1.  Purpose of this document

   This document is partially derived from the article "Peer-to-peer
   Overlays for Real-Time Communications: 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.  Its goal is to collect feedback from the IRTF community
   in order to document the advances in the field of security of P2P
   systems for realtime communications, for the benefit of related
   standardization activities going on in IETF.

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.
   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, such attacks are still possible
   against individuals within the overlay if the attackers possess
   sufficient resources.  For instance, a network of worm-affected
   malicious nodes spread across the Internet and controlled by an
   attacker (often referred 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 apart from money.  With the
   growth of illegal usage of sharing files with copyrights, record
   companies have been known to attempt polluting 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

Schulzrinne, et al.      Expires August 26, 2009                [Page 6]

Internet-Draft   Security in P2P Realtime Communications   February 2009

   users would get frustrated and stop using the service.  Attacks can
   also be launched by novice attackers who are there 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.
   Doucer [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.

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 malcontent, then the quality of the overlay would

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 [KADEMLIA], 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 which start misbehaving in a later stage (i.e., after they have

Schulzrinne, et al.      Expires August 26, 2009                [Page 7]

Internet-Draft   Security in P2P Realtime Communications   February 2009

   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 of
   service attacks targeted to the central authority).  The latter, 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

Schulzrinne, et al.      Expires August 26, 2009                [Page 8]

Internet-Draft   Security in P2P Realtime Communications   February 2009

   easily addressed by humans but hard to solve by computers, also known
   as CAPTCHA [Ahn].

4.  Determining the position in the overlay

   For ring based DHT overlays such as Chord [Stoica], Kademlia
   [KADEMLIA] and Pastry [PASTRY], 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 and thus avoid a trust
   bottleneck.  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 which are the furthest
   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.  Authors

Schulzrinne, et al.      Expires August 26, 2009                [Page 9]

Internet-Draft   Security in P2P Realtime Communications   February 2009

   use 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 kind 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
   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 it is responsible for (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

Schulzrinne, et al.      Expires August 26, 2009               [Page 10]

Internet-Draft   Security in P2P Realtime Communications   February 2009

   scalability, while, if they are performed too rarely, they would
   probably be useless.

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.  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.

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 [Uzun] [Damiani] [Lee] [Kamvar] are for
   file-sharing applications.  In reputation systems, it should not be
   possible for a misbehaving peer with low reputation to simply rejoin
   the network with a different ID and therefore start from a clean
   slate.  To counter this, Kwon 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].
   Kamvar et. al [Kamvar] define five design considerations for
   reputation management systems;
   o  Self policing.
   o  Anonymity.
   o  No profit to new comers.
   o  Minimal overhead.
   o  Robustness to malicious peers.

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 that it has interacted
   with.  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

Schulzrinne, et al.      Expires August 26, 2009               [Page 11]

Internet-Draft   Security in P2P Realtime Communications   February 2009

   looking up content.  However, such an approach requires peers to get
   reputation information from as many sources as possible; otherwise,
   malicious nodes may succesfully 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
   from all, then the they incur large traffic overhead.  Systems such
   as 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.  The algorithm has fast convergence
   properties [Haveliwala].  For maintaining this information in a
   structured way, the authors use a content addressable network (CAN)
   DHT [Ratnasamy].  The information of 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
   separately in Section 7.

6.1.  Data integrity

   For file-sharing applications, insertion of wrong content (e.g. files
   not matching their names or descriptions) or introduction of corrupt
   data chunks (often referred to as poisoning and pollution) are a
   significant problem.  Bit-Torrent 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,

Schulzrinne, et al.      Expires August 26, 2009               [Page 12]

Internet-Draft   Security in P2P Realtime Communications   February 2009

   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 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 can not 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 [PASTRY] and Kademlia
   [KADEMLIA] 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

7.  Peer-to-peer in realtime communication

   The idea of using P2P in realtime communication boils down to
   distributing centralized entities from conventional architectures
   over peer-to-peer 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
   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

Schulzrinne, et al.      Expires August 26, 2009               [Page 13]

Internet-Draft   Security in P2P Realtime Communications   February 2009

      available at any given time as users only register a limited
      number of locations (rarely more than one).
   o  Confidentiality.  While in file sharing applications, where shared
      files are supposed to be made publicly available, eavesdropping
      and identity theft do not constitute real threats, in realtime
      communication, since exchanges of data are usually meant to happen
      privately, it is essential to have mechanisms to assert identities
      and to guarantee confidentiality.

   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.  Admission

   In order to keep as much compatibility with existing user agents as
   possible, nodes in P2P communication architectures would probably
   have to participate as either peers or clients.  If a node
   participates as a client, then it would use the overlay network by
   simply attaching to a peer or a proxy instead of registering with a
   server.  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

7.1.1.  Active vs. passive upgrades

   Most existing P2P networks [KAZAA] [BITTORRENT] [JOOST] would
   generally make it the responsibility of 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 which fit well in overlays where only a subset of the
   peers is required to provide the service (as in realtime
   o  An attacker cannot estimate in advance when and if it would be
      invited to join the overlay as a peer.
   o  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.

Schulzrinne, et al.      Expires August 26, 2009               [Page 14]

Internet-Draft   Security in P2P Realtime Communications   February 2009

      The 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  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

7.1.2.  When to upgrade

   In order to answer this question one would have to define some
   criteria that would allow to determine 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.  The 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

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.
   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.

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:

Schulzrinne, et al.      Expires August 26, 2009               [Page 15]

Internet-Draft   Security in P2P Realtime Communications   February 2009

   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 used for realtime communications if the peers which
   surround a particular ID are compromised.  These peers which 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.

7.2.2.  Man in the middle attack

   The man in the middle attack is well described by Seedorf [Seedorf06]
   in the particular case of P2PSIP [P2PSIP] and consist 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 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 it 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 [Seedorf06].

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

Schulzrinne, et al.      Expires August 26, 2009               [Page 16]

Internet-Draft   Security in P2P Realtime Communications   February 2009

   o  Using certificates assigned by an external authority.  The
      drawback with this approach is that it requires a centralized
   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 signalization

   One way for implementing realtime communication overlays (as we have
   mentioned in earlier sections) would be to simply replace centralized
   entities in signalling protocols like SIP [RFC3261] with distributed
   services.  In some cases this might imply reusing existing protocol
   mechanisms for routing signalling 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

   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 signalling with some kind of end-
   to-end encryption.

   Another option would be to extend existing signalling protocols and
   modify the way they route messages in order to guarantee secure end-
   to-end transmission.  Gurbani et al. define a similar mechanism for
   SIP called SIPSEC [I-D.gurbani-sip-sipsec].  It 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 [Seedorf08].  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

Schulzrinne, et al.      Expires August 26, 2009               [Page 17]

Internet-Draft   Security in P2P Realtime Communications   February 2009

   entity which looks up for 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
   which 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 extra processing resources required by the
   encryption algorithms, the management of keying material (e.g.,
   retrieving public keys when interacting with unknown peers) may
   constitute an expensive task, especially for mobile devices.

7.2.7.  Other issues

   Identifying more specific threats related to the P2P realtime
   communications, would require a clearly defined economic model.
   Answers to the following questions would be helpful.
   o  To 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] suggests
   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.

Schulzrinne, et al.      Expires August 26, 2009               [Page 18]

Internet-Draft   Security in P2P Realtime Communications   February 2009

8.  Security Considerations

   This document, informative in nature, discusses some of the security
   issues of peer-to-peer systems used for realtime communications.

9.  Acknowledgments

   The authors are particularly grateful to Dhruv Chopra who contributed
   to the writing of the article "Peer-to-peer Overlays for Real-Time
   Communications: Issues and Solutions" (IEEE Surveys & Tutorials, Vol.
   11, No. 1) this work is partially derived from.

10.  Informative references

   [Ahn]      Ahn, Luis., Blum, Manuel., and John. Langford, "Telling
              humans and computers apart automatically".

              Androutsellis-Theotokis, S. and D. Spinellis, "A survey of
              peer-to-peer content distribution technologies".

              "BitTorrent", <>.

   [Baset]    Baset, S. and H. Schulzrinne, "An analysis of the skype
              peer-to-peer internet telephony protocol".

   [Baumann]  Baumann, R., Cavin, S., and S. Schmid, "Voice Over IP -
              Security and SPIT".

              "COOLSTREAMING", <>.

   [Castro]   Castro, M., Druschel, P., Ganesh, A., Rowstron, A., and D.
              Wallach, "Secure routing for structured peer-to-peer
              overlay networks".

   [Condie]   Condie, T., Kacholia, V., Sankararaman, S., Hellerstein,
              J., and P. Maniatis, "Maelstorm: Churn as Shelter".

   [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".

   [Danezis]  Danezis, G., Lesniewski-Laas, C., Kaashoek, M., and R.
              Anderson, "Sybil-resistant DHT routing".

Schulzrinne, et al.      Expires August 26, 2009               [Page 19]

Internet-Draft   Security in P2P Realtime Communications   February 2009

   [Douceur]  Douceur, J., "The Sybil Attack".

              Haveliwala, T. and S. Kamvar, "The second value eigenvalue
              of the google matrix".

              Gurbani, V., Audet, F., and D. Willis, "The SIPSEC Uniform
              Resource Identifier (URI)", draft-gurbani-sip-sipsec-01
              (work in progress), June 2007.

   [JOOST]    "Joost", <>.

              Maymounkov, P. and D. Mazi, "Kademlia: A Peer-to-peer
              Information System Based on the XOR Metric".

   [KAZAA]    "KaZaa", <>.

   [Kamvar]   Kamvar, S., Garcia-Molina, H., and M. Schlosser, "The
              EigenTrust Algorithm for Reputation Management in P2P

   [Kim]      Kim, Y., Mazzocchi, D., and G. Tsudik, "Admission Control
              in Peer Groups".

   [Kong]     Kong, J., Zerfos, P., Luo, H., Lu, S., and L. Zhang,
              "Providing robust and ubiquitous security support for

   [Lee]      Lee, S., Kwon, O., Kim, J., and S. Hong, "A Reputation
              Management System in Structured Peer-to-Peer Networks".

   [Liang]    Liang, J., Kumar, R., Xi, Y., and K. Ross, "Pollution in
              p2p file sharing systems".

   [Marti]    Marti, S., Ganesan, P., and H. Garcia-Molina, "SPROUT: P2P
              Routing with Social Networks".

   [McCue]    McCue, Andy., "Bookie reveals 100,000 cost of denial-of-
              service extortion attacks", <

   [NAPSTER]  "Napster", <>.

   [Ohta]     Ohta, K., Micali, S., and L. Reyzin, "Accountable Subgroup

Schulzrinne, et al.      Expires August 26, 2009               [Page 20]

Internet-Draft   Security in P2P Realtime Communications   February 2009

   [P2PSIP]   "Peer-to-Peer Session Initiation Protocol (P2PSIP) IETF
              Working Group",

   [PASTRY]   Rowstron, A. and P. Druschel, "Pastry: Scalable,
              distributed object location and routing for large-scale
              peer-to-peer systems".

   [Poon]     Poon, W. and R. Chang, "Robust Forwarding in Structured
              Peer-to-Peer Overlay Networks".

              Pouwelse, J., Garbacki, P., Epema, D., and H. Sips, "The
              Bittorent P2P File-Sharing System: Measurements and

   [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.

              Ratnasamy, S., Francis, P., Handley, M., Karp, R., and S.
              Shenker, "A Scalable Content-Addressable Network".

   [Rowaihy]  Rowaihy, H., Enck, W., McDaniel, P., and T. Porta,
              "Limiting Sybil attacks in structured peer-to-peer

   [SHA1]     180-1, FIPS., "Secure Hash Standard".

   [SKYPE]    "Skype", <>.

   [Saxena]   Saxena, N., Tsudik, G., and J. Yi, "Admission Control in
              Peer-to-Peer: Design and Performance Evaluation".

              Scheideler, C., "How to Spread Adversarial Nodes?:

              Seedorf, J., "Security Challenges for Peer-to-Peer SIP".

Schulzrinne, et al.      Expires August 26, 2009               [Page 21]

Internet-Draft   Security in P2P Realtime Communications   February 2009

              Seedorf, J., "Using Cryptographically Generated SIP-URIs
              to Protect the Integrity of Content in P2P-SIP".

   [Singh]    Singh, K. and H. Schulzrinne, "Peer-to-Peer Internet
              Telephony using SIP".

   [Sit]      Sit, E. and R. Morris, "Security considerations for peer-
              to-peer distributed hash tables".

   [Stoica]   Stoica, I., Morris, R., Karger, D., Kaashoek, M., and H.
              Balakrishnan, "Chord: A Scalable Peer-to-peer Lookup
              Service for Internet Applications".

   [Uzun]     Uzun, E., Pariente, M., and A. Selpk, "A Reputation-Based
              Trust Management System for P2P Networks".

   [Wallach]  Wallach, D., "A Survey of Peer-to-Peer Security Issues",

   [Yu]       Yu, H., Kaminsky, M., Gibbons, P., and A. Flaxman,
              "SybilGuard: Defending Against Sybil Attacks via Social

   [Zhang]    Zhang, X., Chen, S., and R. Sandhu, "Enhancing Data
              Authenticity and Integrity in P2P Systems".

              Zimmermann, Philip., "Pretty good privacy: public key
              encryption for the masses".

Authors' Addresses

   Henning Schulzrinne
   Columbia University
   1214 Amsterdam Avenue
   New York, NY  10027


Schulzrinne, et al.      Expires August 26, 2009               [Page 22]

Internet-Draft   Security in P2P Realtime Communications   February 2009

   Enrico Marocco
   Telecom Italia
   Via G. Reiss Romoli, 274
   Turin  10148


   Emil Ivov
   SIP Communicator
   4 rue Blaise Pascal
   Strasbourg Cedex  F-67070


Schulzrinne, et al.      Expires August 26, 2009               [Page 23]