Security Issues and Solutions in Peer-to-Peer Systems for Realtime Communications
draft-irtf-p2prg-rtc-security-05
The information below is for an old version of the document that is already published as an RFC.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 5765.
|
|
|---|---|---|---|
| Authors | Emil Ivov , Enrico Marocco , Henning Schulzrinne | ||
| Last updated | 2020-07-29 (Latest revision 2009-09-18) | ||
| Replaces | draft-schulzrinne-p2prg-rtc-security | ||
| RFC stream | Internet Research Task Force (IRTF) | ||
| Intended RFC status | Informational | ||
| Formats | |||
| Stream | IRTF state | (None) | |
| Consensus boilerplate | Unknown | ||
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 5765 (Informational) | |
| Action Holders |
(None)
|
||
| Telechat date | (None) | ||
| Responsible AD | Robert Sparks | ||
| Send notices to | (None) |
draft-irtf-p2prg-rtc-security-05
Network Working Group H. Schulzrinne
Internet-Draft Columbia University
Intended status: Informational E. Marocco
Expires: March 22, 2010 Telecom Italia
E. Ivov
SIP Communicator / University of
Strasbourg
September 18, 2009
Security Issues and Solutions in Peer-to-peer Systems for Realtime
Communications
draft-irtf-p2prg-rtc-security-05
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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-
Drafts.
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
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 22, 2010.
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 (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Schulzrinne, et al. Expires March 22, 2010 [Page 1]
Internet-Draft Security in P2P Realtime Communications September 2009
Abstract
Peer-to-peer 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.
Schulzrinne, et al. Expires March 22, 2010 [Page 2]
Internet-Draft Security in P2P Realtime Communications September 2009
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 . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . 13
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 . . . . . . . . . . . . . . . . 18
7.2. Security . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.2.1. Targeted denial of service . . . . . . . . . . . . . . 19
7.2.2. Man in the middle attack . . . . . . . . . . . . . . . 19
7.2.3. Trust between peers . . . . . . . . . . . . . . . . . 19
7.2.4. Routing call signaling . . . . . . . . . . . . . . . . 20
7.2.5. Integrity of location bindings . . . . . . . . . . . . 20
7.2.6. Encrypting content . . . . . . . . . . . . . . . . . . 21
7.2.7. Other issues . . . . . . . . . . . . . . . . . . . . . 21
8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 22
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
11. Informative references . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
Schulzrinne, et al. Expires March 22, 2010 [Page 3]
Internet-Draft Security in P2P Realtime Communications September 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 [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 (DHT) [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, etc.) 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 of user location, the DHT being the substitute
for a centralized registration server.
At first glance, it may appear that requirements on peer-to-peer
systems for realtime communications services are no different than
Schulzrinne, et al. Expires March 22, 2010 [Page 4]
Internet-Draft Security in P2P Realtime Communications September 2009
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. Expires March 22, 2010 [Page 5]
Internet-Draft Security in P2P Realtime Communications September 2009
| 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 | to leave the overlay |
| | the time required for | 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. |
+-----------------+-----------------------+-------------------------+
Main differences between P2P applications used for file-sharing and
for realtime communication.
Table 1
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 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.
Schulzrinne, et al. Expires March 22, 2010 [Page 6]
Internet-Draft Security in P2P Realtime Communications September 2009
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 2.1, Section 2.2 |
| pollution | Section 2.1, Section 2.2 |
| sybil | Section 2.2, Section 4 |
| targeted denial of service | Section 7.2.1 |
+---------------------------------------+---------------------------+
Index of some of the more popular attacks and problems discussed in
this document.
Table 2
Schulzrinne, et al. Expires March 22, 2010 [Page 7]
Internet-Draft Security in P2P Realtime Communications September 2009
+---------------------------------------+---------------------------+
| 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 6.2, Section 4 |
| 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 |
+---------------------------------------+---------------------------+
Index of some of the more popular solutions discussed in this
document.
Table 3
2. The attackers
Schulzrinne, et al. Expires March 22, 2010 [Page 8]
Internet-Draft Security in P2P Realtime Communications September 2009
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, 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 communications 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
attemping 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.
Doucer [Douceur] proves that even with the assumption that attackers
Schulzrinne, et al. Expires March 22, 2010 [Page 9]
Internet-Draft Security in P2P Realtime Communications September 2009
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 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 which 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
Schulzrinne, et al. Expires March 22, 2010 [Page 10]
Internet-Draft Security in P2P Realtime Communications September 2009
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). 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
Schulzrinne, et al. Expires March 22, 2010 [Page 11]
Internet-Draft Security in P2P Realtime Communications September 2009
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 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 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. The
solutions 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 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.
Schulzrinne, et al. Expires March 22, 2010 [Page 12]
Internet-Draft Security in P2P Realtime Communications September 2009
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
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
Schulzrinne, et al. Expires March 22, 2010 [Page 13]
Internet-Draft Security in P2P Realtime Communications September 2009
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 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 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 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
those proposed by [Lee] [Kamvar] try to resolve it in a structured
Schulzrinne, et al. Expires March 22, 2010 [Page 14]
Internet-Draft Security in P2P Realtime Communications September 2009
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
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,
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
Schulzrinne, et al. Expires March 22, 2010 [Page 15]
Internet-Draft Security in P2P Realtime Communications September 2009
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 [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 is of paramount importance. Furthermore, the
notion of identity plays an important role in realtime
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.
Schulzrinne, et al. Expires March 22, 2010 [Page 16]
Internet-Draft Security in P2P Realtime Communications September 2009
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 which 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 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
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
Schulzrinne, et al. Expires March 22, 2010 [Page 17]
Internet-Draft Security in P2P Realtime Communications September 2009
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
[I-D.ietf-p2psip-diagnostics]; 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.
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
Schulzrinne, et al. Expires March 22, 2010 [Page 18]
Internet-Draft Security in P2P Realtime Communications September 2009
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.
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 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 [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:
Schulzrinne, et al. Expires March 22, 2010 [Page 19]
Internet-Draft Security in P2P Realtime Communications September 2009
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 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 [Gurbani] 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
Schulzrinne, et al. Expires March 22, 2010 [Page 20]
Internet-Draft Security in P2P Realtime Communications September 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
Details on cost and payment regimes could help identifying 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 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 March 22, 2010 [Page 21]
Internet-Draft Security in P2P Realtime Communications September 2009
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.
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
Communications: Issues and Solutions" (IEEE Surveys & Tutorials, Vol.
11, No. 1) this work is partially derived from.
The authors would also like to thank Vijay Gurbani and Song Haibin
for reviewing the document and the many others who provided useful
comments.
Schulzrinne, et al. Expires March 22, 2010 [Page 22]
Internet-Draft Security in P2P Realtime Communications September 2009
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/>.
[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.
Schulzrinne, et al. Expires March 22, 2010 [Page 23]
Internet-Draft Security in P2P Realtime Communications September 2009
[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.
[I-D.ietf-p2psip-diagnostics]
Yongchao, S. and X. Jiang, "Diagnose P2PSIP Overlay
Network", draft-ietf-p2psip-diagnostics-00 (work in
progress), January 2009.
[KAZAA] "KaZaa", <http://www.kazaa.com/>.
[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,
Schulzrinne, et al. Expires March 22, 2010 [Page 24]
Internet-Draft Security in P2P Realtime Communications September 2009
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", June 2004, <http://
software.silicon.com/security/0,39024655,39121278,00.htm>.
[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.
[P2PSIP] "Peer-to-Peer Session Initiation Protocol (P2PSIP) IETF
Working Group",
<http://ietf.org/html.charters/p2psip-charter.html>.
[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.
Schulzrinne, et al. Expires March 22, 2010 [Page 25]
Internet-Draft Security in P2P Realtime Communications September 2009
[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.
[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,
Schulzrinne, et al. Expires March 22, 2010 [Page 26]
Internet-Draft Security in P2P Realtime Communications September 2009
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.
[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
Schulzrinne, et al. Expires March 22, 2010 [Page 27]
Internet-Draft Security in P2P Realtime Communications September 2009
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. Expires March 22, 2010 [Page 28]