P2PSIP Working Group H. Song
Internet-Draft Huawei
Intended status: Informational M. Matuszewski
Expires: January 11, 2010 Nokia
D. York
Voxeo
July 10, 2009
P2PSIP Security Overview and Risk Analysis
draft-matuszewski-p2psip-security-requirements-05
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 11, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Song, et al. Expires January 11, 2010 [Page 1]
Internet-Draft P2PSIP Security Overview July 2009
Abstract
This document provides a security overview and analysis for the Peer-
to-Peer Session Initiation Protocol (P2PSIP) overlay network. It
discusses security threats for the P2PSIP architecture and its
components. It compares security difference between client/server
(C/S) and P2P implementations of SIP, and then partitions the P2PSIP
architecture into layers and analyzes the security issues in each
layer and the security relationship among the layers.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Security threats . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Message Insertion, Modification, Deletion . . . . . . . . 6
3.3. Man-In-The-Middle . . . . . . . . . . . . . . . . . . . . 8
3.4. Offline Cryptographic Attacks . . . . . . . . . . . . . . 8
3.5. Unauthorized Usage . . . . . . . . . . . . . . . . . . . . 9
3.6. Inappropriate Usage . . . . . . . . . . . . . . . . . . . 9
3.7. Denial of Service . . . . . . . . . . . . . . . . . . . . 10
3.8. Communication security threats . . . . . . . . . . . . . . 10
4. Security Comparison between C/S and P2P . . . . . . . . . . . 12
5. Security Analysis with P2P Layers . . . . . . . . . . . . . . 14
5.1. Overlay Link Layer Security . . . . . . . . . . . . . . . 15
5.2. Forwarding and Link Management Layer Security . . . . . . 15
5.3. Topology Plugin Security . . . . . . . . . . . . . . . . . 16
5.4. Storage Security . . . . . . . . . . . . . . . . . . . . . 16
5.5. Message Transport Security . . . . . . . . . . . . . . . . 17
5.6. Usage Layer Security . . . . . . . . . . . . . . . . . . . 18
6. Security Analysis with Application Scenarios . . . . . . . . . 19
6.1. Trusted P2P Overlay Base . . . . . . . . . . . . . . . . . 19
6.2. Untrusted P2P Overlay Base . . . . . . . . . . . . . . . . 21
7. Interconnection to other networks . . . . . . . . . . . . . . 24
7.1. Connections to SIP networks . . . . . . . . . . . . . . . 24
7.2. Direct connections to the PSTN . . . . . . . . . . . . . . 25
8. Security considerations . . . . . . . . . . . . . . . . . . . 26
8.1. User security considerations . . . . . . . . . . . . . . . 26
8.2. System security considerations . . . . . . . . . . . . . . 26
8.2.1. Dependence of reachability of a centralized server . . 26
8.2.2. Scalability . . . . . . . . . . . . . . . . . . . . . 26
8.2.3. Preference of existing security mechanisms . . . . . . 26
8.2.4. Base P2P security design considerations and
guideline . . . . . . . . . . . . . . . . . . . . . . 27
8.2.5. Node and user identification . . . . . . . . . . . . . 27
8.2.6. Enrollment . . . . . . . . . . . . . . . . . . . . . . 27
Song, et al. Expires January 11, 2010 [Page 2]
Internet-Draft P2PSIP Security Overview July 2009
8.2.7. Replay attacks . . . . . . . . . . . . . . . . . . . . 28
8.2.8. Unauthorized data access . . . . . . . . . . . . . . . 28
8.2.9. Data validation . . . . . . . . . . . . . . . . . . . 28
8.2.10. Denial of Service (DOS) attacks . . . . . . . . . . . 29
8.2.11. Privacy Protection . . . . . . . . . . . . . . . . . . 29
8.2.12. Badly behaving nodes . . . . . . . . . . . . . . . . . 29
9. Security Considerations . . . . . . . . . . . . . . . . . . . 30
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
12. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
12.1. Revision 5 . . . . . . . . . . . . . . . . . . . . . . . . 33
13. Normative References . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
Song, et al. Expires January 11, 2010 [Page 3]
Internet-Draft P2PSIP Security Overview July 2009
1. Introduction
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 [I-D.ietf-p2psip-concepts] . It
presents an introduction to security threats to P2PSIP environments
and then compares security difference between client/server (C/S) and
P2P implementations of SIP, and then 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. Some solutions to certain attacks are given as an example
in the analysis text. In the end, it provides user and system
security considerations for the P2PSIP overlay network. This
document is designed to complement the P2PSIP Protocol Framework and
Requirements document [I-D.bryan-p2psip-requirements].
Song, et al. Expires January 11, 2010 [Page 4]
Internet-Draft P2PSIP Security Overview July 2009
2. Terminology
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 [RFC2119].
We use the terminology and definitions from the Concepts and
Terminology for Peer to Peer SIP [I-D.ietf-p2psip-concepts] draft
extensively in this document. Other terms used in this document are
defined inline when used and are also defined below for reference.
O P2PSIP Network Entity: A P2PSIP network entity is a peer, client,
or other functional node that may become a part of a P2PSIP overlay.
O P2PSIP System: A P2PSIP system consists of the P2PSIP overlay as
defined in [I-D.ietf-p2psip-concepts] 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.
O 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.
O 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.
O 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.
Song, et al. Expires January 11, 2010 [Page 5]
Internet-Draft P2PSIP Security Overview July 2009
3. Security threats
This section analyses security threats in the Peer-to-Peer SIP
architecture.
3.1. Replay Attacks
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.
This is especially applicable to P2PSIP overlays that use the
recursive routing mode. In the recursive routing mode, 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.
3.2. Message Insertion, Modification, Deletion
The message insertion, modification, and deletion attacks are where
an attacker is able to alter the messages being exchanged between two
end points.
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:
o modify incoming messages,
Song, et al. Expires January 11, 2010 [Page 6]
Internet-Draft P2PSIP Security Overview July 2009
o discard incoming messages (the peer can discard requests and
responses it is supposed to forward),
o generate incorrect responses to requests that are directed to some
other nodes.
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.
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.
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.
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 SIP [RFC3261].
Song, et al. Expires January 11, 2010 [Page 7]
Internet-Draft P2PSIP Security Overview July 2009
3.3. Man-In-The-Middle
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 13.2 man-in-the middle attacks are
prevalent in pairing and authentication procedures.
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 13.2. There can be malicious peers that
are authorized overlay participants with a particular peer
identifiers.
If a bootstrap process is fully decentralized 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.
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.
3.4. Offline Cryptographic Attacks
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.
Song, et al. Expires January 11, 2010 [Page 8]
Internet-Draft P2PSIP Security Overview July 2009
3.5. Unauthorized Usage
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.
A malicious peer may do a multitude of attacks towards the overlay
including:
o ignoring, changing, and deleting records in DHT that is it
responsible for,
o misbehaving during data lookups (ie, giving wrong node addresses,
discarding queries).
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 bootstrapping
information.
The second bullet point addresses attacks that may impact correctness
of routing mechanisms. If the recursive 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.
3.6. Inappropriate Usage
The P2PSIP overlay 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)
Song, et al. Expires January 11, 2010 [Page 9]
Internet-Draft P2PSIP Security Overview July 2009
records and perform inappropriate usage attacks. Besides the
attacker may also update entries of other users or resources.
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.
3.7. Denial of Service
In the P2PSIP architecture [I-D.ietf-p2psip-concepts], 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).
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.
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.
Another critical point where a D-o-S attack can be mounted is the
enrollment system.
3.8. Communication security threats
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.
This document assumes that the actual SIP service implementation
provides its own communication security, and the P2PSIP adds to that
Song, et al. Expires January 11, 2010 [Page 10]
Internet-Draft P2PSIP Security Overview July 2009
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.
Song, et al. Expires January 11, 2010 [Page 11]
Internet-Draft P2PSIP Security Overview July 2009
4. Security Comparison between C/S and P2P
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.
However, in a P2P architecture the security issues are more complex.
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.
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 are intermediate nodes between the source and destination.
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.
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.
Song, et al. Expires January 11, 2010 [Page 12]
Internet-Draft P2PSIP Security Overview July 2009
+------------+----------------------+--------------------------+
| | | |
| | 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 Comparison between C/S and P2P security
Song, et al. Expires January 11, 2010 [Page 13]
Internet-Draft P2PSIP Security Overview July 2009
5. Security Analysis with P2P Layers
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.
Application
+-------+ +-------+
| SIP | | XMPP | ...
| Usage | | Usage |
+-------+ +-------+
-------------------------------------- Messaging API
+------------------+ +---------+
| Message |<--->| Storage |
| Transport | +---------+
+------------------+ ^
^ ^ |
| v v
| +-------------------+
| | Topology |
| | Plugin |
| +-------------------+
| ^
v v
+------------------+
| Forwarding & |
| Link Management |
+------------------+
-------------------------------------- Overlay Link API
+-------+ +------+
|TLS | |DTLS | ...
+-------+ +------+
Figure 2 P2PSIP architecture
The major components of RELOAD are:
Usage Layer: Each application defines a RELOAD usage; a set of
data kinds and behaviors which describe how to use the services
provided by RELOAD. These usages all talk to RELOAD through a
common Message Transport API.
Song, et al. Expires January 11, 2010 [Page 14]
Internet-Draft P2PSIP Security Overview July 2009
Message Transport: Handles the end-to-end reliability, manages
request state for the usages, and forwards Store and Fetch
operations to the Storage component. Delivers message responses
to the component initiating the request.
Storage: The Storage component is responsible for processing
messages relating to the storage and retrieval of data. It talks
directly to the Topology Plugin to manage data replication and
migration, and it talks to the Message Transport to send and
receive messages.
Topology Plugin: The Topology Plugin is responsible for
implementing the specific overlay algorithm being used. It uses
the Message Transport component to send and receive overlay
management messages, to the Storage component to manage data
replication, and directly to the Forwarding Layer to control hop-
by-hop message forwarding. This component closely parallels
conventional routing algorithms, but is more tightly coupled to
the Forwarding Layer because there is no single "routing table"
equivalent used by all overlay algorithms.
Forwarding and Link Management Layer: Stores and implements the
routing table by providing packet forwarding services between
nodes. It also handles establishing new links between nodes,
including setting up connections across NATs using ICE.
Overlay Link Layer: TLS and DTLS are the "link layer" protocols
used by RELOAD for hop-by-hop communication. Each such protocol
includes the appropriate provisions for per-hop framing or hop-by-
hop ACKs required by unreliable transports.
5.1. Overlay Link Layer Security
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 MUST 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.
5.2. Forwarding and Link Management Layer Security
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
Song, et al. Expires January 11, 2010 [Page 15]
Internet-Draft P2PSIP Security Overview July 2009
some security threats with the routing table updating interaction and
the key-based routing.
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 received by the peer correct or not. A correct routing table
is important for hop by hop forwarding security.
Second, some attackers may discard the messages when forwarding, or
on purpose forward the message to a wrong next hop. The overlay
should include some method to detect incorrectly forwarded messages.
Third, some attacks may cause high churn rate to the overlay. 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.
In this case, we need a method to control nodes joining 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.
Chosen-ID attack makes the above security issues much more worse.
In general, the main security issues in this layer are about routing
table maintenance security, and the the KBR function security.
5.3. Topology Plugin Security
The security issues with with this component are rather p2p algorithm
specific.
5.4. Storage Security
The storage component provides distributed storage service for the
resource objects that located in one's responsible resource ID range,
Song, et al. Expires January 11, 2010 [Page 16]
Internet-Draft P2PSIP Security Overview July 2009
and the replication service to keep the availability of resource
objects under churn. The security issues here are typically end to
end, and about the content and authority security.
First, We need to protect resource objects when needed against
unauthorized data operation such as fetch, modify or remove. A
solution for authorization is needed.
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 connections to B which will overload Peer B. Using
certificates can't solve this problem, a check mechanism for the
resource object is needed.
Third, overlays work well for a reasonable amount of resource
objects, but crash more or less when inserting big number of resource
objects per node. Spam attacks can make overlays go down. Open
issue: Should spam attack be considered in the storage layer? Or is
it only the responsibility of the application layer to handle this
problem?
Fourth, for the availability of the resource records in the overlay
network, replication is needed, but attackers can replicate excessive
amount of resources in the overlay network. So, only authorized
peers can replicate certain resources, and the number of resources
one can replicate is limited.
5.5. Message Transport Security
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
message transport security.
Another security issue in this layer is about the message state
maintenance. The timeout value for the end to end message transport
must be chosen appropriately, because too short timeout value will
cause the overlay be flooded with messages since the initiator will
send the request again before the response is received. And too long
timeout value will not satisfy the requirement for communication
efficiency when routing failures occur. An open issue here is: How
to derive the appropriate timeout value and should the timeout value
Song, et al. Expires January 11, 2010 [Page 17]
Internet-Draft P2PSIP Security Overview July 2009
be changed when the overlay size changes?
5.6. Usage Layer Security
The SIP usage security analysis is briefly discussed in the Security
Considerations section of [I-D.ietf-p2psip-sip].
Song, et al. Expires January 11, 2010 [Page 18]
Internet-Draft P2PSIP Security Overview July 2009
6. Security Analysis with Application Scenarios
As mentioned in the security considerations section in the
application scenarios draft [I-D.bryan-p2psip-app-scenarios], 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 6.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 6.2 of this specification).
6.1. Trusted P2P Overlay Base
In a trusted P2P Overlay Base, all the peers are deemed to be
trustworthy and are assumed to behave in a good manner. They may be
deployed to provide reliable and high quality services, and may also
do some management services for the overlay. All P2PSIP clients
access the overlay service through an associated trusted peer, as
shown in figure 3.
Song, et al. Expires January 11, 2010 [Page 19]
Internet-Draft P2PSIP Security Overview July 2009
+---------+ +---------+
| Trusted +---------------+ Trusted |
| Peer | | Peer |
+---+-----+ +----+----+
| |
| |
| |
| |
| P2PSIP Peer |
+---+-----+ Protocol +----+----+
| Trusted +---------------+ Trusted |
| Peer | | Peer |
+---+-----+ +----+----+
| |
P2PSIP Client |
Protocol |
+---+-----+ +----+----+
| | | |
|Client | | Client |
+---------+ +---------+
Figure 3 Trusted P2P Overlay Base
In these 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.
Security issues also focus on distributed storage layer.
Song, et al. Expires January 11, 2010 [Page 20]
Internet-Draft P2PSIP Security Overview July 2009
+--------------------+-----------------------+---------------------+
| 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 |
| | | per time unit |
+--------------------+-----------------------+---------------------+
Figure 4 Additional Possible Attacks on Trusted Overlay Base Scenarios
6.2. Untrusted P2P Overlay Base
In an untrusted P2P Overlay Base, there are peers who are not trusted
by other peers. Some of the untrusted peers may do harmful things or
abnormal behaviors to the overlay due to malicious or unknown
intentions. There may be trusted peers in the overlay, as Shown in
Figure 5.
Song, et al. Expires January 11, 2010 [Page 21]
Internet-Draft P2PSIP Security Overview July 2009
+---------+ +---------+
|Untrusted+---------------+ Trusted |
| Peer | | Peer |
+---+-----+ +----+----+
| |
| |
| |
| |
| P2PSIP Peer |
+---+-----+ Protocol +----+----+
| Trusted +---------------+Untrusted|
| Peer | | Peer |
+---+-----+ +----+----+
| |
P2PSIP Client P2PSIP Client
Protocol Protocol
+---+-----+ +----+----+
| | | |
|Client | | Client |
+---------+ +---------+
Figure 5 Untrusted P2P Overlay Base
In these scenarios, the security threats with the Trusted P2P Overlay
Base still exist. However there are many additional security threats
because there may exist malicious peers in these networks. 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 Figure 6.
Song, et al. Expires January 11, 2010 [Page 22]
Internet-Draft P2PSIP Security Overview July 2009
+--------------------+-----------------------+---------------------+
| 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
As for these security issues, the diagnosis draft
[I-D.zheng-p2psip-diagnose] provides a framework using diagnostic
methods to diagnose some of the problems in the P2PSIP overlay.
Song, et al. Expires January 11, 2010 [Page 23]
Internet-Draft P2PSIP Security Overview July 2009
7. Interconnection to other networks
While some P2PSIP systems may exist that only allow communication
between P2PSIP peers within the system, other P2PSIP systems may have
connections to other networks such as the traditional Public Switched
Telephone Network (PSTN) or newer SIP-based networks.
For example, a P2PSIP system might be deployed within a branch office
with a connection from the P2PSIP system going back to a SIP-based
communication network in a main corporate office. Alternatively, a
small office might deploy a P2PSIP system and then have some gateway
to the PSTN for external communication.
In examples such as these, care must be taken to ensure the security
of communication to those external networks. Note that the level of
concern may vary depending upon whether the P2PSIP overlay base is
trusted or untrusted, as discussed in the previous section.
7.1. Connections to SIP networks
A common scenario may be for a P2PSIP system to be connected to
another SIP network. This could be to a main corporate network as
described earlier, or it could be to a SIP-based Service Provider who
would then provide inbound and / or outbound connectivity to the
PSTN. It could also be to an on-premise device such as an IP-PBX or
SIP application server that would provide connectivity to other
networks.
Important considerations here include:
o How is the P2PSIP overlay network connected to the SIP network?
Is it through a single designated peer? Is it through multiple
peers?
o How is the availability of the connection to the SIP network
preserved?
o How susceptible to Denial of Service attacks is the connection?
o How are the authentication credentials for the SIP connection
protected?
o What kind of transport security is deployed for the connection?
o How are firewall traversal issues addressed?
Care must be taken that the confidentiality, integrity and
availability of this connection be maintained.
Song, et al. Expires January 11, 2010 [Page 24]
Internet-Draft P2PSIP Security Overview July 2009
7.2. Direct connections to the PSTN
While some P2PSIP systems may choose to connect to SIP-based Service
Providers to achieve PSTN connectivity, others might opt for direct
connectivity to the PSTN through local gateways such as hardware
cards. For instance, a small office might have a PC or other device
with a hardware card that provided connectivity to a traditional
analog line to the PSTN. Similarly, a desk phone may be created with
both an IP connection and an analog line connection.
In these cases, one or more of the P2PSIP Peers may have these
devices installed and may then advertise these resources as being
available. Important considerations here include:
o How is the availability of the Peer(s) providing the PSTN gateway?
o Are there protections in place to ensure that routing tables
aren't manipulated so that other Peers cannot find the gateways?
Song, et al. Expires January 11, 2010 [Page 25]
Internet-Draft P2PSIP Security Overview July 2009
8. Security considerations
This section describes aspects of security considerations in a P2PSIP
system.
8.1. User security considerations
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:
o lookup and discovery of users and resources that is secure and
reliable,
o certainty of user and resource identity,
o confidentiality and integrity of end-to-end multimedia
communication,
o easy and secure enrollment to the P2PSIP system,
8.2. System security considerations
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.
8.2.1. Dependence of reachability of a centralized server
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.
8.2.2. Scalability
P2PSIP security SHOULD scale from a small ad-hoc network to a network
with hundred millions of network nodes and users.
8.2.3. Preference of existing security mechanisms
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
Song, et al. Expires January 11, 2010 [Page 26]
Internet-Draft P2PSIP Security Overview July 2009
potential security loopholes that need to be patched later. Besides
implementation is easier if chosen security protocols are widely
implemented and used.
8.2.4. Base P2P security design considerations and guideline
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 left to the P2P algorithm to solve.
A P2PSIP system should provide methods to support various level of
security provisioning. Security requirements in P2P systems can be
different, depending on level of trust in the central entities and
connectivity to the global Internet. Security operations should be
specified in a manner that they do not overload base P2P algorithms
(e.g. DHT implementations). Security risks, not covered by these,
should be further investigated in research projects.
8.2.5. Node and user identification
The P2PSIP system MUST preserve user and resource identities. It
MUST NOT be possible to steal a P2PSIP identity from another user.
Because some attackers may try to use identities of another P2PSIP
network entities it should be possible to verify the identity of
another party.
8.2.6. Enrollment
The enrollment process defines the set of users and P2PSIP network
entities that may participate in a P2PSIP system. Each P2PSIP system
may establish its own policy for who can join the system. The
enrollment process policy may define:
o how many and what user IDs and peer IDs a user or a P2PSIP network
entity may register,
o and how often they must re-new their subscription to the P2PSIP
system.
As it was indicated in [I-D.bryan-p2psip-requirements] the enrollment
process may take several measures in admitting a user or a network
node to the P2PSIP system to increase security:
Song, et al. Expires January 11, 2010 [Page 27]
Internet-Draft P2PSIP Security Overview July 2009
o may require strong identity such as employment or identity
provided by a trusted 3rd party or by the P2PSIP service operator,
o may apply reputation mechanisms.
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.
8.2.7. Replay attacks
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.
8.2.8. Unauthorized data access
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.
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.
8.2.9. Data validation
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.
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.
Song, et al. Expires January 11, 2010 [Page 28]
Internet-Draft P2PSIP Security Overview July 2009
8.2.10. Denial of Service (DOS) attacks
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.
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.
8.2.11. Privacy Protection
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.
It MUST also be difficult to monitor who is communicating with a
particular user, or retrieve 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.
8.2.12. Badly behaving nodes
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 to limit the impact of the badly
behaving nodes on the overall system security. There should be
methods to look for badly behaving nodes and exclude or reject them
from the P2PSIP system.
Song, et al. Expires January 11, 2010 [Page 29]
Internet-Draft P2PSIP Security Overview July 2009
9. Security Considerations
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.
Song, et al. Expires January 11, 2010 [Page 30]
Internet-Draft P2PSIP Security Overview July 2009
10. IANA Considerations
There are no IANA considerations associated to this memo.
Song, et al. Expires January 11, 2010 [Page 31]
Internet-Draft P2PSIP Security Overview July 2009
11. Acknowledgments
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.
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.
Acknowledgement also to Christian Schmidt with Nokia Siemens Networks
for providing valuable input to this document.
Song, et al. Expires January 11, 2010 [Page 32]
Internet-Draft P2PSIP Security Overview July 2009
12. Changes
12.1. Revision 5
This document represents a merge of two drafts:
o draft-matuszewski-p2psip-security-requirements
o [I-D.song-p2psip-security-eval]
with some post-merge editing by Song Haibin, Dan York and Marcin
Matuszewski. The authors have finished with the work that is
promised in the previous version. The main changes include:
o The security requirements have been taken out from this document,
which have been sent out to the P2PSIP mailing list to provide
security guidance for the base draft. And this document has
become an analysis and tutorial for p2psip security.
o The document is synchronized with the recently released updates to
the RELOAD protocol as documented by editor Bruce Lowekamp in
[I-D.ietf-p2psip-sip] and [I-D.ietf-p2psip-base]
o The merge between the two previous documents is completed and the
text flows better.
o 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.
o A subsection about SIP usage security has been created.
o Various wording changes based on comments from Christian Schmidt.
Song, et al. Expires January 11, 2010 [Page 33]
Internet-Draft P2PSIP Security Overview July 2009
13. Normative References
[I-D.bryan-p2psip-app-scenarios]
Bryan, D., Shim, E., Lowekamp, B., and S. Dawkins,
"Application Scenarios for Peer-to-Peer Session Initiation
Protocol (P2PSIP)", draft-bryan-p2psip-app-scenarios-00
(work in progress), November 2007.
[I-D.bryan-p2psip-requirements]
Bryan, D., "P2PSIP Protocol Framework and Requirements",
draft-bryan-p2psip-requirements-00 (work in progress),
July 2007.
[I-D.ietf-p2psip-base]
Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
Base Protocol", draft-ietf-p2psip-base-02 (work in
progress), March 2009.
[I-D.ietf-p2psip-concepts]
Bryan, D., Matthews, P., Shim, E., Willis, D., and S.
Dawkins, "Concepts and Terminology for Peer to Peer SIP",
draft-ietf-p2psip-concepts-02 (work in progress),
July 2008.
[I-D.ietf-p2psip-sip]
Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
H. Schulzrinne, "A SIP Usage for RELOAD",
draft-ietf-p2psip-sip-01 (work in progress), March 2009.
[I-D.song-p2psip-security-eval]
Yongchao, S., Zhao, B., Jiang, X., and J. Haifeng, "P2PSIP
Security Analysis and Evaluation",
draft-song-p2psip-security-eval-00 (work in progress),
February 2008.
[I-D.zheng-p2psip-diagnose]
Yongchao, S. and X. Jiang, "Diagnose P2PSIP Overlay
Network", draft-zheng-p2psip-diagnose-04 (work in
progress), December 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
Song, et al. Expires January 11, 2010 [Page 34]
Internet-Draft P2PSIP Security Overview July 2009
Authors' Addresses
Song Haibin
Huawei
Baixia Road No. 91
Nanjing, Jiangsu Province 210001
P.R.China
Phone: +86-25-84565081
Fax: +86-25-84565070
Email: melodysong@huawei.com
Marcin Matuszewski
Nokia
P.O.Box 407
NOKIA GROUP, FIN 00045
Finland
Email: marcin.matuszewski@nokia.com
Dan York
Voxeo Corporation
Keene, NH
USA
Phone: +1-407-455-5859
Email: dyork@voxeo.com
URI: http://www.voxeo.com/
Song, et al. Expires January 11, 2010 [Page 35]
