One document matched: draft-matuszewski-p2psip-security-requirements-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[
<!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3261 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY I-D.ietf-p2psip-sip SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-p2psip-sip.xml">
<!ENTITY I-D.ietf-p2psip-base SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-p2psip-base.xml">
<!ENTITY I-D.song-p2psip-security-eval SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.song-p2psip-security-eval.xml">
<!ENTITY I-D.bryan-p2psip-app-scenarios SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bryan-p2psip-app-scenarios.xml">
<!ENTITY I-D.bryan-p2psip-requirements SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bryan-p2psip-requirements.xml">
<!ENTITY I-D.zheng-p2psip-diagnose SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.zheng-p2psip-diagnose.xml">
]>
<rfc category="info"
docName="draft-matuszewski-p2psip-security-requirements-04"
ipr="full3978">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="Security requirements in P2PSIP">Security requirements in
Peer-to-Peer Session Initiation Protocol (P2PSIP)</title>
<author fullname="Song Haibin" initials="H." surname="Song">
<organization>Huawei</organization>
<address>
<postal>
<street>Baixia Road No. 91</street>
<city>Nanjing</city>
<region>Jiangsu Province</region>
<code>210001</code>
<country>P.R.China</country>
</postal>
<phone>+86-25-84565081</phone>
<facsimile>+86-25-84565070</facsimile>
<email>melodysong@huawei.com</email>
</address>
</author>
<author fullname="Marcin Matuszewski" initials="M." surname="Matuszewski">
<organization>Nokia</organization>
<address>
<postal>
<street>P.O.Box 407</street>
<city>NOKIA GROUP</city>
<region>FIN</region>
<code>00045</code>
<country>Finland</country>
</postal>
<email>marcin.matuszewski@nokia.com</email>
</address>
</author>
<author fullname="Dan York" initials="D." surname="York">
<organization abbrev="Voxeo">Voxeo Corporation</organization>
<address>
<postal>
<street></street>
<city>Keene</city>
<region>NH</region>
<code></code>
<country>USA</country>
</postal>
<phone>+1-407-455-5859</phone>
<email>dyork@voxeo.com</email>
<uri>http://www.voxeo.com/</uri>
</address>
</author>
<date year="2008" />
<area>Real-time Applications and Infrastructure</area>
<workgroup>P2PSIP Working Group</workgroup>
<keyword>Security</keyword>
<keyword>P2PSIP</keyword>
<abstract>
<t>This document outlines the security requirements for a
Peer-to-Peer Session Initiation Protocol (P2PSIP) overlay network. It
compares security difference between client/server (C/S) and P2P
implementations of SIP, partitions the P2PSIP architecture into
layers and analyzes the security issues in each
layer and the security relationship among the layers. This draft also
describes the different security requirements related to different
application scenarios as well as a minimal set of security requirements
valid for all applications. It also discusses open issues related to
certain security threats for the P2PSIP architecture and its components.</t>
</abstract>
</front>
<middle>
<section title="Authors' Notes">
<t>This document represents a merge of two drafts:<list
style="symbols">
<t>draft-matuszewski-p2psip-security-requirements</t>
<t><xref target="I-D.song-p2psip-security-eval"/></t>
</list>with some post-merge editing by Song Haiban, Dan York and Marcin
Matuszewski. It is submitted to continue the ongoing
dialogue within the P2PSIP Working Group around security with the
recognition that further work needs to be done to complete the merger
of the two documents. The authors intend to do the following:<list
style="symbols">
<t>The document will be synchronized with the recently released
updates to the RELOAD protocol as documented by editor Bruce
Lowekamp in <xref target="I-D.ietf-p2psip-sip"/> and <xref
target="I-D.ietf-p2psip-base"/> </t>
<t>The merge between the two previous documents will be completed
so that the text flows better.</t>
<t>A section will be added on security
requirements related to interconnection of P2PSIP networks to
other networks including non-P2P SIP networks and the PSTN.</t>
</list> </t>
</section>
<section title="Introduction">
<t>The scope of this document is to analyze security threats concerning
a P2PSIP overlay architecture as described in the concepts and
terminology for P2PSIP document <xref target="1"/> and list security
requirements for the architecture and its components. It
compares security difference between client/server (C/S) and P2P
implementations of SIP, partitions the P2PSIP architecture into
layers and analyzes the security issues in each
layer and the security relationship among the layers. This draft also
classifies the application scenarios into two main types and then
analyzes in detail the security threats with these two types of
scenarios. In the end, it summarizes the main security requirements
for the P2PSIP architecture and its components. An appendix presents
an introduction to security threats to P2PSIP environments. </t>
<t>This document is intended to list the security requirements that must
be addressed in P2PSIP specifications. Some solutions to certain
attacks are given as an example in the analysis text. This document is a merge of
features from the security requirement draft version and the <xref
target="I-D.song-p2psip-security-eval">security
analysis and evaluation draft</xref>. It complements the <xref
target="I-D.bryan-p2psip-requirements">P2PSIP Protocol
Framework and Requirements document</xref>.</t>
</section>
<section title="Definitions">
<t>This section defines a number of concepts that are key to understand
the rest of the document.</t>
<section title="General">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 <xref
target="RFC2119"/>.</t>
</section>
<section title="P2PSIP network entity">
<t>A P2PSIP network entity is a peer, client, or other functional node
that may become a part of a P2PSIP overlay.</t>
</section>
<section title="P2PSIP system">
<t>A P2PSIP system consists of the P2PSIP overlay as defined in
<xref target="1"/>
and one or more enrollment servers. The enrollment servers issue unique
identities and credentials that are used to authenticate and admit
P2PSIP network entities to the overlay and allow a user to use
services provided by the P2PSIP overlay. The enrollment server may also
provide an initial set of bootstrap nodes.</t>
</section>
<section title="P2P Overlay Base">
<t><figure>
<preamble></preamble>
<artwork><![CDATA[P2P Overlay Base: A P2P Overlay Base includes all the Peers that
participate in the p2p overlay. The P2P Overlay Base provides
distributed storage and routing services to both peers and
clients.
Trusted P2P Overlay Base: All peers in a Trusted P2P Overlay Base are
trusted. The Peers in the overlay are all of good behaviors and
under control due to deployment. For example, a carrier deploys
a Trusted P2P Overlay Base to provide service to his customers,
and all the peers are the carrier's devices.
Untrusted P2P Overlay Base: Peers in a Untrusted P2P Overlay Base
are not all trusted. There may exist some malicious behaving
nodes in the P2P Overlay Base.
]]></artwork>
<postamble></postamble>
</figure></t>
</section>
</section>
<section title="Security Comparison between C/S and P2P">
<t>In a Client Server(C/S) architecture, a client asks for a specific
service only from a specific server. The destination contact
address(i.e. the address of that server) can be acquired from the
trusted DNS system directly. Given this, the security issues exist
only with the connection between the client and the server.
Typically, making the connection secure between the client and
the server addresses most of the security issues related to the
client.</t>
<t>However, in a P2P architecture the security issues are more
complex.</t>
<t>First, where in a C/S architecture specific servers provide
certain services, in a P2P architecture, each peer in the P2P overlay
can provide distributed storage and transport services for other P2P
entities. There is also no hierarchy of servers but instead the peers
self-organize into the P2P overlay.
</t>
<t>Second, where in a C/S architecture a client sends its request
directly to a server, in a P2P architecture a peer sends messages
through Key-Based-Routing and it doesn't know where the destination is.
There exist intermediate nodes between the source and destination.</t>
<t>Third, where in a C/S architecture the client can trust the
information from the server, in a P2P architecture, one peer does not
know whether it should trust the information acquired from the overlay.</t>
<t>So in a P2P architecture, security issues not only exist between
end to end entities, but also between hop by hop services. They are not only
related to the routing security, but also related to the content
security.</t>
<figure>
<preamble></preamble>
<artwork align="center"><![CDATA[
+------------+----------------------+--------------------------+
| | | |
| | C/S | P2P |
+------------+----------------------+--------------------------+
| | | |
| transport | authenticate between | authentication between |
| | client and server | P2PSIP network entities |
| | | |
+------------+----------------------+--------------------------+
| |need one hop security;| need hop by hop security|
| routing |transport layer | to ensure the end to end|
| |security can ensure it| security |
+------------+----------------------+--------------------------+
| | | responsible peer may not |
| storage | server is trusted for| trusted, need for resource|
| | storage | data management security |
+------------+----------------------+--------------------------+
| | | |
| application| out of scope of this| out of scope of this |
| | specification | specification |
| | | |
+------------+----------------------+--------------------------+
Figure 1 Comparision between C/S and P2P security]]></artwork>
<postamble></postamble>
</figure>
</section>
<section title="Security Analysis with P2P Layers">
<t>The overall security of a P2PSIP system depends upon the security
of each layer of the P2PSIP architecture. In this section we split the P2PSIP architecture
into four main layers, as shown in the following figure, and analyze the
security issues from the P2PSIP architecture perspective.</t>
<figure>
<preamble></preamble>
<artwork align="center"><![CDATA[
+----------+
| | Application Layer
| | --------------------------------------
| | +------+ +-------------+ +-------------+
| | | | | Distributed | | Replication |
| | | | | Storage | | |
| | | | +-------------+ +-------------+
| | | |--------------------------------------
|Enrollment| |P2P | +-------------+
|Server | |Layers| | Routing |
| | | | | Maintenance | +-----------+
| | | | +-------------+ | NAT&FW |
| | | | +-------------+ | Traversal |
| | | | | Key Based | +-----------+
| | | | | Routing(KBR)|
| | +------+ +-------------+
| | --------------------------------------
| | Transport Layer Security(TLS,DTLS)
+----------+
Figure 2 P2PSIP architecture]]></artwork>
<postamble></postamble>
</figure>
<t>The four main layers are:</t>
<t>Transport Layer: Provides transport service for the upper layers.</t>
<t>Routing Maintenance and KBR Layer: Maintains the routing table, and
do the Key Based Routing(KBR). NAT and Firewall traversal may be
involved to establish direct connections.</t>
<t>Distributed Storage and Replication Layer: Stores and Manages the
resource objects. Each peer's responsible resource objects are
determined by the specific P2P algorithm. Replication may be utilized to
ensure the availability of resource objects under churn.</t>
<t>Application Layer: Provides the user application, and invokes the
services provided by the Distributed Storage and Replication Layer.</t>
<t>The security measures adopted in the lower layer may impact the upper
layer security choices. Not every security threat needs to be
considered in each layer and typically each security threat only
needs to be solved in one of the layers. The question of in which
layer a specific security threat should be solved is addressed in our
primary analysis of each layer in the following sub-sections.</t>
<section title="Transport Layer Security">
<t>Given that a P2PSIP overlay can run on top of the Internet or
other untrusted network, messages between associated nodes should be
protected against attacks(such as Man-in-the-Middle). In order to
establish the identity trust association, nodes SHOULD authenticate
each other with e.g. TLS and DTLS. If transport service security is
provided, we can prevent nodes without valid identities to
participate in the overlay. This layer must provides reliable and
secure hop-by-hop transport service for the P2P overlay. This
alone, though, is not enough to secure the P2P system.</t>
</section>
<section title="Routing Maintenance and KBR layer Security">
<t>Each Peer in the P2PSIP overlay provides key-based routing service
to other peers and a routing maintenance mechanism is used to keep
the routing table timely and correct for the routing service. There
are some security threats with the routing table updating interaction
and the key-based routing.</t>
<t>Even if all the nodes participating in the P2PSIP overlay have
valid identities, the overlay may still be attacked by responding with
fake routing table to UPDATE requests. If the routing table is false,
the routing determination based on it will be false too. So,
verification mechanisms SHOULD be adopted to verify if the routing
table one learned from another is correct or not. A correct routing
table is important for hop by hop security.</t>
<t>Second, some attacker who is not responsible for the destination
ID may respond to some requests when he is in the intermediate routing
path(May respond with a fabricated resource object or just says that
the searched resource object doesn't exist). Should the source node
verify whether the response peer is responsible for the request? When
and how does the source peer do that? Whether the response peer is
responsible for the request is important for the end to end
security.</t>
<t>Third, some attackers may discard the messages when forwarding, or
on purpose forward the message to a wrong next hop. Should the overlay
need a method to detect the misbehaving forwardings?</t>
<t>Chosen-ID attack makes the above security issues much more
worse.</t>
<t>Fourth, some attacks may cause the overlay under high churn rate.
For example, some peers may frequently join and leave the overlay.
Overlay wastes much more traffic to update the routing table, and
transfer relative resource objects under churn. It can also make the
routing messages fail.</t>
<t><list>
<t>In this case, we need a method to control nodes to join the
overlay. The join control entity, which may be a bootstrap server
or enrollment server, or a bootstrap peer, makes records of peers'
historical behaviors in the overlay and their historical join
requests. When it receives the join request from a peer to join
the overlay, it checks the historical records as mentioned above
to determine whether this peer is permitted to join at this point.
It will deny the node to join the overlay when it determines the
peer is not permitted to join. For example, if a peer joins and
leaves too frequently, it will be denied to join the overlay as a peer for a
period of time and instead it will be allowed to join the overlay as a client.</t>
</list></t>
<t>The first and fourth issue above is about routing maintenance
function security, and the remain two issues are about the KBR
function security.</t>
</section>
<section title="Distributed Storage and Replication Layer Security">
<t>Distributed storage and replication layer provides distributed
storage service for the resource objects that located in one's
responsible resource ID range, and the replication service to keep the
availability of resource objects under churn. The security issues in
this layer are typically end to end, and about the content and
authority security.</t>
<t>First, We need to protect resource objects when needed against
unauthorized data operation such as obtainment, modification or
removing. A solution for authorization is needed.</t>
<t>Second, The P2PSIP overlay needs a method to prevent attackers from
publishing malicious information that will cause a DDOS attack. For
example, Peer A may publish a very popular resource record with the
contact address of Peer B without B's permission. That causes
unexpected lots of connections to B which will make Peer B down. Using
certificate can't solve this problem, a check mechanism for the
resource object is needed.</t>
<t>Third, overlays work well for a reasonable amount of resource
objects, but crash more or less when inserting millions of resource
objects per node. Spam attacks can make overlays go down. Open issue:
Should the spam attack be considered in the distributed storage layer?
Or is it only the responsibility of the application layer to handle
this problem?</t>
<t>Replication security is to TODO.</t>
</section>
<section title="Application Layer Security">
<t>Application layer security requirements are out of scope of this
specification.</t>
</section>
</section>
<section title="Security Analysis with Application Scenarios">
<t>As described in the security considerations section in <xref
target="I-D.bryan-p2psip-app-scenarios">the application
scenarios draft</xref>, the security requirements of the various application
scenarios vary tremendously. So in this section, we divide the
application scenarios into two main types, instead of analyzing all the
security threats with each specific scenario described in the
application scenarios draft, we just analyze the relative security
threats of these two types, which represent most of the likely
deployment scenarios in the real world. For example, the "Public P2P
VoIP Service Providers" scenario in section 4.1.1 of application
scenarios draft may be deployed using the first type(refer to section
5.1 of this specification), and the "Open Global P2P VoIP Network"
scenario in section 4.1.2 of application scenarios draft may be deployed
using the second type(refer to section 5.2 of this specification).</t>
<section title="Trusted P2P Overlay Base">
<t>In a trusted P2P Overlay Base, all the peers are deployed with
trustful nodes. They are of good behaviors. They may deployed to
provide reliable and high quality services, and may also do some
management issues for the overlay. All P2PSIP clients access the
overlay service through the associated trusted peer. Shown as the
following figure 3.</t>
<figure>
<preamble></preamble>
<artwork align="center"><![CDATA[
+---------+ +---------+
| Trusted +---------------+ Trusted |
| Peer | | Peer |
+---+-----+ +----+----+
| |
| |
|
| |
| P2PSIP Peer |
+---+-----+ Protocol +----+----+
| Trusted +---------------+ Trusted |
| Peer | | Peer |
+---+-----+ +----+----+
| |
P2PSIP Client |
Protocol |
+---+-----+ +----+----+
| | | |
|Client | | Client |
+---------+ +---------+
Figure 3 Trusted P2P Overlay Base]]></artwork>
<postamble></postamble>
</figure>
<t>As for this type of scenarios, we regard the P2P Overlay Base to be
secure. The security issues to be considered are the transport
security between trusted peers and the security issues associated with
clients. Because clients doesn't provide routing service for the
overlay. Security issues more focus on distributed storage layer. Some
of the attacks are described in the appendix of this draft.</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[ +--------------------+-----------------------+---------------------+
| Possible Attacks | Descriptions | Considerations |
|--------------------+-----------------------+---------------------+
| | 1.Message Privacy | TLS and DTLS |
| Transport Related | 2.ID hijack | |
+--------------------+-----------------------+---------------------+
|Unauthorized Data | Unauthorized Access, | Certificate |
|Operation | Modification, Removing| Mechanism |
+--------------------+-----------------------+---------------------+
| | In the progress of | |
| Man In the Middle | Authentication between| Authentication |
| | client and its | Security |
| | associated peer | |
+--------------------+-----------------------+---------------------+
| | | |
| data pollution and |1.Publish Fake Resource| 1.Check Mechanism? |
| poison | Objects | |
| |2.Publish malicious | 2.Black List? |
| | contact information | |
| | (DDOS attack) | |
+--------------------+-----------------------+---------------------+
| | | |
| Spam Attack | Publish lots of | 1. Check Mechanism? |
| | redundant resources | 2. Limit one's |
| | | publication number? |
+--------------------+-----------------------+---------------------+
Figure 4 Possible Attacks on the Trusted Overlay Base Scenarios]]></artwork>
<postamble></postamble>
</figure>
</section>
<section title="Untrusted P2P Overlay Base">
<t>In an untrusted P2P Overlay Base, there are peers who are not
trusted by other peers. Some of untrusted peers may do harmful things
or abnormal behaviors to the overlay due to malicious or unknown
intentions. There may or may not exist trusted peers in the overlay.
Shown as the following Figure 5.</t>
<figure>
<preamble></preamble>
<artwork align="center"><![CDATA[
Please view in a fixed-width font such as
Courier.
+---------+ +---------+
|Untrusted+---------------+ Peer |
| Peer | | |
+---+-----+ +----+----+
| |
| |
| |
| |
| P2PSIP Peer |
+---+-----+ Protocol +----+----+
| Peer +---------------+Untrusted|
| | | Peer |
+---+-----+ +----+----+
| |
P2PSIP Client P2PSIP Client
Protocol Protocol
+---+-----+ +----+----+
| | | |
|Client | | Client |
+---------+ +---------+
Figure 5 Untrusted P2P Overlay Base
]]></artwork>
<postamble></postamble>
</figure>
<t>As for this type of scenarios, the security threats with the
Trusted P2P Overlay Base still exist, besides that, even more security
issues emerge, because there may exist malicious peers in this type of
scenarios. Each layer of the P2PSIP architecture and the enrollment
may be attacked, the attacks beyond those in the Trusted Overlay Base
scenarios are listed in the followings Figure 6.</t>
<figure>
<preamble></preamble>
<artwork align="center"><![CDATA[ +--------------------+-----------------------+---------------------+
| Possible Attacks | Descriptions | Considerations |
|--------------------+-----------------------+---------------------+
| |1.Chosen-ID attack | 1.Enrollment Server |
| Identity Attack |2.Sybil Attack | |
| |3.Fabricated response | 2.A proof mechanism |
| | from the intermediate| to verify whether it|
| | peer | is a true root? |
+--------------------+-----------------------+---------------------+
| |1.discard messages | 1.message signature?|
| Forwarding Attack |2.Forwarding to a wrong| 2.A diagnosis |
| |next hop node | mechanism for |
| |3.modify messages when | detecting which |
| |forwarding | intermediate peer is|
| | | a bad man? |
+--------------------+-----------------------+---------------------+
| | Intermediate peer | |
| Replay Attack | stores messages and |Timestamp to |
| | replays |recognize timed |
| | |messages? |
+--------------------+-----------------------+---------------------+
| | give malicious | |
| Routing Table | response info to an |Per DHT specific? |
| Attack | updating routing table| |
| | request | |
+--------------------+-----------------------+---------------------+
Figure 6 Possible Attacks on the Untrusted Overlay Base Scenarios]]></artwork>
<postamble></postamble>
</figure>
<t>As for these security issues, <xref
target="I-D.zheng-p2psip-diagnose">the diagnosis draft</xref>
provides a
framework using an ECHO message to diagnose some of the problems in
the P2PSIP overlay.</t>
</section>
</section>
<section title="Security requirements">
<t>This section describes requirements related to the security of a
P2PSIP system. We divided the requirements into user requirements and
system requirements.</t>
<section title="User requirements">
<t>The user wants available and reliable service that enables him to
interact with other users and resources in a secure way. This means
that the P2PSIP system MUST provide:</t>
<t><list style="symbols">
<t>lookup and discovery of users and resources that is secure and
reliable,</t>
<t>certainty of user and resource identity,</t>
<t>confidentiality and integrity of end-to-end multimedia
communication,</t>
<t>easy and secure enrollment to the P2PSIP system,</t>
<t>privacy.</t>
</list></t>
</section>
<section title="System requirements">
<t>In order for a P2PSIP system to function properly and that the end
user gets a proper service, there are several aspects that the P2PSIP
system must take in to account.</t>
<section title="Dependence of reachability of a centralized server">
<t>Considering the nature of P2P in general, the dependence of
reachability of a centralized server SHOULD be minimized. There may
be unavoidable situations such as the enrollment process, where this
is not possible. However, the normal functioning of the P2PSIP
overlay such as join and leave operations, modification, retrieval
and deletion of P2PSIP resource (user) records from the P2PSIP
system should not depend on the reachability of a centralised
server.</t>
</section>
<section title="Scalability">
<t>P2PSIP security SHOULD scale from a small ad-hoc network to a
network with hundred millions of network nodes and users.</t>
</section>
<section title="Preference of existing security mechanisms">
<t>Although P2PSIP defines a new architecture, and thereby new
interfaces and protocols, for security there are several
standardized solutions for access control, authentication, integrity
protection and communication security. Using established protocols
minimizes potential security loopholes that need to be patched
later. Besides implementation is easer if chosen security protocols
are widely implemented and used.</t>
</section>
<section title="Requirements on a base P2P algorithm">
<t>All of the security operations should be specified in such a
way that they do not impose new unnecessary requirements on a base P2P
algorithm (e.g., DHT implementations) and limit its scalability. The
security issues that are not introduced by the P2P algorithm MUST not
be isolated to the P2P algorithm to solve. </t>
</section>
<section title="Node and user identification">
<t>The P2PSIP system MUST preserve user and resource identities. It
MUST NOT be possible to steal a P2PSIP identity from another
user.</t>
<t>Because some attackers may try to use identities of another
P2PSIP network entities it must be possible to verify the identity
of another party. </t>
</section>
<section title="Enrollment">
<t>The ease for users to enroll to a P2PSIP system SHOULD be ensured
as said in the section 4.1. The enrollment process defines the set
of users and P2PSIP network entities that may participate in a
P2PSIP system and issues them credentials. This process is defined
by the P2PSIP system, and the policy who can participate to is done
during this process. The enrollment process policy may define:</t>
<t><list style="symbols">
<t>how many and what user IDs and peer IDs an user or a P2PSIP
network entity may register,</t>
<t>whether users are charged for the usage of the P2PSIP
system,</t>
<t>and how often they must re-new their subscription to the
P2PSIP system.</t>
</list></t>
<t>As it was indicated in <xref
target="I-D.bryan-p2psip-requirements"/> the enrollment process may take
several measures in admitting a user or a network node to the P2PSIP
system, for example:</t>
<t><list style="symbols">
<t>may require strong identity such as employment or identity
provided by a trusted 3rd party or by the P2PSIP service
operator,</t>
<t>may charge for the enrollment,</t>
<t>may apply reputation mechanisms.</t>
</list></t>
<t>Although the user probably is the entity that enrolls to the
P2PSIP system, the credentials that are the result of the enrollment
are used to grant a device the right to function as a peer, client
or any other operative function possible in the system. Thus the
security of enrollment also translates to the security of the device
itself where the credentials are stored, and threats related to
device security in general.</t>
</section>
<section title="Replay attacks">
<t>An attacker should not be able to repeat or delay valid data
transmission during enrollment and modification of P2PSIP resource
(user) records in a P2PSIP overlay.</t>
</section>
<section title="Data access">
<t>An attacker MUST NOT be able to easily corrupt, delete, or
overwrite other user's or resource's data stored in P2PSIP resource
(user) records as well as routing tables. Only authorized users MUST
be able to modify, delete or overwrite their P2PSIP resource (user)
records in the P2PSIP system. P2PSIP security should allow users and
P2PSIP network entities to register the same resources (e.g.
TURN@overlay.net), however each entity should have rights only to
its own part of a resource record. In other words each entity should
be able to perform the same operations on its part of a resource
record as on its own resource (user) records.</t>
<t>The owner of the P2PSIP resource (user) records SHOULD be able to
authorize other users and network entities to modify, delete their
P2PSIP resource (user) records.</t>
</section>
<section title="Data validation">
<t>First and foremost it MUST be possible to verify that the data
stored in or retrieved from the P2PSIP overlay is authentic, i.e.
was not tampered by unauthorized P2PSIP network entities.</t>
<t>The peer that stores P2PSIP resource (user) records MUST be able
to validate the data received in the process of P2PSIP resource
(user) record insertion and modification.</t>
</section>
<section title="Denial of Service (DOS) attacks">
<t>It MUST NOT be possible to obtain control of the location in the
overlay where the attacked user's or resource's records are
registered. In order to prevent so-called Sybil or join-leave
attacks the attacker SHOULD NOT be able to easily register a
unlimited number of IDs of his choice in the P2SIP overlay. The
P2PSIP system SHOULD be able to control ID assignment. Once
assigned, an ID or a set of IDs SHOULD be difficult to change.</t>
<t>In addition the P2PSIP architecture SHOULD make sure that data
stored in a P2PSIP overlay is persistent, meaning that even if a
number of nodes (but not all of nodes in the overlay) fails the data
stored by those nodes is not lost. In addition the attacker MUST NOT
be able to register unlimited number of resources in the
overlay.</t>
</section>
<section title="Privacy">
<t>The security of P2PSIP systems MUST guarantee privacy of the
P2PSIP network participants. The P2PSIP security SHOULD allow the
users and P2PSIP network entities to indicate which other users or
P2PSIP network entities can retrieve, modify, and delete data stored
in their P2PSIP resource (user) records. The owner of a P2PSIP
resource (user) record SHOULD be able to limit the access to his own
resource (user) records, and this feature should be enforced by the
P2P network.</t>
<t>It MUST also be difficult to monitor who is communicating with a
particular user, or retreive any contextual data about the user
without the user's explicit consent. The P2PSIP network entities
MUST be provided with option to encrypt data exchanged with other
P2PSIP network entities.</t>
</section>
<section title="Detection and rejection of badly behaving nodes">
<t>It SHOULD be possible to limit potential damage caused by
malfunctioning and badly behaving nodes in a P2PSIP system. As the
policy taken by the P2PSIP system operator/community may be very
liberal, any user can obtain the right to be a user of a P2PSIP
system. It may be that some users behave badly intentionally in
which case it should be possible limit the impact of the badly
behaving nodes on the overall system security. It SHOULD be possible
to identify badly behaving nodes, and exclude or reject them from
the P2PSIP system.</t>
</section>
<section title="Summary of the system requirements">
<t>P2PSIP system requirements related to security issues are
summarized below:</t>
<t>Req. 1: Dependence of reachability of a centralized server SHOULD
be minimized.</t>
<t>Req. 2: P2PSIP security SHOULD scale from a small ad-hoc network
to a network with hundred millions of network nodes and users.</t>
<t>Req. 3: Existing security mechanisms SHOULD be used as much as
possible to protect P2PSIP functions, and avoid the need for
standardizing new mechanisms.</t>
<t>Req. 4: Security requirements on the base P2P algorithm (e.g.,
DHT implementations) used in P2PSIP SHOULD be minimized and SHOULD
NOT limit its scalability.</t>
<t>Req. 5: The registered identities in a P2PSIP overlay MUST be
preserved. The attacker MUST NOT be able to steal identity from
another user.</t>
<t>Req. 6: The enrollment process MUST make it difficult for an
attacker to register many identities in a P2PSIP overlay and easily
modify the registered identities.</t>
<t>Req. 7: It MUST be difficult to select a particular peer ID e.g.
peer ID assignment process should introduce some degree of
randomness to peer identities.</t>
<t>Req. 8: It MUST be possible to authenticate users and P2PSIP
network entities.</t>
<t>Req. 9: It MUST NOT be possible to repeat or delay valid data
transmission during enrollment and modification of P2PSIP resource
(user) records.</t>
<t>Req. 10: The P2PSIP security MUST support integrity protection of
the data being inserted or retrieved to/from an overlay.</t>
<t>Req. 11: The P2PSIP network entities MUST be provided with an
option to encrypt data exchanged with other P2PSIP network
entities.</t>
<t>Req. 12: Only authorized users and P2PSIP network entities MUST
be able to join the P2PSIP system and insert, modify, delete or
overwrite P2PSIP resource (user) records in the P2PSIP system.</t>
<t>Req. 13: In the situations where many users or P2PSIP network
entities register the same resource in the P2PSIP overlay, each
entity MUST have rights only to its own part of a resource
record.</t>
<t>Req. 14: An owner of P2PSIP resource (user) record MAY indicate
which users or network entities can retrieve, modify, and delete
data stored in their P2PSIP resource (user) records.</t>
<t>Req. 15: P2PSIP overlay protocols MUST be designed such a way so
that the effect of DOS attacks on the P2PSIP overlay is
minimized.</t>
<t>Req. 16: It SHOULD be possible to limit the impact of badly
behaving P2PSIP nodes on the overall system security. There SHOULD
be an option to identify malfunctioning or badly behaving nodes, and
exclude or reject them from the P2PSIP system.</t>
</section>
</section>
</section>
<section anchor="sec:security" title="Security Considerations">
<t>This memo discusses security threats in P2PSIP overlay networks.
Security aspects are discussed throughout the document. However, this
document does not introduce any security risk by itself.</t>
</section>
<section anchor="sec:iana" title="IANA Considerations">
<t>There are no IANA considerations associated to this memo.</t>
</section>
<section title="Acknowledgments">
<t>The authors would like to thank the many people of the IETF P2PSIP WG
that have contributed to discussions and provided input invaluable in
assembling this document.</t>
<t>Acknowledgement is also given to Jan-Erik Ekberg and Pekka
Laitinen, both with Nokia, and to Jiang Xingfeng with Huawei for
their work on earlier versions of the documents now incorporated into
this draft.</t>
</section>
<section anchor="Changes" title="Changes">
<section title="Revision 4">
<t>In this revision, the following changes were made:<list
style="symbols">
<t>Author team was modified.</t>
<t>Author Note was changed to reflect that changes will be
made based on new RELOAD draft.</t>
<t>Various wording changes based on comments from Christian
Schmidt.</t>
<t>The migration of references was begun to a form where they
will stay up-to-date when new versions of the document are
created.</t>
</list></t>
</section>
</section>
<section title="Appendix: Security threats">
<t>This section analyses security threats in the Peer-to-Peer SIP
architecture.</t>
<section title="Replay Attacks">
<t>Replay attacks are a form of network attacks where a valid data
transmission is repeated or delayed. A badly behaving node may take an
older message sent by another node, resend it to the overlay, and thus
replace any newer data with the old information present in this
message. During those procedures, an attacker may be able to enroll
credentials for himself, or replace existing entry in the P2PSIP
overlay by an older entry. Thus, the architecture must consider this
issue in the process of both enrollment and modification of P2PSIP
resource (user) records in a P2PSIP overlay.</t>
<t>This is especially applicable to P2PSIP overlays that use the
recursive routing style. In the recursive routing style, data sent in
a PUT request traverses many peers in the overlay. If there is no
protection against the replay attacks any peer that forwards the
request may store a copy of the request and resend the captured
request corrupting data stored in the overlay.</t>
</section>
<section title="Message Insertion, Modification, Deletion">
<t>The message insertion, modification, and deletion attacks are where
an attacker is able to alter the messages being exchanged between two
end points.</t>
<t>P2PSIP peers connect to other peers to form the P2PSIP overlay
network. Typically peers provide storage, routing and bootstrap
services for other peers and clients. They allow P2PSIP entities to
PUT information to or GET information from the P2PSIP overlay network.
In the P2PSIP overlay that allows for a recursive routing, peers are
responsible for forwarding messages (requests and responses) received
from P2PSIP network entities to other peers. Depending on the size of
the overlay a single message can be forwarded by many peers before it
reaches a destination. In the iterative routing peers are responsible
for redirecting the requests to other peers. They do not forward the
requests to other peers. They respond to a request originator with an
address of a peer that should be contacted in the next step. In such
an environment a badly behaving peer may:</t>
<t><list style="symbols">
<t>modify incoming messages,</t>
<t>discard incoming messages (the peer can discard requests and
responses it is supposed to forward),</t>
<t>generate incorrect responses to requests that are directed to
some other nodes.</t>
</list></t>
<t>The first bullet point describes the attack that allows the peer to
cause the overlay to store unauthorized or outdated information in the
resource (user) records or return corrupted data to the originator of
the GET request (a peer or client). The peer may change the data
record in the overlay by changing incoming PUT messages or modify
result of the GET operation by modifying incoming GET responses. With
this type of attack the integrity of the P2PSIP system can become
compromised.</t>
<t>The middle bullet point is related not only to attacks that allow a
malicious peer to prevent access to a P2PSIP resource (user) record,
but also to attacks that can degrade the performance of the P2PSIP
system making it useless from the end-user perspective. The second
problem is of high importance in P2PSIP overlays that store user's
reachability data which is much more time-critical than content stored
in file sharing networks.</t>
<t>The attack described in the last bullet above may lead to a
requestor receiving corrupted data e.g. a connectivity information
that points to some other node. This may happen if a malicious peer
can respond to incoming requests that are directed to another
peer.</t>
<t>Besides peers may act as relays relaying traffic between two P2PSIP
network entities or act as a SIP proxy and a SIP registrar. Providing
those services a malicious peer may perform a similar attacks as
described above. Let us consider the following deployment scenario
where some peers act as SIP registrars or/and SIP proxies and allow a
conventional SIP UA to access resources of the P2PSIP overlay network.
An unmodified SIP UA sends an SIP Invite request towards an unknown
peer that acts as a SIP proxy. If the SIP messages are not
cryptographically protected, this peer may act maliciously and proxy a
request to other than intended node or modify SDP messages in order to
stay on the media path. Similarly a peer that acts as a SIP Registrar
may modify registration information before it sends it to a peer that
is responsible for storing the P2PSIP user record of a registering SIP
UA. Those attacks do not have impact on the integrity of the overlay.
Nevertheless those attacks must be addressed by designers of service
specific protocols such as <xref target="RFC3261">SIP</xref>.</t>
</section>
<section title="Man-In-The-Middle">
<t>In man-in-the-middle (m-i-m) attacks a malicious node can hijack a
connection established between two legitimate nodes, or just listen
and/or modify messages exchanged between two nodes. In contrast to the
attacks presented in Section 3.2 man-in-the middle attacks are
prevalent in pairing and authentication procedures.</t>
<t>The m-i-m threat can be mitigated by using well-established
authentication protocols. The authentication protocols may be used to
verify if a certain P2PSIP entity is the entity it claims to be, for
example if it is really a peer that is identified by a certain peer
ID. The authentication protocols can also be used to verify if a
particular P2PSIP entity belongs to a particular overlay or not.
However, authentication protocols cannot fully mitigate all of the
attacks presented in Section 3.2. There can be malicious peers that
are authorised overlay participants with a particular peer
identifiers.</t>
<t>If a bootstrap process is fully decentralised and a bootstrap node
is not trusted or authentication of the bootstrap node is not
possible, then the joining node can easily be attacked, e.g. it may be
redirected to another overlay or a part of the legacy overlay that is
controlled by the attacker. However if it is possible to authenticate
a particular peer in the overlay the joining peer may use P2P specific
mechanisms to detect if it is redirected to the right overlay or the
right place in the overlay.</t>
<t>Conventional SIP proxy and SIP registrars are servers maintained by
a service provider. If a user trust a service provider he also trusts
servers the service provider maintains. In P2PSIP SIP proxies and
registrars can be maintained by users themselves (they can be
collocated with peers). In a distributed environment it is very
difficult to trust all of peers in the overlay. Without an efficient
verification mechanism that allows to verify which peers are be
trusted, peers that act as SIP proxies and registrars may easily
perform m-i-m attacks. The problem must be solved by SIP designers as
well as by the P2PSIP community.</t>
</section>
<section title="Offline Cryptographic Attacks">
<t>The incentive to break a secure system dominates the effort to do
so. It is likely that P2PSIP systems do not pose a likely target for
attacks, and if state-of-the art security methods are used, the needed
effort to break the system by breaking cryptography is very likely to
be higher than by finding and exploiting software errors and
vulnerabilities.</t>
</section>
<section title="Unauthorized Usage">
<t>The basic notions of authentication and authorization, when
implemented correctly and consistently SHOULD protect against
unauthorized usage of the P2PSIP system. However, the trustworthiness
of an identity may be weak i.e. the enrollment system might be fairly
open and allow devices and persons that wish to attack the system.
Thus, there is a significant threat of attacks from within the
system.</t>
<t>A malicious peer may do a multitude of attacks towards the overlay
including:</t>
<t><list style="symbols">
<t>ignoring, changing, and deleting records in DHT that is it
responsible for,</t>
<t>misbehaving during data lookups (ie, giving wrong node
addresses, discarding queries).</t>
</list></t>
<t>The first bullet point is related to attacks that may cause DHT to
contain unauthorized, outdated information and/or miss information
about users or resources. Each peer is responsible for a part of the
hash space. Peers store resource (user) records that fall into their
part of the hash space. A malicious peer may modify or delete resource
(user) records it is supposed to store. It may also reply with
incorrect information to the GET requests addressed to resource (user)
records it is responsible for. In addition it may ignore any record
updates. These attacks are not limited to peers that are responsible
for primary copies of resource (user) records. They are also related
to peers that store replicas of resource (user) records. Besides a
bootstrap node may also respond with wrong bootstraping
information.</t>
<t>The second bullet point addresses attacks that may impact
correctness of routing mechanisms. If the recoursive routing is used a
malicious peer can forward messages to another malicious node rather
than forwarding the messages according to the legitimate routing
information. This may also impact the iterative routing being
corrupted when the peer redirects the requester to a malicious
node.</t>
</section>
<section title="Inappropriate Usage">
<t>The P2PSIP essentially provides a distributed storage for P2PSIP
resource (user) records. The data stored in the distributed database
can be used in an inappropriate manner. If there is no access control
to a resource (user) records stored in the overlay and any node can
update or retrieve information stored in the overlay. An attacker may
request data stored in the P2PSIP resource (user) records and perform
inappropriate usage attacks. Besides the attacker may also update
entries of other users or resources.</t>
<t>The individual services provided by P2PSIP (messaging, real-time
communication) have their respective threat models regarding
inappropriate use (Spam, viruses, ...) but these can be considered out
of scope for this document.</t>
</section>
<section title="Denial of Service">
<t>In the P2PSIP architecture <xref target="1"/>, the P2PSIP resource (user) records
are not maintained in a central, trustworthy storage system, rather
they are distributed among peers participating in the system. Routing,
relaying, SIP proxy and registrar services are also distributed among
P2PSIP entities. In cases where authentication in the P2PSIP overlay
is weak or where the system is fairly open to new participants the
"infiltration" is trivial (e.g., Sybil attack).</t>
<t>If peers in the P2PSIP overlay can freely choose peer IDs or/and
easily modify previously selected peer IDs the attacker may use
join-leave attacks to place a malicious peer intentionally at any
location in overlay. Placing the peer at any location allows an
attacker to obtain control of the location in the overlay where the
attacked user or resource is registered. A malicious peer may discard,
modify the data it is supposed to store and may discard lookup
requests or reply with incorrect entries to the incoming requests.</t>
<t>The attacker may also try to register a large number of resources
to the P2PSIP overlay increasing processing load on peers that are
responsible for storing the resources and limiting the overall
capacity of the P2PSIP overlay network. It may also try to register
all popular names preventing the name holders from registering their
preferred URIs.</t>
<t>Another critical point where a D-o-S attack can be mounted is the
enrollment system.</t>
</section>
<section title="Communication security threats">
<t>The main places where communication security becomes an issue in
the P2PSIP context is the enrollment process and the communication
between endpoints. The last ones are subject to all typical threats in
this domain, however they have been individually considered in the
earlier sections of this chapter.</t>
<t>This document assumes that the actual SIP service implementation
provides its own communication security, and that P2PSIP adds to that
only in providing a means for the communication endpoints to establish
a shared key for further security needs. Otherwise, the communication
security threats in that domain is out-of-scope for this
discussion.</t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="1">
<front>
<title>Concepts and Terminology for Peer to Peer SIP</title>
<author fullname="David A. Bryan" initials="D" surname="Bryan">
<organization></organization>
</author>
<author fullname="Philip Matthews" initials="P" surname="Matthews">
<organization></organization>
</author>
<author fullname="Eunsoo Shim " initials="P" surname="Shim">
<organization></organization>
</author>
<author fullname="Dean Willis" initials="D" surname="Willis">
<organization></organization>
</author>
<date day="25" month="April" year="2007" />
</front>
<seriesInfo name="Internet-Draft"
value="draft-ietf-p2psip-concepts-02.txt" />
<format target="http://tools.ietf.org/id/draft-ietf-p2psip-concepts-02.txt"
type="TXT" />
</reference>
&RFC2119;
&RFC3261;
&I-D.ietf-p2psip-sip;
&I-D.ietf-p2psip-base;
&I-D.song-p2psip-security-eval;
&I-D.bryan-p2psip-app-scenarios;
&I-D.bryan-p2psip-requirements;
&I-D.zheng-p2psip-diagnose;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:07:24 |