One document matched: draft-irtf-p2prg-rtc-security-05.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfcXXXX.dtd">
<rfc docName="draft-irtf-p2prg-rtc-security-05" category="info" ipr="trust200902">
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<front>
<title abbrev="Security in P2P Realtime Communications">
Security Issues and Solutions in Peer-to-peer Systems for Realtime
Communications
</title>
<author initials="H." surname="Schulzrinne"
fullname="Henning Schulzrinne">
<organization>Columbia University</organization>
<address>
<postal>
<street>1214 Amsterdam Avenue</street>
<city>New York, NY</city>
<code>10027</code>
<country>USA</country>
</postal>
<email>hgs@cs.columbia.edu</email>
</address>
</author>
<author initials="E." surname="Marocco" fullname="Enrico Marocco">
<organization>Telecom Italia</organization>
<address>
<postal>
<street>Via G. Reiss Romoli, 274</street>
<city>Turin</city>
<code>10148</code>
<country>Italy</country>
</postal>
<email>enrico.marocco@telecomitalia.it</email>
</address>
</author>
<author initials="E." surname="Ivov" fullname="Emil Ivov">
<organization>
SIP Communicator / University of Strasbourg
</organization>
<address>
<postal>
<street>4 rue Blaise Pascal</street>
<city>Strasbourg Cedex</city>
<code>F-67070</code>
<country>France</country>
</postal>
<email>emcho@sip-communicator.org</email>
</address>
</author>
<date day="18" month="September" year="2009"/>
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Peer-to-peer (P2P) overlays have become quite popular with the
advent of file-sharing applications such as <xref
target="NAPSTER">Napster</xref>, <xref
target="KAZAA">KaZaa</xref> and <xref
target="BITTORRENT">BitTorrent</xref>. After their success in
file-sharing and <xref target="Androutsellis-Theotokis">content
distribution</xref>, P2P networks are now also being used for
applications such as Voice over IP (VoIP) <xref target="SKYPE"/>
<xref target="Singh"/> and television <xref target="PPLIVE"/>
<xref target="COOLSTREAM"/>. However most of these systems are
not purely P2P and have centralized components like the login
server in Skype <xref target="Baset"/> or moderators and
trackers in BitTorrent <xref target="Pouwelse"/>. Securing pure
P2P networks is therefore still a field of very active research
<xref target="Wallach"/>.
</t>
<t>
P2P overlays can be broadly classified as structured and
unstructured <xref target="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) <xref target="Stoica"/> <xref target="Maymounkov"/>
<xref target="Rowstron"/> to perform directed searches which
make lookups more efficient in locating data. This document will
mostly focus on DHT-based P2P overlays.
</t>
<t>
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.
</t>
<t>
Once the threat has been identified, admission control is a
first step towards security that can help avoid a substantial
number of attacks <xref target="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.
</t>
<t>
Other P2P specific security problems discussed here include
attacks on the routing of queries, targeted denial of service
attacks and attacks on data integrity.
</t>
<t>
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.
</t>
<t>
At first glance, it may appear that requirements on peer-to-peer
systems for realtime communications services are no different than
those for file-sharing services. <xref target="tab:differences"/>
demonstrates that there are sizeable differences related to
privacy, availability, and a marked increase in the general
security requirements.
</t>
<texttable anchor="tab:differences">
<ttcol width="20%"></ttcol>
<ttcol width="40%">
File-sharing
</ttcol>
<ttcol width="40%">
Realtime communication
</ttcol>
<c>
Distributed database
</c>
<c>
Shared file locations are indexed in a table distributed
among peers; often hundreds or thousands per peer.
</c>
<c>
User locations are indexed in a table distributed among peers;
rarely more than one per peer.
</c>
<c>
Availability
</c>
<c>
Same files are usually available at multiple locations and
failures involving single instances are overcome by abundancy
of resources; attacks targeting single files need to be
addressed to the distributed index.
</c>
<c>
Users are unique; attacks targeting single users may be
addressed both to the distributed index and to the user's
device directly.
</c>
<c>
Integrity
</c>
<c>
Attackers may want to share corrupted files in place of
popular content, e.g. to discourage users from acquiring
copyrighted material; constitute a threat for the service, but
not for the users.
</c>
<c>
Attackers may want to impersonate different users in order to
handle calls directed to them; constitute a particular threat
for the user as, in case of success, the attacker acquires
full control on the victim's personal communications.
</c>
<c>
Confidentiality
</c>
<c>
Shared files are, by definition, readable by all users; in
some cases encryption is used to avoid elements not involved
in the service to detect traffic.
</c>
<c>
Communications are usually meant to be private and need to be
encrypted; eavesdropping may reveal sensitive data and is a
serious threat for users.
</c>
<c>
Bitrate and latency
</c>
<c>
The file-transfer use case is particularly tolerant to unstable
bitrates and ability to burst on and off as peers disappear or
new ones become available.
</c>
<c>
Realtime traffic almost always requires a constant minimum
bitrate and low latency in order to avoid problems like jitter.
While this is not 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.
</c>
<c>
Peer lifetime
</c>
<c>
File-sharing users do not need to stay in the overlay more
than the time required for downloading the content they are
looking for.
</c>
<c>
Realtime communication applications need not to leave the
overlay for as long as the user wants to stay connected and be
reachable. This gives the attackers longer time for conducting
successful targeted attacks.
</c>
<postamble>
Main differences between P2P applications used for
file-sharing and for realtime communication.
</postamble>
</texttable>
<section title="Purpose of this document">
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="Structure of this document">
<t>
The document is organized as follows. In <xref
target="attackers"/>, 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 <xref target="adm.ctrl"/>, we discuss
admission control problems. In <xref target="det.pos"/>, we
identify the problem of where a node joins in the overlay. In
<xref target="id.dis"/>, we describe problems related to
identification of malicious nodes and the dissemination of
this information. In <xref target="p2p.integrity"/>, we
describe the issues of routing and data integrity in P2P
networks. Finally, in <xref target="p2p.communication"/> we
discuss how issues and solutions previously presented apply in
P2P overlays for realtime communication.
</t>
<t>
<xref target="tab:attacks"/> and <xref
target="tab:solutions"/> provide an index of the attacks and
the solutions discussed in the rest of this document.
</t>
<texttable anchor="tab:attacks">
<ttcol width="60%">
Attack name
</ttcol>
<ttcol width="40%">
Referring sections
</ttcol>
<c>
botnets (use of)
</c>
<c>
<xref target="attack.incentives"/>,
<xref target="attack.resources"/>
</c>
<c>
denial of service (DoS)
</c>
<c>
<xref target="attack.incentives"/>, <xref target="dos"/>
</c>
<c>
man in the middle (MITM)
</c>
<c>
<xref target="mitm"/>
</c>
<c>
poisoning
</c>
<c>
<xref target="attack.incentives"/>,
<xref target="attack.resources"/>
</c>
<c>
pollution
</c>
<c>
<xref target="attack.incentives"/>,
<xref target="attack.resources"/>
</c>
<c>
sybil
</c>
<c>
<xref target="attack.resources"/>,
<xref target="det.pos"/>
</c>
<c>
targeted denial of service
</c>
<c>
<xref target="dos"/>
</c>
<postamble>
Index of some of the more popular attacks and problems
discussed in this document.
</postamble>
</texttable>
<texttable anchor="tab:solutions">
<ttcol width="60%">
Solution name
</ttcol>
<ttcol width="40%">
Referring sections
</ttcol>
<c>
admission control
</c>
<c>
<xref target="adm.ctrl"/>
</c>
<c>
anonymity
</c>
<c>
<xref target="reput.mgmt"/>
</c>
<c>
asymmetric key pair
</c>
<c>
<xref target="bindings.integrity"/>
</c>
<c>
CAPTCHA
</c>
<c>
<xref target="adm.ctrl"/>
</c>
<c>
certificates
</c>
<c>
<xref target="trust"/>
</c>
<c>
CONNECT (SIP method)
</c>
<c>
<xref target="call.sig.routing"/>
</c>
<c>
cryptographic puzzles
</c>
<c>
<xref target="det.pos"/>
</c>
<c>
diametrically opposite IDs
</c>
<c>
<xref target="det.pos"/>
</c>
<c>
end-to-end encryption
</c>
<c>
<xref target="call.sig.routing"/>
</c>
<c>
group authority
</c>
<c>
<xref target="adm.ctrl"/>
</c>
<c>
group charter
</c>
<c>
<xref target="adm.ctrl"/>
</c>
<c>
iterative routing
</c>
<c>
<xref target="mitm"/>
</c>
<c>
no profit for newcomers
</c>
<c>
<xref target="reput.mgmt"/>
</c>
<c>
online phone book
</c>
<c>
<xref target="bindings.integrity"/>
</c>
<c>
passive upgrades
</c>
<c>
<xref target="active.vs.passive"/>
</c>
<c>
peer promotion
</c>
<c>
<xref target="promotion"/>
</c>
<c>
proactive identification
</c>
<c>
<xref target="pro.identification"/>
</c>
<c>
reactive identification
</c>
<c>
<xref target="re.identification"/>
</c>
<c>
recommendation
</c>
<c>
<xref target="adm.ctrl"/>
</c>
<c>
reputation management systems
</c>
<c>
<xref target="reput.mgmt"/>
</c>
<c>
self-policing
</c>
<c>
<xref target="reput.mgmt"/>
</c>
<c>
signatures
</c>
<c>
<xref target="adm.ctrl"/>
</c>
<c>
social networks (using)
</c>
<c>
<xref target="routing.integrity"/>, <xref target="det.pos"/>
</c>
<c>
SRTP
</c>
<c>
<xref target="encrypt"/>
</c>
<c>
structured reputation management
</c>
<c>
<xref target="str.reput.mgmt"/>
</c>
<c>
SybilGuard (protocol)
</c>
<c>
<xref target="det.pos"/>
</c>
<c>
transitivity of trust
</c>
<c>
<xref target="str.reput.mgmt"/>
</c>
<c>
trust and distrust vectors
</c>
<c>
<xref target="unstr.reput.mgmt"/>
</c>
<c>
trust and trusted nodes
</c>
<c>
<xref target="adm.ctrl"/>,
<xref target="routing.integrity"/>,
<xref target="trust"/>
</c>
<c>
unstructured reputation management
</c>
<c>
<xref target="unstr.reput.mgmt"/>
</c>
<c>
voluntary moderators
</c>
<c>
<xref target="data.integrity"/>
</c>
<postamble>
Index of some of the more popular solutions discussed in
this document.
</postamble>
</texttable>
</section>
</section>
<section title="The attackers"
anchor="attackers">
<section title="Incentive of the attacker"
anchor="attack.incentives">
<t>
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 <xref
target="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 <xref
target="Sit"/>. However with replication of key-value pairs at
multiple locations, such threats can be mitigated.
</t>
<t>
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 <xref target="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.
</t>
<t>
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.
</t>
</section>
<section title="Resources available to the attacker"
anchor="attack.resources">
<t>
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 <xref target="Douceur">Sybil attack</xref>
described in <xref target="det.pos"/>, IP addresses are also
an important resource for the attacker since in DHTs such as
<xref target="Stoica">Chord</xref>, the position in the
overlay is determined by using a base hash function such as
<xref target="SHA1">SHA-1</xref> on the node's IP address. The
cryptographic puzzles <xref target="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 <xref
target="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.
</t>
</section>
<section title="Victim of the attack"
anchor="attack.victim">
<t>
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 <xref target="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.
</t>
</section>
<section title="Time of attack"
anchor="attack.time">
<t>
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 <xref
target="Maymounkov">Kademlia</xref>, 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.
</t>
</section>
</section>
<section title="Admission control"
anchor="adm.ctrl">
<t>
Admission control depends on who decides whether or not to admit
a node and how this permission is granted. <xref
target="Kim">Kim et al.</xref> 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.
</t>
<t>
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). 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. <xref target="Saxena">Saxena et al.</xref>
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
<xref target="Kong"/> and multisignature schemes <xref
target="Ohta"/>.
</t>
<t>
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 <xref
target="Ahn">CAPTCHA</xref>; however, reliability of such
mechanisms is at the time of writing a topic of lively debate
<xref target="Tam"/> <xref target="Chellapilla"/>.
</t>
</section>
<section title="Determining the position in the overlay"
anchor="det.pos">
<t>
For ring based DHT overlays such as <xref
target="Stoica">Chord</xref>, <xref
target="Maymounkov">Kademlia</xref> and <xref
target="Rowstron">Pastry</xref>, 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 <xref target="Douceur">Sybil attack</xref>. 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 <xref target="Condie"/> <xref target="Scheideler"/>. Such
temporal solutions, however have the drawback that they increase
the maintenance traffic and possibly deteriorate the efficiency
of caching. <xref target="Danezis">Danezis et al.</xref>
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 <xref
target="Rowaihy">Rowaihy et al.</xref>. 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.
</t>
<t>
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.
</t>
<t>
Another approach proposed by <xref target="Yu">Yu et
al.</xref>. 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 <xref
target="Yu">SybilGuard protocol</xref> 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.
</t>
<t>
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 <xref
target="Ratnasamy">content addressable network (CAN)</xref>, 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.
</t>
</section>
<section title="Resilience against malicious peers"
anchor="id.dis">
<t>
Making overlays robust against even a small percentage of
malicious nodes is difficult <xref target="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.
</t>
<section title="Identification of malicious peers"
anchor="identification">
<t>
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.
</t>
<section title="Proactive identification"
anchor="pro.identification">
<t>
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 <xref target="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.
</t>
<t>
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 <xref
target="Maymounkov">Kademlia</xref>, the sending peer can
identify anomalies comparing responses coming in from
different paths.
</t>
</section>
<section title="Reactive identification"
anchor="re.identification">
<t>
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. <xref target="Poon">Poon et al.</xref> 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.
</t>
</section>
</section>
<section title="Reputation management systems"
anchor="reput.mgmt">
<t>
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 <xref target="Uzun"/> <xref target="Damiani"/>
<xref target="Lee"/> <xref target="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, <xref target="Lee">Lee et al.</xref> 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. <xref target="Kamvar">Kamvar
et al.</xref> define five design considerations for reputation
management systems:
<list style="symbols">
<t>
The system should be self-policing.
</t>
<t>
The system should maintain anonymity.
</t>
<t>
The system should not assign any profit to newcomers.
</t>
<t>
The system should have minimal overhead in terms of
computation, infrastructure, storage, and message
complexity.
</t>
<t>
The system should be robust to malicious collectives of
peers who know one another and attempt to collectively
subvert the system.
</t>
</list>
</t>
<section title="Unstructured reputation management"
anchor="unstr.reput.mgmt">
<t>
Unstructured reputation management systems have been
proposed by <xref target="Uzun">Uzun et al.</xref> and <xref
target="Damiani">Damiani et al.</xref>. 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 <xref
target="Uzun">Uzun et al.</xref>, 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.
</t>
</section>
<section title="Structured reputation management"
anchor="str.reput.mgmt">
<t>
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 <xref
target="Lee"/> <xref target="Kamvar"/> try to resolve it in
a structured manner. The idea of the <xref
target="Kamvar">eigen trust algorithm</xref> 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 <xref
target="Ratnasamy">content addressable network (CAN)
DHT</xref>. 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.
</t>
</section>
</section>
</section>
<section title="Routing and data integrity"
anchor="p2p.integrity">
<t>
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 <xref
target="p2p.communication"/>.
</t>
<section title="Data integrity"
anchor="data.integrity">
<t>
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 <xref
target="Zhang"/>. An analysis of BitTorrent in terms of
integrity and performance can be found in the work of <xref
target="Pouwelse">Pouwelse et al.</xref>.
</t>
</section>
<section title="Routing integrity"
anchor="routing.integrity">
<t>
To enhance the integrity of routing, it is important to reduce
the number of queries forwarded to malicious nodes. <xref
target="Marti">Marti et al.</xref> 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 <xref
target="Stoica">Chord</xref> routing table to forward
queries. While their results indicate good average
performance, it can not guarantee log(N) hops for all cases.
<xref target="Danezis">Danezis et al.</xref> 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 <xref target="Rowstron">Pastry</xref>
and <xref target="Maymounkov">Kademlia</xref> 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.
</t>
</section>
</section>
<section title="Peer-to-peer in realtime communication"
anchor="p2p.communication">
<t>
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 <xref target="P2PSIP">P2PSIP
working group in IETF</xref> 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.
</t>
<t>
Even if based on the same technology, overlays used for realtime
communication differ from those used for file-sharing in at
least two aspects:
<list style="symbols">
<t>
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).
</t>
<t>
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.
</t>
</list>
</t>
<t>
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.
</t>
<section title="Peer promotion"
anchor="promotion">
<t>
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 <xref
target="RFC3261">SIP</xref>. Through the rest of this document
we will refer to nodes that access the service without
actually joining the overlay as "clients".
</t>
<t>
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.
</t>
<section title="Active vs. passive upgrades"
anchor="active.vs.passive">
<t>
Most existing P2P networks <xref target="KAZAA"/> <xref
target="BITTORRENT"/> <xref target="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 <xref target="SKYPE">Skype
network</xref>, 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 <xref target="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):
<list style="symbols">
<t>
An attacker cannot estimate in advance when and if it
would be invited to join the overlay as a peer.
</t>
<t>
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.
</t>
<t>
Discourages malicious peers from attempting Sybil and,
more generally, brute force attacks, as only a small
ratio of clients has chances to join the overlay
(possibly after an accurate examination).
</t>
</list>
</t>
</section>
<section title="When to upgrade"
anchor="when.to.upgrade">
<t>
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 <xref
target="I-D.ietf-p2psip-diagnostics"/>; in general,
reasonable criteria for determining load can be:
<list style="symbols">
<t>
Number of clients attached.
</t>
<t>
Bandwidth usage for DHT maintenance, forwarding requests
and responses to and from peers and from the attached
clients.
</t>
<t>
Memory usage for DHT routing table, DHT neighborhood
table, application specific data and information about
the attached clients.
</t>
</list>
</t>
</section>
<section title="Which clients to upgrade"
anchor="who.to.upgrade">
<t>
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:
<list style="symbols">
<t>
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.
</t>
<t>
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.
</t>
<t>
Keeping track of history. Peers could record history of
the clients they invite and the way they contribute to
the overlay.
</t>
</list>
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.
</t>
<t>
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.
</t>
</section>
<section title="Incentives for clients"
anchor="client.incentives">
<t>
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:
<list style="symbols">
<t>
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.
</t>
<t>
Peers could restrict the number or types of calls that
they allow clients to make.
</t>
</list>
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.
</t>
</section>
</section>
<section title="Security"
anchor="p2prtc.security">
<section title="Targeted denial of service"
anchor="dos">
<t>
In addition to bombardment with queries as described in
<xref target="attackers"/>, 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. <xref
target="Danezis">Danezis et al.'s solution</xref> can also
provide protection against such attacks as in their solution
peers vary the nodes used in queries.
</t>
</section>
<section title="Man in the middle attack"
anchor="mitm">
<t>
The man in the middle attack is well described by <xref
target="Seedorf1">Seedorf</xref> in the particular case of
<xref target="P2PSIP">P2PSIP</xref> 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" <xref
target="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 <xref target="Seedorf1"/>.
</t>
</section>
<section title="Trust between peers"
anchor="trust">
<t>
The effect of malicious peers could be mitigated by
introducing the concept of trust within an overlay. This can
be done in different ways:
<list style="symbols">
<t>
Using certificates assigned by an external authority.
The drawback with this approach is that it requires a
centralized element.
</t>
<t>
Using certificates reciprocally signed by peers. This
mechanism is quite similar to <xref
target="Zimmermann">PGP</xref>; 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.
</t>
</list>
</t>
</section>
<section title="Routing call signaling"
anchor="call.sig.routing">
<t>
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
<xref target="RFC3261">SIP</xref> 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
</t>
<t>
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.
</t>
<t>
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 <xref
target="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 <xref
target="RFC2818">HTTPS</xref>.
</t>
</section>
<section title="Integrity of location bindings"
anchor="bindings.integrity">
<t>
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 <xref
target="Seedorf2"/>. The idea is for an entity to choose an
asymmetric key pair and hash its public key to generate its
URI. The entity then signs its present location with its
private key and registers with the quadruple (URI, IP,
signature, public key). Any entity 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.
</t>
</section>
<section title="Encrypting content"
anchor="encrypt">
<t>
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.
</t>
<t>
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 <xref target="RFC3711">SRTP</xref>.
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.
</t>
</section>
<section title="Other issues"
anchor="other.issues">
<t>
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:
<list style="symbols">
<t>
To whom do the users pay?
</t>
<t>
Do the users only pay when accessing the public
telephone network?
</t>
<t>
Is the billing done per call or is it fixed?
</t>
</list>
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. <xref
target="Baumann">Baumann et al.</xref> 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.
</t>
</section>
</section>
</section>
<section title="Open Issues">
<t>
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 <xref target="Baset"/>, moderators and trackers in
BitTorrent <xref target="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:
<list style="symbols">
<t>
Secure assignment of node IDs.
</t>
<t>
Entity-identity association.
</t>
<t>
Distributed trust among peers.
</t>
<t>
Resistance against malicious peer collusion.
</t>
<t>
Robustness and damage recovery.
</t>
</list>
</t>
<t>
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.
</t>
</section>
<section title="Security Considerations">
<t>
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.
</t>
</section>
<section title="Acknowledgments">
<t>
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.
</t>
<t>
The authors would also like to thank Vijay Gurbani and Song
Haibin for reviewing the document and the many others who
provided useful comments.
</t>
</section>
</middle>
<back>
<references title="Informative references">
<reference anchor="RFC3261">
<front>
<title>
SIP: Session Initiation Protocol
</title>
<author initials="J." surname="Rosenberg"
fullname="J. Rosenberg">
<organization/>
</author>
<author initials="H." surname="Schulzrinne"
fullname="H. Schulzrinne">
<organization/>
</author>
<author initials="G." surname="Camarillo"
fullname="G. Camarillo">
<organization/>
</author>
<author initials="A." surname="Johnston"
fullname="A. Johnston">
<organization/>
</author>
<author initials="J." surname="Peterson"
fullname="J. Peterson">
<organization/>
</author>
<author initials="R." surname="Sparks"
fullname="R. Sparks">
<organization/>
</author>
<author initials="M." surname="Handley"
fullname="M. Handley">
<organization/>
</author>
<author initials="E." surname="Schooler"
fullname="E. Schooler">
<organization/>
</author>
<date year="2002" month="June"/>
</front>
<seriesInfo name="RFC" value="3261"/>
<format type="TXT" octets="647976"
target="ftp://ftp.isi.edu/in-notes/rfc3261.txt"/>
</reference>
<reference anchor="RFC3711">
<front>
<title>
The Secure Real-time Transport Protocol (SRTP)
</title>
<author initials="M." surname="Baugher"
fullname="M. Baugher">
<organization/>
</author>
<author initials="D." surname="McGrew"
fullname="D. McGrew">
<organization/>
</author>
<author initials="M." surname="Naslund"
fullname="M. Naslund">
<organization/>
</author>
<author initials="E." surname="Carrara"
fullname="E. Carrara">
<organization/>
</author>
<author initials="K." surname="Norrman"
fullname="K. Norrman">
<organization/>
</author>
<date year="2004" month="March"/>
</front>
<seriesInfo name="RFC" value="3711"/>
<format type="TXT" octets="134270"
target="ftp://ftp.isi.edu/in-notes/rfc3711.txt"/>
</reference>
<reference anchor="RFC2818">
<front>
<title>
HTTP Over TLS
</title>
<author initials="E." surname="Rescorla"
fullname="E. Rescorla">
<organization/>
</author>
<date year="2000" month="May"/>
</front>
<seriesInfo name="RFC" value="2818"/>
<format type="TXT" octets="15170"
target="ftp://ftp.isi.edu/in-notes/rfc2818.txt"/>
</reference>
<reference anchor="RFC4981">
<front>
<title>
Survey of Research towards Robust Peer-to-Peer Networks:
Search Methods
</title>
<author initials="J." surname="Risson" fullname="J. Risson">
<organization/>
</author>
<author initials="T." surname="Moors" fullname="T. Moors">
<organization/>
</author>
<date year="2007" month="September"/>
</front>
<seriesInfo name="RFC" value="4981"/>
<format type="TXT" octets="239752"
target="ftp://ftp.isi.edu/in-notes/rfc4981.txt"/>
</reference>
<reference anchor="I-D.ietf-p2psip-diagnostics">
<front>
<title>Diagnose P2PSIP Overlay Network</title>
<author initials="S" surname="Yongchao"
fullname="Song Yongchao">
<organization/>
</author>
<author initials="X" surname="Jiang"
fullname="XingFeng Jiang">
<organization/>
</author>
<date month="January" day="22" year="2009"/>
</front>
<seriesInfo name="Internet-Draft"
value="draft-ietf-p2psip-diagnostics-00"/>
<format type="TXT"
target="http://www.ietf.org/internet-drafts/draft-ietf-p2psip-diagnostics-00.txt"/>
</reference>
<reference anchor="Gurbani">
<front>
<title>
Cryptographically Transparent Session Initiation Protocol
(SIP) Proxies
</title>
<author initials="V" surname="Gurbani">
<organization/>
</author>
<author initials="D" surname="Willis">
<organization/>
</author>
<author initials="F" surname="Audet">
<organization/>
</author>
<date month="June" day="14" year="2007"/>
</front>
<seriesInfo name="Proceedings of" value="IEEE ICC '07"/>
</reference>
<reference anchor="P2PSIP" target="http://ietf.org/html.charters/p2psip-charter.html">
<front>
<title>Peer-to-Peer Session Initiation Protocol (P2PSIP) IETF Working Group</title>
<author initials="" surname="">
<organization/>
</author>
</front>
</reference>
<reference anchor="NAPSTER" target="http://www.napster.com/">
<front>
<title>Napster</title>
<author initials="" surname="">
<organization/>
</author>
</front>
</reference>
<reference anchor="KAZAA" target="http://www.kazaa.com/">
<front>
<title>KaZaa</title>
<author initials="" surname="">
<organization/>
</author>
</front>
</reference>
<reference anchor="SKYPE" target="http://www.skype.com/">
<front>
<title>Skype</title>
<author initials="" surname="">
<organization/>
</author>
</front>
</reference>
<reference anchor="COOLSTREAM" target="http://www.coolstreaming.us">
<front>
<title>COOLSTREAMING</title>
<author initials="" surname="">
<organization/>
</author>
</front>
</reference>
<reference anchor="PPLIVE" target="http://www.pplive.com">
<front>
<title>PPLive</title>
<author initials="" surname="">
<organization/>
</author>
</front>
</reference>
<reference anchor="BITTORRENT" target="http://www.bittorrent.com/">
<front>
<title>BitTorrent</title>
<author initials="" surname="">
<organization/>
</author>
</front>
</reference>
<reference anchor="Ahn">
<front>
<title>Telling humans and computers apart automatically</title>
<author initials="L." surname="Ahn">
<organization/>
</author>
<author initials="M." surname="Blum">
<organization/>
</author>
<author initials="J." surname="Langford">
<organization/>
</author>
<date month="February" year="2004"/>
</front>
<seriesInfo name="Communications of the ACM" value="vol. 47, no. 2"/>
</reference>
<reference anchor="Tam">
<front>
<title>
Breaking Audio CAPTCHAs with Machine Learning Techniques
</title>
<author initials="J." surname="Tam">
<organization/>
</author>
<author initials="J." surname="Simsa">
<organization/>
</author>
<author initials="S." surname="Hyde">
<organization/>
</author>
<author initials="L." surname="Ahn">
<organization/>
</author>
<date month="December" year="2009"/>
</front>
<seriesInfo name="Proceedings of"
value="Advances in Neural Information Processing Systems"/>
</reference>
<reference anchor="Chellapilla">
<front>
<title>
Using Machine Learning to Break Visual Human Interaction
Proofs (HIPs)
</title>
<author initials="K." surname="Chellapilla">
<organization/>
</author>
<author initials="P." surname="Simard">
<organization/>
</author>
<date month="December" year="2004"/>
</front>
<seriesInfo name="Proceedings of"
value="Advances in Neural Information Processing Systems"/>
</reference>
<reference anchor="Androutsellis-Theotokis">
<front>
<title>A survey of peer-to-peer content distribution technologies</title>
<author initials="S" surname="Androutsellis-Theotokis">
<organization/>
</author>
<author initials="D" surname="Spinellis">
<organization/>
</author>
<date month="December" year="2004"/>
</front>
<seriesInfo name="ACM CSUR" value="vol. 36, no. 4"/>
</reference>
<reference anchor="Wallach" target="http://www.cs.rice.edu/~dwallach/pub/tokyo-p2p2002.pdf">
<front>
<title>A Survey of Peer-to-Peer Security Issues</title>
<author initials="D" surname="Wallach">
<organization/>
</author>
<date month="November" year="2002"/>
</front>
<seriesInfo name="Proceedings of"
value="International Symposium of Software Security 2002"/>
</reference>
<reference anchor="Zhang">
<front>
<title>Enhancing Data Authenticity and Integrity in P2P Systems</title>
<author initials="X" surname="Zhang">
<organization/>
</author>
<author initials="S" surname="Chen">
<organization/>
</author>
<author initials="R" surname="Sandhu">
<organization/>
</author>
<date month="September" year="2005"/>
</front>
<seriesInfo name="IEEE Internet Computing"
value="vol. 9, no. 6"/>
</reference>
<reference anchor="Pouwelse">
<front>
<title>The Bittorent P2P File-Sharing System: Measurements and Analysis</title>
<author initials="J" surname="Pouwelse">
<organization/>
</author>
<author initials="P" surname="Garbacki">
<organization/>
</author>
<author initials="D" surname="Epema">
<organization/>
</author>
<author initials="H" surname="Sips">
<organization/>
</author>
<date month="February" year="2005"/>
</front>
<seriesInfo name="Proceedings of"
value="4th International Workshop of Peer-to-peer Systems"/>
</reference>
<reference anchor="Singh">
<front>
<title>Peer-to-Peer Internet Telephony using SIP</title>
<author initials="K" surname="Singh">
<organization/>
</author>
<author initials="H" surname="Schulzrinne">
<organization/>
</author>
<date month="June" year="2005"/>
</front>
<seriesInfo name="Proceedings of"
value="International Workshop on Network and Operating System Support for Digital Audio and Video"/>
</reference>
<reference anchor="Seedorf1">
<front>
<title>Security Challenges for Peer-to-Peer SIP</title>
<author initials="J" surname="Seedorf">
<organization/>
</author>
<date month="September" year="2006"/>
</front>
<seriesInfo name="IEEE Network"
value="vol. 20, no. 5"/>
</reference>
<reference anchor="Stoica">
<front>
<title>Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications</title>
<author initials="I" surname="Stoica">
<organization/>
</author>
<author initials="R" surname="Morris">
<organization/>
</author>
<author initials="D" surname="Karger">
<organization/>
</author>
<author initials="M" surname="Kaashoek">
<organization/>
</author>
<author initials="H" surname="Balakrishnan">
<organization/>
</author>
<date month="May" year="2001"/>
</front>
<seriesInfo name="Proceedings of"
value="Applications, Technologies, Architectures, and Protocols for Computer Communication 2001"/>
</reference>
<reference anchor="Sit">
<front>
<title>Security considerations for peer-to-peer distributed hash tables</title>
<author initials="E" surname="Sit">
<organization/>
</author>
<author initials="R" surname="Morris">
<organization/>
</author>
<date month="March" year="2002"/>
</front>
<seriesInfo name="Revised Papers from"
value="First International Workshop on Peer-to-Peer Systems"/>
</reference>
<reference anchor="Baset">
<front>
<title>An analysis of the skype peer-to-peer internet telephony protocol</title>
<author initials="S" surname="Baset">
<organization/>
</author>
<author initials="H" surname="Schulzrinne">
<organization/>
</author>
<date month="April" year="2006"/>
</front>
<seriesInfo name="Proceedings of"
value="IEEE INFOCOM 2006"/>
</reference>
<reference anchor="Poon">
<front>
<title>Robust Forwarding in Structured Peer-to-Peer Overlay Networks</title>
<author initials="W" surname="Poon">
<organization/>
</author>
<author initials="R" surname="Chang">
<organization/>
</author>
<date month="August" year="2004"/>
</front>
<seriesInfo name="Proceedings of"
value="ACM SIGCOMM 2004"/>
</reference>
<reference anchor="Uzun">
<front>
<title>A Reputation-Based Trust Management System for P2P Networks</title>
<author initials="E" surname="Uzun">
<organization/>
</author>
<author initials="M" surname="Pariente">
<organization/>
</author>
<author initials="A" surname="Selpk">
<organization/>
</author>
<date month="April" year="2004"/>
</front>
<seriesInfo name="Proceedings of"
value="International Symposium on Cluster Computing and the Grids"/>
</reference>
<reference anchor="Kim">
<front>
<title>Admission Control in Peer Groups</title>
<author initials="Y" surname="Kim">
<organization/>
</author>
<author initials="D" surname="Mazzocchi">
<organization/>
</author>
<author initials="G" surname="Tsudik">
<organization/>
</author>
<date month="April" year="2003"/>
</front>
<seriesInfo name="Proceedings of"
value="Second IEEE International Symposium on Network Computing and Applications"/>
</reference>
<reference anchor="Maymounkov">
<front>
<title>Kademlia: A Peer-to-peer Information System Based on the XOR Metric</title>
<author initials="P" surname="Maymounkov">
<organization/>
</author>
<author initials="D" surname="Mazi">
<organization/>
</author>
<date month="March" year="2002"/>
</front>
<seriesInfo name="Proceedings of"
value="First International Workshop on Peer-to-peer Systems"/>
</reference>
<reference anchor="Rowstron">
<front>
<title>Pastry: Scalable, distributed object location and routing for large-scale peer-to-peer systems</title>
<author initials="A" surname="Rowstron">
<organization/>
</author>
<author initials="P" surname="Druschel">
<organization/>
</author>
<date month="November" year="2001"/>
</front>
<seriesInfo name="Proceedings of"
value="18th IFIP/ACM International Conference on Distributed Systems Platforms (Middleware 2001)"/>
</reference>
<reference anchor="Ratnasamy">
<front>
<title>A Scalable Content-Addressable Network</title>
<author initials="S" surname="Ratnasamy">
<organization/>
</author>
<author initials="P" surname="Francis">
<organization/>
</author>
<author initials="M" surname="Handley">
<organization/>
</author>
<author initials="R" surname="Karp">
<organization/>
</author>
<author initials="S" surname="Shenker">
<organization/>
</author>
<date month="January" year="2001"/>
</front>
<seriesInfo name="Proceedings of"
value="ACM SIGCOMM 2001"/>
</reference>
<reference anchor="Saxena">
<front>
<title>Admission Control in Peer-to-Peer: Design and Performance Evaluation</title>
<author initials="N" surname="Saxena">
<organization/>
</author>
<author initials="G" surname="Tsudik">
<organization/>
</author>
<author initials="J" surname="Yi">
<organization/>
</author>
<date month="October" year="2003"/>
</front>
<seriesInfo name="Proceedings of"
value="1st ACM workshop on Security of ad hoc and sensor networks"/>
</reference>
<reference anchor="Condie">
<front>
<title>Maelstorm: Churn as Shelter</title>
<author initials="T" surname="Condie">
<organization/>
</author>
<author initials="V" surname="Kacholia">
<organization/>
</author>
<author initials="S" surname="Sankararaman">
<organization/>
</author>
<author initials="J" surname="Hellerstein">
<organization/>
</author>
<author initials="P" surname="Maniatis">
<organization/>
</author>
<date month="November" year="2005"/>
</front>
<seriesInfo name="Proceedings of"
value="13th Annual Network and Distributed System Security Symposium"/>
</reference>
<reference anchor="Danezis">
<front>
<title>Sybil-resistant DHT routing</title>
<author initials="G" surname="Danezis">
<organization/>
</author>
<author initials="C" surname="Lesniewski-Laas">
<organization/>
</author>
<author initials="M" surname="Kaashoek">
<organization/>
</author>
<author initials="R" surname="Anderson">
<organization/>
</author>
<date month="September" year="2005"/>
</front>
<seriesInfo name="Proceedings of"
value="10th European Symposium on Research in Computer Security"/>
</reference>
<reference anchor="Marti">
<front>
<title>SPROUT: P2P Routing with Social Networks</title>
<author initials="S" surname="Marti">
<organization/>
</author>
<author initials="P" surname="Ganesan">
<organization/>
</author>
<author initials="H" surname="Garcia-Molina">
<organization/>
</author>
<date month="March" year="2004"/>
</front>
<seriesInfo name="Proceedings of"
value="First International Workshop on Peer-to-Peer and Databases"/>
</reference>
<reference anchor="Scheideler">
<front>
<title>How to Spread Adversarial Nodes?: Rotate!</title>
<author initials="C" surname="Scheideler">
<organization/>
</author>
<date month="May" year="2005"/>
</front>
<seriesInfo name="Proceedings of"
value="37th Annual ACM Symposium on Theory of Computing"/>
</reference>
<reference anchor="Rowaihy">
<front>
<title>Limiting Sybil attacks in structured peer-to-peer networks</title>
<author initials="H" surname="Rowaihy">
<organization/>
</author>
<author initials="W" surname="Enck">
<organization/>
</author>
<author initials="P" surname="McDaniel">
<organization/>
</author>
<author initials="T" surname="Porta">
<organization/>
</author>
<date month="May" year="2007"/>
</front>
<seriesInfo name="Proceedings of"
value="IEEE INFOCOM 2007"/>
</reference>
<reference anchor="Douceur">
<front>
<title>The Sybil Attack</title>
<author initials="J" surname="Douceur">
<organization/>
</author>
<date month="March" year="2002"/>
</front>
<seriesInfo name="Revised Papers from"
value="First International Workshop on Peer-to-Peer Systems"/>
</reference>
<reference anchor="Yu">
<front>
<title>SybilGuard: Defending Against Sybil Attacks via Social Networks</title>
<author initials="H" surname="Yu">
<organization/>
</author>
<author initials="M" surname="Kaminsky">
<organization/>
</author>
<author initials="P" surname="Gibbons">
<organization/>
</author>
<author initials="A" surname="Flaxman">
<organization/>
</author>
<date month="September" year="2006"/>
</front>
<seriesInfo name="Proceedings of"
value="ACM SIGCOMM 2006"/>
</reference>
<reference anchor="Liang">
<front>
<title>Pollution in p2p file sharing systems</title>
<author initials="J" surname="Liang">
<organization/>
</author>
<author initials="R" surname="Kumar">
<organization/>
</author>
<author initials="Y" surname="Xi">
<organization/>
</author>
<author initials="K" surname="Ross">
<organization/>
</author>
<date month="March" year="2005"/>
</front>
<seriesInfo name="Proceedings of"
value="IEEE INFOCOM 2005"/>
</reference>
<reference anchor="Kong">
<front>
<title>Providing robust and ubiquitous security support for MANET</title>
<author initials="J" surname="Kong">
<organization/>
</author>
<author initials="P" surname="Zerfos">
<organization/>
</author>
<author initials="H" surname="Luo">
<organization/>
</author>
<author initials="S" surname="Lu">
<organization/>
</author>
<author initials="L" surname="Zhang">
<organization/>
</author>
<date month="November" year="2001"/>
</front>
<seriesInfo name="Proceedings of"
value="9th International Conference on Network Protocols"/>
</reference>
<reference anchor="Ohta">
<front>
<title>Accountable Subgroup Multisignatures</title>
<author initials="K" surname="Ohta">
<organization/>
</author>
<author initials="S" surname="Micali">
<organization/>
</author>
<author initials="L" surname="Reyzin">
<organization/>
</author>
<date month="November" year="2001"/>
</front>
<seriesInfo name="Proceedings of"
value="8th ACM conference on Computer and Communications Security"/>
</reference>
<reference anchor="Lee">
<front>
<title>A Reputation Management System in Structured Peer-to-Peer Networks</title>
<author initials="S" surname="Lee">
<organization/>
</author>
<author initials="O" surname="Kwon">
<organization/>
</author>
<author initials="J" surname="Kim">
<organization/>
</author>
<author initials="S" surname="Hong">
<organization/>
</author>
<date month="June" year="2005"/>
</front>
<seriesInfo name="Proceedings of"
value="14th IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprise"/>
</reference>
<reference anchor="Seedorf2">
<front>
<title>Using Cryptographically Generated SIP-URIs to Protect the Integrity of Content in P2P-SIP</title>
<author initials="J" surname="Seedorf">
<organization/>
</author>
<date month="June" year="2006"/>
</front>
<seriesInfo name="Proceedings of"
value="3rd Annual VoIP Security Workshop"/>
</reference>
<reference anchor="Castro">
<front>
<title>Secure routing for structured peer-to-peer overlay networks</title>
<author initials="M" surname="Castro">
<organization/>
</author>
<author initials="P" surname="Druschel">
<organization/>
</author>
<author initials="A" surname="Ganesh">
<organization/>
</author>
<author initials="A" surname="Rowstron">
<organization/>
</author>
<author initials="D" surname="Wallach">
<organization/>
</author>
<date month="December" year="2002"/>
</front>
<seriesInfo name="Proceedings of"
value="5th symposium on Operating systems design and implementation"/>
</reference>
<reference anchor="SHA1">
<front>
<title>Secure Hash Standard</title>
<author initials="FIPS" surname="180-1">
<organization/>
</author>
<date month="April" year="2005"/>
</front>
</reference>
<reference anchor="Damiani">
<front>
<title>A Reputation-Based Approach for Choosing Reliable Resources in Peer-to-Peer Networks</title>
<author initials="E" surname="Damiani">
<organization/>
</author>
<author initials="D" surname="Vimercati">
<organization/>
</author>
<author initials="S" surname="Paraboschi">
<organization/>
</author>
<author initials="P" surname="Samarati">
<organization/>
</author>
<author initials="F" surname="Violante">
<organization/>
</author>
<date month="November" year="2002"/>
</front>
<seriesInfo name="Proceedings of"
value="Conference on Computer and Communications Security"/>
</reference>
<reference anchor="Kamvar">
<front>
<title>The EigenTrust Algorithm for Reputation Management in P2P Networks</title>
<author initials="S" surname="Kamvar">
<organization/>
</author>
<author initials="H" surname="Garcia-Molina">
<organization/>
</author>
<author initials="M" surname="Schlosser">
<organization/>
</author>
<date month="May" year="2003"/>
</front>
<seriesInfo name="Proceedings of"
value="12th international conference on World Wide Web"/>
</reference>
<reference anchor="Baumann">
<front>
<title>Voice Over IP - Security and SPIT</title>
<author initials="R" surname="Baumann">
<organization/>
</author>
<author initials="S" surname="Cavin">
<organization/>
</author>
<author initials="S" surname="Schmid">
<organization/>
</author>
<date month="September" year="2006"/>
</front>
<seriesInfo name="Technical Report,"
value="University of Berne"/>
</reference>
<reference anchor="McCue" target="http://software.silicon.com/security/0,39024655,39121278,00.htm">
<front>
<title>Bookie reveals 100,000 cost of denial-of-service extortion attacks</title>
<author initials="Andy" surname="McCue">
<organization/>
</author>
<date month="June" year="2004"/>
</front>
</reference>
<reference anchor="Zimmermann">
<front>
<title>Pretty good privacy: public key encryption for the masses</title>
<author initials="Philip" surname="Zimmermann">
<organization/>
</author>
<date year="1995"/>
</front>
<seriesInfo name="Building in big brother: the cryptographic policy debate"
value="pag. 103-107"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 15:29:24 |