P2PSIP Security Overview and Risk Analysis

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

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.

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.

1. Introduction
2. Terminology
3. Security threats
    3.1. Replay Attacks
    3.2. Message Insertion, Modification, Deletion
    3.3. Man-In-The-Middle
    3.4. Offline Cryptographic Attacks
    3.5. Unauthorized Usage
    3.6. Inappropriate Usage
    3.7. Denial of Service
    3.8. Communication security threats
4. Security Comparison between C/S and P2P
5. Security Analysis with P2P Layers
    5.1. Overlay Link Layer Security
    5.2. Forwarding and Link Management Layer Security
    5.3. Topology Plugin Security
    5.4. Storage Security
    5.5. Message Transport Security
    5.6. Usage Layer Security
6. Security Analysis with Application Scenarios
    6.1. Trusted P2P Overlay Base
    6.2. Untrusted P2P Overlay Base
7. Interconnection to other networks
    7.1. Connections to SIP networks
    7.2. Direct connections to the PSTN
8. Security considerations
    8.1. User security considerations
    8.2. System security considerations
        8.2.1. Dependence of reachability of a centralized server
        8.2.2. Scalability
        8.2.3. Preference of existing security mechanisms
        8.2.4. Base P2P security design considerations and guideline
        8.2.5. Node and user identification
        8.2.6. Enrollment
        8.2.7. Replay attacks
        8.2.8. Unauthorized data access
        8.2.9. Data validation
        8.2.10. Denial of Service (DOS) attacks
        8.2.11. Privacy Protection
        8.2.12. Badly behaving nodes
9. Security Considerations
10. IANA Considerations
11. Acknowledgments
12. Changes
    12.1. Revision 5
13. Normative References
§ Authors' Addresses

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] (Bryan, D., Matthews, P., Shim, E., Willis, D., and S. Dawkins, “Concepts and Terminology for Peer to Peer SIP,” July 2008.) . 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 (Bryan, D., “P2PSIP Protocol Framework and Requirements,” July 2007.) [I‑D.bryan‑p2psip‑requirements].

2. Terminology

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

3. Security threats

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:

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

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.

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.

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

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

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.

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.

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

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

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

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

5.4. Storage Security

The storage component 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 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 be changed when the overlay size changes?

5.6. Usage Layer Security

6. Security Analysis with Application Scenarios

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

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

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

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

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

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.

Care must be taken that the confidentiality, integrity and availability of this connection be maintained.

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:

8. Security considerations

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:

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

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.

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.

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.

10. IANA Considerations

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.

12. Changes

12.1. Revision 5

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:

[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 (TXT).
[I-D.bryan-p2psip-requirements]	Bryan, D., “P2PSIP Protocol Framework and Requirements,” draft-bryan-p2psip-requirements-00 (work in progress), July 2007 (TXT).
[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-08 (work in progress), March 2010 (TXT).
[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 (TXT).
[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-04 (work in progress), March 2010 (TXT).
[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 (TXT).
[I-D.zheng-p2psip-diagnose]	Yongchao, S. and X. Jiang, “Diagnose P2PSIP Overlay Network,” draft-zheng-p2psip-diagnose-04 (work in progress), December 2008 (TXT).
[RFC2119]	Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[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 (TXT).

	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/

P2PSIP Security Overview and Risk Analysisdraft-matuszewski-p2psip-security-requirements-05

Status of this Memo

Copyright Notice