P2PSIP Working Group M. Matuszewski Internet-Draft J-E. Ekberg Intended status: Informational P. Laitinen Expires: May 22, 2008 Nokia November 19, 2007 Security requirements in P2PSIP draft-matuszewski-p2psip-security-requirements-02.txt 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 22, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Matuszewski, et al. Expires May 22, 2008 [Page 1] Internet-Draft Security requirements in P2PSIP November 2007 Abstract This document presents main security requirements for the Peer-to- Peer SIP (P2PSIP) architecture and its components. This document also analyses security threats in P2PSIP. Typical security ontology is used as classification for the threats. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. P2PSIP network entity . . . . . . . . . . . . . . . . . . 4 2.3. P2PSIP system . . . . . . . . . . . . . . . . . . . . . . 4 3. Security threats . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Message Insertion, Modification, Deletion . . . . . . . . 6 3.3. Man-In-The-Middle . . . . . . . . . . . . . . . . . . . . 8 3.4. Offline Cryptographic Attacks . . . . . . . . . . . . . . 8 3.5. Unauthorized Usage . . . . . . . . . . . . . . . . . . . . 9 3.6. Inappropriate Usage . . . . . . . . . . . . . . . . . . . 9 3.7. Denial of Service . . . . . . . . . . . . . . . . . . . . 10 3.8. Communication security threats . . . . . . . . . . . . . . 10 4. Security requirements . . . . . . . . . . . . . . . . . . . . 12 4.1. User requirements . . . . . . . . . . . . . . . . . . . . 12 4.2. System requirements . . . . . . . . . . . . . . . . . . . 12 4.2.1. Dependence of reachability of a centralized server . . 12 4.2.2. Scalability . . . . . . . . . . . . . . . . . . . . . 12 4.2.3. Preference of existing security mechanisms . . . . . . 13 4.2.4. Requirements on a base P2P algorithm . . . . . . . . . 13 4.2.5. Node and user identification . . . . . . . . . . . . . 13 4.2.6. Enrollment . . . . . . . . . . . . . . . . . . . . . . 13 4.2.7. Replay attacks . . . . . . . . . . . . . . . . . . . . 14 4.2.8. Data access . . . . . . . . . . . . . . . . . . . . . 14 4.2.9. Data validation . . . . . . . . . . . . . . . . . . . 14 4.2.10. Denial of Service (DOS) attacks . . . . . . . . . . . 15 4.2.11. Privacy . . . . . . . . . . . . . . . . . . . . . . . 15 4.2.12. Detection and rejection of badly behaving nodes . . . 15 4.2.13. Summary of the system requirements . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 8. Normative References . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 23 Matuszewski, et al. Expires May 22, 2008 [Page 2] Internet-Draft Security requirements in P2PSIP November 2007 1. Introduction The scope of this document is to analyse security threats concerning a P2PSIP overlay architecture as described in the concepts and terminology for Peer-to-Peer SIP (P2PSIP) document [1] and list security requirements for the architecture and its components. This document does not intend to propose solutions to overcome security threats, but it is more intended to list the security requirements that must be addressed in P2PSIP specifications. This document complements the P2PSIP Protocol Framework and Requirements document [3]. Matuszewski, et al. Expires May 22, 2008 [Page 3] Internet-Draft Security requirements in P2PSIP November 2007 2. Definitions This section defines a number of concepts that are key to understand the rest of the document. 2.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 [2]. 2.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. 2.3. P2PSIP system A P2PSIP system consists of the P2PSIP overlay as defined in [1] and one or more enrolment servers. The enrolment 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 enrolment server may also provide an initial set of bootstrap nodes. Matuszewski, et al. Expires May 22, 2008 [Page 4] Internet-Draft Security requirements in P2PSIP November 2007 --->PSTN +------+ N +------+ +---------+ / | | A | | | Gateway |-/ | UA |####T#####| UA |#####| Peer |####### | Peer | N | Peer | | G | # P2PSIP | E | A | F | +---------+ # Client | | T | | # Protocol +------+ N +------+ # | # A # | NATNATNATNAT # | # # | \__/ NATNATNATNAT +-------+ v / \ # N | |=====/ UA \ +------+ A P2PSIP Overlay | | /Client\ | | T | Peer | |___C__| | UA | N Route Data | Q | ^ | Peer | A +-------+ | | D | T P2PSIP Peer Protocol # | | | N # | +------+ A # | # T # Enrolment | # N +-------+ +-------+ # protocol->| # A | | | | # | | #########T####| Proxy |########| Redir |###### v | N | Peer | | Peer |<----------\ | A | P | | R | v v T +-------+ +-------+ +-----------+ # Enrolment # # Server # \__/ <------------------------------> # # /\ +-----------+ / \ / UA \ /______\ SIP UA A A P2PSIP system Matuszewski, et al. Expires May 22, 2008 [Page 5] Internet-Draft Security requirements in P2PSIP November 2007 3. Security threats This section analyses security threats in the Peer-to-Peer SIP architecture. 3.1. Replay Attacks Replay attacks are a form of network attacks where a valid data transmission is repeated or delayed. A badly behaving node may take an older message sent by another node, resend it to the overlay, and thus replace any newer data with the old information present in this message. During those procedures, an attacker may be able to enroll credentials for himself, or replace existing entry in the P2PSIP overlay by an older entry. Thus, the architecture must consider this issue in the process of both enrollment and modification of P2PSIP resource (user) records in a P2PSIP overlay. This is especially applicable to P2PSIP overlays that use the recursive routing 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. 3.2. Message Insertion, Modification, Deletion The message insertion, modification, and deletion attacks are where an attacker is able to alter the messages being exchanged between two end points. P2PSIP peers connect to other peers to form the P2PSIP overlay network. Typically peers provide storage, routing and bootstrap services for other peers and clients. They allow P2PSIP entities to PUT information to or GET information from the P2PSIP overlay network. In the P2PSIP overlay that allows for a recursive routing, peers are responsible for forwarding messages (requests and responses) received from P2PSIP network entities to other peers. Depending on the size of the overlay a single message can be forwarded by many peers before it reaches a destination. In the iterative routing peers are responsible for redirecting the requests to other peers. They do not forward the requests to other peers. They respond to a request originator with an address of a peer that should be contacted in the next step. In such an environment a badly behaving peer may: o modify incoming messages, Matuszewski, et al. Expires May 22, 2008 [Page 6] Internet-Draft Security requirements in P2PSIP November 2007 o discard incoming messages (the peer can discard requests and responses it is supposed to forward), o generate incorrect responses to requests that are directed to some other nodes. The first bullet point describes the attack that allows the peer to cause the overlay to store unauthorized or outdated information in the resource (user) records or return corrupted data to the originator of the GET request (a peer or client). The peer may change the data record in the overlay by changing incoming PUT messages or modify result of the GET operation by modifying incoming GET responses. With this type of attack the integrity of the P2PSIP system can become compromised. The middle bullet point is related not only to attacks that allow a malicious peer to prevent access to a P2PSIP resource (user) record, but also to attacks that can degrade the performance of the P2PSIP system making it useless from the end-user perspective. The second problem is of high importance in P2PSIP overlays that store user's reachability data which is much more time-critical than content stored in file sharing networks. The attack described in the last bullet above may lead to a requestor receiving corrupted data e.g. a connectivity information that points to some other node. This may happen if a malicious peer can respond to incoming requests that are directed to another peer. Besides peers may act as relays relaying traffic between two P2PSIP network entities or act as a SIP proxy and a SIP registrar. Providing those services a malicious peer may perform a similar attacks as described above. Let us consider the following deployment scenario where some peers act as SIP registrars or/and SIP proxies and allow a conventional SIP UA to access resources of the P2PSIP overlay network. An unmodified SIP UA sends an SIP Invite request towards an unknown peer that acts as a SIP proxy. If the SIP messages are not cryptographically protected, this peer may act maliciously and proxy a request to other than intended node or modify SDP messages in order to stay on the media path. Similarly a peer that acts as a SIP Registrar may modify registration information before it sends it to a peer that is responsible for storing the P2PSIP user record of a registering SIP UA. Those attacks do not have impact on the integrity of the overlay. Nevertheless those attacks must be addressed by designers of service specific protocols such as SIP [4]. Matuszewski, et al. Expires May 22, 2008 [Page 7] Internet-Draft Security requirements in P2PSIP November 2007 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 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. 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. Matuszewski, et al. Expires May 22, 2008 [Page 8] Internet-Draft Security requirements in P2PSIP November 2007 3.5. Unauthorized Usage The basic notions of authentication and authorization, when implemented correctly and consistently SHOULD protect against unauthorized usage of the P2PSIP system. However, the trustworthiness of an identity may be weak i.e. the enrollment system might be fairly open and allow devices and persons that wish to attack the system. Thus, there is a significant threat of attacks from within the system. A malicious peer may do a multitude of attacks towards the overlay including: o ignoring, changing, and deleting records in DHT that is it responsible for, o misbehaving during data lookups (ie, giving wrong node addresses, discarding queries). The first bullet point is related to attacks that may cause DHT to contain unauthorized, outdated information and/or miss information about users or resources. Each peer is responsible for a part of the hash space. Peers store resource (user) records that fall into their part of the hash space. A malicious peer may modify or delete resource (user) records it is supposed to store. It may also reply with incorrect information to the GET requests addressed to resource (user) records it is responsible for. In addition it may ignore any record updates. These attacks are not limited to peers that are responsible for primary copies of resource (user) records. They are also related to peers that store replicas of resource (user) records. Besides a bootstrap node may also respond with wrong 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. 3.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) Matuszewski, et al. Expires May 22, 2008 [Page 9] Internet-Draft Security requirements in P2PSIP November 2007 records and perform inappropriate usage attacks. Besides the attacker may also update entries of other users or resources. The individual services provided by P2PSIP (messaging, real-time communication) have their respective threat models regarding inappropriate use (Spam, viruses, ...) but these can be considered out of scope for this document. 3.7. Denial of Service In the P2PSIP architecture [1], the P2PSIP resource (user) records are not maintained in a central, trustworthy storage system, rather they are distributed among peers participating in the system. Routing, relaying, SIP proxy and registrar services are also distributed among P2PSIP entities. In cases where authentication in the P2PSIP overlay is weak or where the system is fairly open to new participants the "infiltration" is trivial (e.g., Sybil attack). 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 that P2PSIP adds to that only in providing a means for the communication endpoints to Matuszewski, et al. Expires May 22, 2008 [Page 10] Internet-Draft Security requirements in P2PSIP November 2007 establish a shared key for further security needs. Otherwise, the communication security threats in that domain is out-of-scope for this discussion. Matuszewski, et al. Expires May 22, 2008 [Page 11] Internet-Draft Security requirements in P2PSIP November 2007 4. Security requirements This section describes requirements related to the security of a P2PSIP system. We divided the requirements into user requirements and system requirements. 4.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: o lookup and discovery of users and resources that is secure and reliable, o certainty of user and resource identity, o confidentiality and integrity of end-to-end multimedia communication, o easy and secure enrolment to the P2PSIP system, o privacy. 4.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. 4.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. 4.2.2. Scalability P2PSIP security SHOULD scale from a small ad-hoc network to a network with hundred millions of network nodes and users. Matuszewski, et al. Expires May 22, 2008 [Page 12] Internet-Draft Security requirements in P2PSIP November 2007 4.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. 4.2.4. Requirements on a base P2P algorithm All of 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. 4.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. 4.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 enrolment process policy may define: o how many and what user IDs and peer IDs an user or a P2PSIP network entity may register, o whether users are charged for the usage of the P2PSIP system, o and how often they must re-new their subscription to the P2PSIP system. As it was indicated in [3] the enrollment process may take several measures in admitting a user or a network node to the P2PSIP system, for example: Matuszewski, et al. Expires May 22, 2008 [Page 13] Internet-Draft Security requirements in P2PSIP November 2007 o may require strong identity such as employment or identity provided by a trusted 3rd party or by the P2PSIP service operator, o may charge for the enrollment, o may apply reputation mechanisms. Although the user probably is the entity that enrolls to the P2PSIP system, the credentials that are the result of the enrollment are used to grant a device the right to function as a peer, client or any other operative function possible in the system. Thus the security of enrollment also translates to the security of the device itself where the credentials are stored, and threats related to device security in general. 4.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. 4.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. 4.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. Matuszewski, et al. Expires May 22, 2008 [Page 14] Internet-Draft Security requirements in P2PSIP November 2007 4.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. 4.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. 4.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. Matuszewski, et al. Expires May 22, 2008 [Page 15] Internet-Draft Security requirements in P2PSIP November 2007 4.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. Matuszewski, et al. Expires May 22, 2008 [Page 16] Internet-Draft Security requirements in P2PSIP November 2007 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. Matuszewski, et al. Expires May 22, 2008 [Page 17] Internet-Draft Security requirements in P2PSIP November 2007 5. 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. Matuszewski, et al. Expires May 22, 2008 [Page 18] Internet-Draft Security requirements in P2PSIP November 2007 6. IANA Considerations There are no IANA considerations associated to this memo. Matuszewski, et al. Expires May 22, 2008 [Page 19] Internet-Draft Security requirements in P2PSIP November 2007 7. 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. Matuszewski, et al. Expires May 22, 2008 [Page 20] Internet-Draft Security requirements in P2PSIP November 2007 8. Normative References [1] Bryan, D., Matthews, P., Shim, P., and D. Willis, "Concepts and Terminology for Peer to Peer SIP", draft-ietf-p2psip-concepts-01.txt (work in progress), April 2007. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Bryan, D., Baset, S., Matuszewski, M., and H. Sinnreich, "P2PSIP Protocol Framework and Requirements", draft-bryan-p2psip-requirements-00.txt (work in progress), July 2007. [4] 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. Matuszewski, et al. Expires May 22, 2008 [Page 21] Internet-Draft Security requirements in P2PSIP November 2007 Authors' Addresses Marcin Matuszewski Nokia P.O.Box 407 NOKIA GROUP, FIN 00045 Finland Email: marcin.matuszewski@nokia.com Jan-Erik Ekberg Nokia P.O.Box 407 NOKIA GROUP, FIN 00045 Finland Email: jan-erik.ekberg@nokia.com Pekka Laitinen Nokia P.O.Box 407 NOKIA GROUP, FIN 00045 Finland Email: pekka.laitinen@nokia.com Matuszewski, et al. Expires May 22, 2008 [Page 22] Internet-Draft Security requirements in P2PSIP November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Matuszewski, et al. Expires May 22, 2008 [Page 23]