Security requirements in Peer-to-Peer Session Initiation Protocol (P2PSIP)
draft-matuszewski-p2psip-security-requirements-04

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 May 7, 2009.

Abstract

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.

Table of Contents

1.  Authors' Notes
2.  Introduction
3.  Definitions
    3.1.  General
    3.2.  P2PSIP network entity
    3.3.  P2PSIP system
    3.4.  P2P Overlay Base
4.  Security Comparison between C/S and P2P
5.  Security Analysis with P2P Layers
    5.1.  Transport Layer Security
    5.2.  Routing Maintenance and KBR layer Security
    5.3.  Distributed Storage and Replication Layer Security
    5.4.  Application Layer Security
6.  Security Analysis with Application Scenarios
    6.1.  Trusted P2P Overlay Base
    6.2.  Untrusted P2P Overlay Base
7.  Security requirements
    7.1.  User requirements
    7.2.  System requirements
        7.2.1.  Dependence of reachability of a centralized server
        7.2.2.  Scalability
        7.2.3.  Preference of existing security mechanisms
        7.2.4.  Requirements on a base P2P algorithm
        7.2.5.  Node and user identification
        7.2.6.  Enrollment
        7.2.7.  Replay attacks
        7.2.8.  Data access
        7.2.9.  Data validation
        7.2.10.  Denial of Service (DOS) attacks
        7.2.11.  Privacy
        7.2.12.  Detection and rejection of badly behaving nodes
        7.2.13.  Summary of the system requirements
8.  Security Considerations
9.  IANA Considerations
10.  Acknowledgments
11.  Changes
    11.1.  Revision 4
12.  Appendix: Security threats
    12.1.  Replay Attacks
    12.2.  Message Insertion, Modification, Deletion
    12.3.  Man-In-The-Middle
    12.4.  Offline Cryptographic Attacks
    12.5.  Unauthorized Usage
    12.6.  Inappropriate Usage
    12.7.  Denial of Service
    12.8.  Communication security threats
13.  Normative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1.  Authors' Notes

This document represents a merge of two drafts:

• draft-matuszewski-p2psip-security-requirements
• [I‑D.song‑p2psip‑security‑eval] (Yongchao, S., Zhao, B., Jiang, X., and J. Haifeng, “P2PSIP Security Analysis and Evaluation,” February 2008.)

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:

• The document will be synchronized with the recently released updates to the RELOAD protocol as documented by editor Bruce Lowekamp in [I‑D.ietf‑p2psip‑sip] (Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, “A SIP Usage for RELOAD,” March 2010.) and [I‑D.ietf‑p2psip‑base] (Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, “REsource LOcation And Discovery (RELOAD) Base Protocol,” March 2010.)
• The merge between the two previous documents will be completed so that the text flows better.
• 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.

2.  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 [1] (Bryan, D., Matthews, P., Shim, P., and D. Willis, “Concepts and Terminology for Peer to Peer SIP,” April 2007.) 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.

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 security analysis and evaluation draft (Yongchao, S., Zhao, B., Jiang, X., and J. Haifeng, “P2PSIP Security Analysis and Evaluation,” February 2008.) [I‑D.song‑p2psip‑security‑eval]. It complements the P2PSIP Protocol Framework and Requirements document (Bryan, D., “P2PSIP Protocol Framework and Requirements,” July 2007.) [I‑D.bryan‑p2psip‑requirements].

3.  Definitions

This section defines a number of concepts that are key to understand the rest of the document.

3.1.  General

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

3.2.  P2PSIP network entity

A P2PSIP network entity is a peer, client, or other functional node that may become a part of a P2PSIP overlay.

3.3.  P2PSIP system

A P2PSIP system consists of the P2PSIP overlay as defined in [1] (Bryan, D., Matthews, P., Shim, P., and D. Willis, “Concepts and Terminology for Peer to Peer SIP,” April 2007.) 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.

3.4.  P2P Overlay Base

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.

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

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

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

The four main layers are:

Transport Layer: Provides transport service for the upper layers.

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.

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.

Application Layer: Provides the user application, and invokes the services provided by the Distributed Storage and Replication Layer.

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.

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

5.2.  Routing Maintenance and KBR 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 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 one learned from another is correct or not. A correct routing table is important for hop by hop security.

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.

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?

Chosen-ID attack makes the above security issues much more worse.

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.

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.

The first and fourth issue above is about routing maintenance function security, and the remain two issues are about the KBR function security.

5.3.  Distributed Storage and Replication Layer Security

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.

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.

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.

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?

Replication security is to TODO.

5.4.  Application Layer Security

Application layer security requirements are out of scope of this specification.

6.  Security Analysis with Application Scenarios

As described in the security considerations section in the application scenarios draft (Bryan, D., Shim, E., Lowekamp, B., and S. Dawkins, “Application Scenarios for Peer-to-Peer Session Initiation Protocol (P2PSIP),” November 2007.) [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 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).

6.1.  Trusted P2P Overlay Base

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.

    +---------+               +---------+
    | Trusted +---------------+ Trusted |
    | Peer    |               | Peer    |
    +---+-----+               +----+----+
        |                          |
        |                          |
        |
        |                          |
        |       P2PSIP Peer        |
    +---+-----+ Protocol      +----+----+
    | Trusted +---------------+ Trusted |
    | Peer    |               | Peer    |
    +---+-----+               +----+----+
        |                          |
    P2PSIP Client                  |
    Protocol                       |
    +---+-----+               +----+----+
    |         |               |         |
    |Client   |               | Client  |
    +---------+               +---------+


Figure 3    Trusted P2P Overlay Base

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.

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

6.2.  Untrusted P2P Overlay Base

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.

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

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.

 +--------------------+-----------------------+---------------------+
 |  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 (Yongchao, S. and X. Jiang, “Diagnose P2PSIP Overlay Network,” December 2008.) [I‑D.zheng‑p2psip‑diagnose] provides a framework using an ECHO message to diagnose some of the problems in the P2PSIP overlay.

7.  Security requirements

This section describes requirements related to the security of a P2PSIP system. We divided the requirements into user requirements and system requirements.

7.1.  User requirements

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:

• lookup and discovery of users and resources that is secure and reliable,
• certainty of user and resource identity,
• confidentiality and integrity of end-to-end multimedia communication,
• easy and secure enrollment to the P2PSIP system,
• privacy.

7.2.  System requirements

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.

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

7.2.2.  Scalability

P2PSIP security SHOULD scale from a small ad-hoc network to a network with hundred millions of network nodes and users.

7.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 potential security loopholes that need to be patched later. Besides implementation is easer if chosen security protocols are widely implemented and used.

7.2.4.  Requirements on a base P2P algorithm

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.

7.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 must be possible to verify the identity of another party.

7.2.6.  Enrollment

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:

• how many and what user IDs and peer IDs an user or a P2PSIP network entity may register,
• whether users are charged for the usage of the P2PSIP system,
• and how often they must re-new their subscription to the P2PSIP system.

As it was indicated in [I‑D.bryan‑p2psip‑requirements] (Bryan, D., “P2PSIP Protocol Framework and Requirements,” July 2007.) the enrollment process may take several measures in admitting a user or a network node to the P2PSIP system, for example:

• may require strong identity such as employment or identity provided by a trusted 3rd party or by the P2PSIP service operator,
• may charge for the enrollment,
• 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.

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

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

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

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

7.2.11.  Privacy

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

7.2.12.  Detection and rejection of 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 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.

7.2.13.  Summary of the system requirements

P2PSIP system requirements related to security issues are summarized below:

Req. 1: Dependence of reachability of a centralized server SHOULD be minimized.

Req. 2: P2PSIP security SHOULD scale from a small ad-hoc network to a network with hundred millions of network nodes and users.

Req. 3: Existing security mechanisms SHOULD be used as much as possible to protect P2PSIP functions, and avoid the need for standardizing new mechanisms.

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.

Req. 5: The registered identities in a P2PSIP overlay MUST be preserved. The attacker MUST NOT be able to steal identity from another user.

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.

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.

Req. 8: It MUST be possible to authenticate users and P2PSIP network entities.

Req. 9: It MUST NOT be possible to repeat or delay valid data transmission during enrollment and modification of P2PSIP resource (user) records.

Req. 10: The P2PSIP security MUST support integrity protection of the data being inserted or retrieved to/from an overlay.

Req. 11: The P2PSIP network entities MUST be provided with an option to encrypt data exchanged with other P2PSIP network entities.

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.

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.

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.

Req. 15: P2PSIP overlay protocols MUST be designed such a way so that the effect of DOS attacks on the P2PSIP overlay is minimized.

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.

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

9.  IANA Considerations

There are no IANA considerations associated to this memo.

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

11.  Changes

11.1.  Revision 4

In this revision, the following changes were made:

• Author team was modified.
• Author Note was changed to reflect that changes will be made based on new RELOAD draft.
• Various wording changes based on comments from Christian Schmidt.
• The migration of references was begun to a form where they will stay up-to-date when new versions of the document are created.

12.  Appendix: Security threats

This section analyses security threats in the Peer-to-Peer SIP architecture.

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

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

• modify incoming messages,
• discard incoming messages (the peer can discard requests and responses it is supposed to forward),
• 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 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261].

12.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 3.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 3.2. There can be malicious peers that are authorised overlay participants with a particular peer identifiers.

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.

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.

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

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

• ignoring, changing, and deleting records in DHT that is it responsible for,
• 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 bootstraping information.

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.

12.6.  Inappropriate Usage

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.

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.

12.7.  Denial of Service

In the P2PSIP architecture [1] (Bryan, D., Matthews, P., Shim, P., and D. Willis, “Concepts and Terminology for Peer to Peer SIP,” April 2007.), 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.

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

13. Normative References

Authors' Addresses

Full Copyright Statement

Copyright © The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.