idnits 2.17.1 draft-matuszewski-p2psip-security-requirements-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 28, 2009) is 5323 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-26) exists of draft-ietf-p2psip-base-03 == Outdated reference: A later version (-09) exists of draft-ietf-p2psip-concepts-02 == Outdated reference: A later version (-22) exists of draft-ietf-p2psip-diagnostics-01 == Outdated reference: A later version (-21) exists of draft-ietf-p2psip-sip-01 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 P2PSIP Working Group H. Song 3 Internet-Draft Huawei 4 Intended status: Informational M. Matuszewski 5 Expires: April 1, 2010 Future Invest 6 D. York 7 Voxeo 8 September 28, 2009 10 P2PSIP Security Overview and Risk Analysis 11 draft-matuszewski-p2psip-security-requirements-06 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. This document may contain material 17 from IETF Documents or IETF Contributions published or made publicly 18 available before November 10, 2008. The person(s) controlling the 19 copyright in some of this material may not have granted the IETF 20 Trust the right to allow modifications of such material outside the 21 IETF Standards Process. Without obtaining an adequate license from 22 the person(s) controlling the copyright in such materials, this 23 document may not be modified outside the IETF Standards Process, and 24 derivative works of it may not be created outside the IETF Standards 25 Process, except to format it for publication as an RFC or to 26 translate it into languages other than English. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on April 1, 2010. 46 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 This document provides a security overview and analysis for the Peer- 60 to-Peer Session Initiation Protocol (P2PSIP) overlay network. It 61 discusses security threats for the P2PSIP architecture and its 62 components. It compares security difference between client/server 63 (C/S) and P2P implementations of SIP, and then partitions the P2PSIP 64 architecture into layers and analyzes the security issues in each 65 layer and the security relationship among the layers. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 3. Security threats . . . . . . . . . . . . . . . . . . . . . . . 7 72 3.1. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 7 73 3.2. Message Insertion, Modification, Deletion . . . . . . . . 7 74 3.3. Man-In-The-Middle . . . . . . . . . . . . . . . . . . . . 9 75 3.4. Offline Cryptographic Attacks . . . . . . . . . . . . . . 9 76 3.5. Unauthorized Usage . . . . . . . . . . . . . . . . . . . . 10 77 3.6. Inappropriate Usage . . . . . . . . . . . . . . . . . . . 10 78 3.7. Denial of Service . . . . . . . . . . . . . . . . . . . . 11 79 3.8. Communication security threats . . . . . . . . . . . . . . 11 80 4. Security Comparison between C/S and P2P . . . . . . . . . . . 13 81 5. Security Analysis with P2P Layers . . . . . . . . . . . . . . 15 82 5.1. Overlay Link Layer Security . . . . . . . . . . . . . . . 16 83 5.2. Forwarding and Link Management Layer Security . . . . . . 16 84 5.3. Topology Plugin Security . . . . . . . . . . . . . . . . . 17 85 5.4. Storage Security . . . . . . . . . . . . . . . . . . . . . 17 86 5.5. Message Transport Security . . . . . . . . . . . . . . . . 18 87 5.6. Usage Layer Security . . . . . . . . . . . . . . . . . . . 19 88 6. Security Analysis with Application Scenarios . . . . . . . . . 20 89 6.1. Trusted P2P Overlay Base . . . . . . . . . . . . . . . . . 20 90 6.2. Untrusted P2P Overlay Base . . . . . . . . . . . . . . . . 22 91 7. Interconnection to other networks . . . . . . . . . . . . . . 25 92 7.1. Connections to SIP networks . . . . . . . . . . . . . . . 25 93 7.2. Direct connections to the PSTN . . . . . . . . . . . . . . 26 94 8. Security considerations . . . . . . . . . . . . . . . . . . . 27 95 8.1. User security considerations . . . . . . . . . . . . . . . 27 96 8.2. System security considerations . . . . . . . . . . . . . . 27 97 8.2.1. Dependence of reachability of a centralized server . . 27 98 8.2.2. Scalability . . . . . . . . . . . . . . . . . . . . . 27 99 8.2.3. Preference of existing security mechanisms . . . . . . 27 100 8.2.4. Base P2P security design considerations and 101 guideline . . . . . . . . . . . . . . . . . . . . . . 28 102 8.2.5. Node and user identification . . . . . . . . . . . . . 28 103 8.2.6. Enrollment . . . . . . . . . . . . . . . . . . . . . . 28 104 8.2.7. Replay attacks . . . . . . . . . . . . . . . . . . . . 29 105 8.2.8. Unauthorized data access . . . . . . . . . . . . . . . 29 106 8.2.9. Data validation . . . . . . . . . . . . . . . . . . . 29 107 8.2.10. Denial of Service (DOS) attacks . . . . . . . . . . . 30 108 8.2.11. Privacy Protection . . . . . . . . . . . . . . . . . . 30 109 8.2.12. Badly behaving nodes . . . . . . . . . . . . . . . . . 30 110 9. Security Considerations . . . . . . . . . . . . . . . . . . . 31 111 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 112 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 113 12. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 114 12.1. Revision 5 . . . . . . . . . . . . . . . . . . . . . . . . 34 115 12.2. Revision 6 / Overview -00 . . . . . . . . . . . . . . . . 34 116 13. Normative References . . . . . . . . . . . . . . . . . . . . . 36 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 119 1. Introduction 121 The scope of this document is to analyze security threats concerning 122 a P2PSIP overlay architecture as described in the concepts and 123 terminology for P2PSIP document [I-D.ietf-p2psip-concepts] . It 124 presents an introduction to security threats to P2PSIP environments 125 and then compares security difference between client/server (C/S) and 126 P2P implementations of SIP, and then partitions the P2PSIP 127 architecture into layers and analyzes the security issues in each 128 layer and the security relationship among the layers. This draft 129 also classifies the application scenarios into two main types and 130 then analyzes in detail the security threats with these two types of 131 scenarios. Some solutions to certain attacks are given as an example 132 in the analysis text. In the end, it provides user and system 133 security considerations for the P2PSIP overlay network. This 134 document is designed to complement the P2PSIP Protocol Framework and 135 Requirements document [I-D.bryan-p2psip-requirements]. 137 2. Terminology 139 We use the terminology and definitions from the Concepts and 140 Terminology for Peer to Peer SIP [I-D.ietf-p2psip-concepts] draft 141 extensively in this document. Other terms used in this document are 142 defined inline when used and are also defined below for reference. 144 O P2PSIP Network Entity: A P2PSIP network entity is a peer, client, 145 or other functional node that may become a part of a P2PSIP overlay. 147 O P2PSIP System: A P2PSIP system consists of the P2PSIP overlay as 148 defined in [I-D.ietf-p2psip-concepts] and one or more enrollment 149 servers. The enrollment servers issue unique identities and 150 credentials that are used to authenticate and admit P2PSIP network 151 entities to the overlay and allow a user to use services provided by 152 the P2PSIP overlay. The enrollment server may also provide an 153 initial set of bootstrap nodes. 155 O P2P Overlay Base: A P2P Overlay Base includes all the Peers that 156 participate in the p2p overlay. The P2P Overlay Base provides 157 distributed storage and routing services to both peers and clients. 159 O Trusted P2P Overlay Base: All peers in a Trusted P2P Overlay Base 160 are trusted. The Peers in the overlay are all of good behaviors and 161 under control due to deployment. For example, a carrier deploys a 162 Trusted P2P Overlay Base to provide service to his customers, and all 163 the peers are the carrier's devices. 165 O Untrusted P2P Overlay Base: Peers in a Untrusted P2P Overlay Base 166 are not all trusted. There may exist some malicious behaving nodes 167 in the P2P Overlay Base. 169 3. Security threats 171 This section analyses security threats in the Peer-to-Peer SIP 172 architecture. 174 3.1. Replay Attacks 176 Replay attacks are a form of network attacks where a valid data 177 transmission is repeated or delayed. A badly behaving node may take 178 an older message sent by another node, resend it to the overlay, and 179 thus replace any newer data with the old information present in this 180 message. During those procedures, an attacker may be able to enroll 181 credentials for himself, or replace existing entry in the P2PSIP 182 overlay by an older entry. Thus, the architecture must consider this 183 issue in the process of both enrollment and modification of P2PSIP 184 resource (user) records in a P2PSIP overlay. 186 This is especially applicable to P2PSIP overlays that use the 187 recursive routing mode. In the recursive routing mode, data sent in 188 a PUT request traverses many peers in the overlay. If there is no 189 protection against the replay attacks any peer that forwards the 190 request may store a copy of the request and resend the captured 191 request corrupting data stored in the overlay. 193 3.2. Message Insertion, Modification, Deletion 195 The message insertion, modification, and deletion attacks are where 196 an attacker is able to alter the messages being exchanged between two 197 end points. 199 P2PSIP peers connect to other peers to form the P2PSIP overlay 200 network. Typically peers provide storage, routing and bootstrap 201 services for other peers and clients. They allow P2PSIP entities to 202 PUT information to or GET information from the P2PSIP overlay 203 network. In the P2PSIP overlay that allows for a recursive routing, 204 peers are responsible for forwarding messages (requests and 205 responses) received from P2PSIP network entities to other peers. 206 Depending on the size of the overlay a single message can be 207 forwarded by many peers before it reaches a destination. In the 208 iterative routing peers are responsible for redirecting the requests 209 to other peers. They do not forward the requests to other peers. 210 They respond to a request originator with an address of a peer that 211 should be contacted in the next step. In such an environment a badly 212 behaving peer may: 214 o modify incoming messages, 215 o discard incoming messages (the peer can discard requests and 216 responses it is supposed to forward), 218 o generate incorrect responses to requests that are directed to some 219 other nodes. 221 The first bullet point describes the attack that allows the peer to 222 cause the overlay to store unauthorized or outdated information in 223 the resource (user) records or return corrupted data to the 224 originator of the GET request (a peer or client). The peer may 225 change the data record in the overlay by changing incoming PUT 226 messages or modify result of the GET operation by modifying incoming 227 GET responses. With this type of attack the integrity of the P2PSIP 228 system can become compromised. 230 The middle bullet point is related not only to attacks that allow a 231 malicious peer to prevent access to a P2PSIP resource (user) record, 232 but also to attacks that can degrade the performance of the P2PSIP 233 system making it useless from the end-user perspective. The second 234 problem is of high importance in P2PSIP overlays that store user's 235 reachability data which is much more time-critical than content 236 stored in file sharing networks. 238 The attack described in the last bullet above may lead to a requestor 239 receiving corrupted data e.g. a connectivity information that points 240 to some other node. This may happen if a malicious peer can respond 241 to incoming requests that are directed to another peer. 243 Besides peers may act as relays relaying traffic between two P2PSIP 244 network entities or act as a SIP proxy and a SIP registrar. 245 Providing those services a malicious peer may perform a similar 246 attacks as described above. Let us consider the following deployment 247 scenario where some peers act as SIP registrars or/and SIP proxies 248 and allow a conventional SIP UA to access resources of the P2PSIP 249 overlay network. An unmodified SIP UA sends an SIP Invite request 250 towards an unknown peer that acts as a SIP proxy. If the SIP 251 messages are not cryptographically protected, this peer may act 252 maliciously and proxy a request to other than intended node or modify 253 SDP messages in order to stay on the media path. Similarly a peer 254 that acts as a SIP Registrar may modify registration information 255 before it sends it to a peer that is responsible for storing the 256 P2PSIP user record of a registering SIP UA. Those attacks do not 257 have impact on the integrity of the overlay. Nevertheless those 258 attacks must be addressed by designers of service specific protocols 259 such as SIP [RFC3261]. 261 3.3. Man-In-The-Middle 263 In man-in-the-middle (m-i-m) attacks a malicious node can hijack a 264 connection established between two legitimate nodes, or just listen 265 and/or modify messages exchanged between two nodes. In contrast to 266 the attacks presented in Section 13.2 man-in-the middle attacks are 267 prevalent in pairing and authentication procedures. 269 The m-i-m threat can be mitigated by using well-established 270 authentication protocols. The authentication protocols may be used 271 to verify if a certain P2PSIP entity is the entity it claims to be, 272 for example if it is really a peer that is identified by a certain 273 peer ID. The authentication protocols can also be used to verify if 274 a particular P2PSIP entity belongs to a particular overlay or not. 275 However, authentication protocols cannot fully mitigate all of the 276 attacks presented in Section 13.2. There can be malicious peers that 277 are authorized overlay participants with a particular peer 278 identifiers. 280 If a bootstrap process is fully decentralized and a bootstrap node is 281 not trusted or authentication of the bootstrap node is not possible, 282 then the joining node can easily be attacked, e.g. it may be 283 redirected to another overlay or a part of the legacy overlay that is 284 controlled by the attacker. However if it is possible to 285 authenticate a particular peer in the overlay the joining peer may 286 use P2P specific mechanisms to detect if it is redirected to the 287 right overlay or the right place in the overlay. 289 Conventional SIP proxy and SIP registrars are servers maintained by a 290 service provider. If a user trust a service provider he also trusts 291 servers the service provider maintains. In P2PSIP SIP proxies and 292 registrars can be maintained by users themselves (they can be 293 collocated with peers). In a distributed environment it is very 294 difficult to trust all of peers in the overlay. Without an efficient 295 verification mechanism that allows to verify which peers are be 296 trusted, peers that act as SIP proxies and registrars may easily 297 perform m-i-m attacks. The problem must be solved by SIP designers 298 as well as by the P2PSIP community. 300 3.4. Offline Cryptographic Attacks 302 The incentive to break a secure system dominates the effort to do so. 303 It is likely that P2PSIP systems do not pose a likely target for 304 attacks, and if state-of-the art security methods are used, the 305 needed effort to break the system by breaking cryptography is very 306 likely to be higher than by finding and exploiting software errors 307 and vulnerabilities. 309 3.5. Unauthorized Usage 311 The basic notions of authentication and authorization, when 312 implemented correctly and consistently should protect against 313 unauthorized usage of the P2PSIP system. However, the 314 trustworthiness of an identity may be weak i.e. the enrollment system 315 might be fairly open and allow devices and persons that wish to 316 attack the system. Thus, there is a significant threat of attacks 317 from within the system. 319 A malicious peer may do a multitude of attacks towards the overlay 320 including: 322 o ignoring, changing, and deleting records in DHT that is it 323 responsible for, 325 o misbehaving during data lookups (ie, giving wrong node addresses, 326 discarding queries). 328 The first bullet point is related to attacks that may cause DHT to 329 contain unauthorized, outdated information and/or miss information 330 about users or resources. Each peer is responsible for a part of the 331 hash space. Peers store resource (user) records that fall into their 332 part of the hash space. A malicious peer may modify or delete 333 resource (user) records it is supposed to store. It may also reply 334 with incorrect information to the GET requests addressed to resource 335 (user) records it is responsible for. In addition it may ignore any 336 record updates. These attacks are not limited to peers that are 337 responsible for primary copies of resource (user) records. They are 338 also related to peers that store replicas of resource (user) records. 339 Besides a bootstrap node may also respond with wrong bootstrapping 340 information. 342 The second bullet point addresses attacks that may impact correctness 343 of routing mechanisms. If the recursive routing is used a malicious 344 peer can forward messages to another malicious node rather than 345 forwarding the messages according to the legitimate routing 346 information. This may also impact the iterative routing being 347 corrupted when the peer redirects the requester to a malicious node. 349 3.6. Inappropriate Usage 351 The P2PSIP overlay essentially provides a distributed storage for 352 P2PSIP resource (user) records. The data stored in the distributed 353 database can be used in an inappropriate manner. If there is no 354 access control to a resource (user) records stored in the overlay and 355 any node can update or retrieve information stored in the overlay. 356 An attacker may request data stored in the P2PSIP resource (user) 357 records and perform inappropriate usage attacks. Besides the 358 attacker may also update entries of other users or resources. 360 The individual services provided by P2PSIP (messaging, real-time 361 communication) have their respective threat models regarding 362 inappropriate use (Spam, viruses, ...) but these can be considered 363 out of scope for this document. 365 3.7. Denial of Service 367 In the P2PSIP architecture [I-D.ietf-p2psip-concepts], the P2PSIP 368 resource (user) records are not maintained in a central, trustworthy 369 storage system, rather they are distributed among peers participating 370 in the system. Routing, relaying, SIP proxy and registrar services 371 are also distributed among P2PSIP entities. In cases where 372 authentication in the P2PSIP overlay is weak or where the system is 373 fairly open to new participants the "infiltration" is trivial (e.g., 374 Sybil attack). 376 If peers in the P2PSIP overlay can freely choose peer IDs or/and 377 easily modify previously selected peer IDs the attacker may use join- 378 leave attacks to place a malicious peer intentionally at any location 379 in overlay. Placing the peer at any location allows an attacker to 380 obtain control of the location in the overlay where the attacked user 381 or resource is registered. A malicious peer may discard, modify the 382 data it is supposed to store and may discard lookup requests or reply 383 with incorrect entries to the incoming requests. 385 The attacker may also try to register a large number of resources to 386 the P2PSIP overlay increasing processing load on peers that are 387 responsible for storing the resources and limiting the overall 388 capacity of the P2PSIP overlay network. It may also try to register 389 all popular names preventing the name holders from registering their 390 preferred URIs. 392 Another critical point where a D-o-S attack can be mounted is the 393 enrollment system. 395 3.8. Communication security threats 397 The main places where communication security becomes an issue in the 398 P2PSIP context is the enrollment process and the communication 399 between endpoints. The last ones are subject to all typical threats 400 in this domain, however they have been individually considered in the 401 earlier sections of this chapter. 403 This document assumes that the actual SIP service implementation 404 provides its own communication security, and the P2PSIP adds to that 405 only in providing a means for the communication endpoints to 406 establish a shared key for further security needs. Otherwise, the 407 communication security threats in that domain is out-of-scope for 408 this discussion. 410 4. Security Comparison between C/S and P2P 412 In a Client Server(C/S) architecture, a client asks for a specific 413 service only from a specific server. The destination contact 414 address(i.e. the address of that server) can be acquired from the 415 trusted DNS system directly. Given this, the security issues exist 416 only with the connection between the client and the server. 417 Typically, making the connection secure between the client and the 418 server addresses most of the security issues related to the client. 420 However, in a P2P architecture the security issues are more complex. 422 First, where in a C/S architecture specific servers provide certain 423 services, in a P2P architecture, each peer in the P2P overlay can 424 provide distributed storage and transport services for other P2P 425 entities. There is also no hierarchy of servers but instead the 426 peers self-organize into the P2P overlay. 428 Second, where in a C/S architecture a client sends its request 429 directly to a server, in a P2P architecture a peer sends messages 430 through Key-Based-Routing and it doesn't know where the destination 431 is. There are intermediate nodes between the source and destination. 433 Third, where in a C/S architecture the client can trust the 434 information from the server, in a P2P architecture, one peer does not 435 know whether it should trust the information acquired from the 436 overlay. 438 So in a P2P architecture, security issues not only exist between end 439 to end entities, but also between hop by hop services. They are not 440 only related to the routing security, but also related to the content 441 security. 443 +------------+----------------------+--------------------------+ 444 | | | | 445 | | C/S | P2P | 446 +------------+----------------------+--------------------------+ 447 | | | | 448 | transport | authenticate between | authentication between | 449 | | client and server | P2PSIP network entities | 450 | | | | 451 +------------+----------------------+--------------------------+ 452 | |need one hop security;| need hop by hop security| 453 | routing |transport layer | to ensure the end to end| 454 | |security can ensure it| security | 455 +------------+----------------------+--------------------------+ 456 | | | responsible peer may not | 457 | storage | server is trusted for| trusted, need for resource| 458 | | storage | data management security | 459 +------------+----------------------+--------------------------+ 460 | | | | 461 | application| out of scope of this| out of scope of this | 462 | | specification | specification | 463 | | | | 464 +------------+----------------------+--------------------------+ 466 Figure 1 Comparison between C/S and P2P security 468 5. Security Analysis with P2P Layers 470 The overall security of a P2PSIP system depends upon the security of 471 each layer of the P2PSIP architecture. In this section we split the 472 P2PSIP architecture into four main layers, as shown in the following 473 figure, and analyze the security issues from the P2PSIP architecture 474 perspective. 476 Application 478 +-------+ +-------+ 479 | SIP | | XMPP | ... 480 | Usage | | Usage | 481 +-------+ +-------+ 482 -------------------------------------- Messaging API 483 +------------------+ +---------+ 484 | Message |<--->| Storage | 485 | Transport | +---------+ 486 +------------------+ ^ 487 ^ ^ | 488 | v v 489 | +-------------------+ 490 | | Topology | 491 | | Plugin | 492 | +-------------------+ 493 | ^ 494 v v 495 +------------------+ 496 | Forwarding & | 497 | Link Management | 498 +------------------+ 499 -------------------------------------- Overlay Link API 500 +-------+ +------+ 501 |TLS | |DTLS | ... 502 +-------+ +------+ 504 Figure 2 P2PSIP architecture 506 The major components of RELOAD are: 508 Usage Layer: Each application defines a RELOAD usage; a set of 509 data kinds and behaviors which describe how to use the services 510 provided by RELOAD. These usages all talk to RELOAD through a 511 common Message Transport API. 513 Message Transport: Handles the end-to-end reliability, manages 514 request state for the usages, and forwards Store and Fetch 515 operations to the Storage component. Delivers message responses 516 to the component initiating the request. 518 Storage: The Storage component is responsible for processing 519 messages relating to the storage and retrieval of data. It talks 520 directly to the Topology Plugin to manage data replication and 521 migration, and it talks to the Message Transport to send and 522 receive messages. 524 Topology Plugin: The Topology Plugin is responsible for 525 implementing the specific overlay algorithm being used. It uses 526 the Message Transport component to send and receive overlay 527 management messages, to the Storage component to manage data 528 replication, and directly to the Forwarding Layer to control hop- 529 by-hop message forwarding. This component closely parallels 530 conventional routing algorithms, but is more tightly coupled to 531 the Forwarding Layer because there is no single "routing table" 532 equivalent used by all overlay algorithms. 534 Forwarding and Link Management Layer: Stores and implements the 535 routing table by providing packet forwarding services between 536 nodes. It also handles establishing new links between nodes, 537 including setting up connections across NATs using ICE. 539 Overlay Link Layer: TLS and DTLS are the "link layer" protocols 540 used by RELOAD for hop-by-hop communication. Each such protocol 541 includes the appropriate provisions for per-hop framing or hop-by- 542 hop ACKs required by unreliable transports. 544 5.1. Overlay Link Layer Security 546 Given that a P2PSIP overlay can run on top of the Internet or other 547 untrusted network, messages between associated nodes should be 548 protected against attacks(such as Man-in-the-Middle). In order to 549 establish the identity trust association, nodes must authenticate 550 each other with e.g. TLS and DTLS. If transport service security is 551 provided, we can prevent nodes without valid identities to 552 participate in the overlay. This layer must provides reliable and 553 secure hop-by-hop transport service for the P2P overlay. This alone, 554 though, is not enough to secure the P2P system. 556 5.2. Forwarding and Link Management Layer Security 558 Each Peer in the P2PSIP overlay provides key-based routing service to 559 other peers and a routing maintenance mechanism is used to keep the 560 routing table timely and correct for the routing service. There are 561 some security threats with the routing table updating interaction and 562 the key-based routing. 564 Even if all the nodes participating in the P2PSIP overlay have valid 565 identities, the overlay may still be attacked by responding with fake 566 routing table to UPDATE requests. If the routing table is false, the 567 routing determination based on it will be false too. So, 568 verification mechanisms should be adopted to verify if the routing 569 table received by the peer correct or not. A correct routing table 570 is important for hop by hop forwarding security. 572 Second, some attackers may discard the messages when forwarding, or 573 on purpose forward the message to a wrong next hop. The overlay 574 should include some method to detect incorrectly forwarded messages. 576 Third, some attacks may cause high churn rate to the overlay. For 577 example, some peers may frequently join and leave the overlay. 578 Overlay wastes much more traffic to update the routing table, and 579 transfer relative resource objects under churn. It can also make the 580 routing messages fail. 582 In this case, we need a method to control nodes joining the overlay. 583 The join control entity, which may be a bootstrap server or 584 enrollment server, or a bootstrap peer, makes records of peers' 585 historical behaviors in the overlay and their historical join 586 requests. When it receives the join request from a peer to join the 587 overlay, it checks the historical records as mentioned above to 588 determine whether this peer is permitted to join at this point. It 589 will deny the node to join the overlay when it determines the peer is 590 not permitted to join. For example, if a peer joins and leaves too 591 frequently, it will be denied to join the overlay as a peer for a 592 period of time and instead it will be allowed to join the overlay as 593 a client. 595 Chosen-ID attack makes the above security issues much more worse. 597 In general, the main security issues in this layer are about routing 598 table maintenance security, and the the KBR function security. 600 5.3. Topology Plugin Security 602 The security issues with with this component are rather p2p algorithm 603 specific. 605 5.4. Storage Security 607 The storage component provides distributed storage service for the 608 resource objects that located in one's responsible resource ID range, 609 and the replication service to keep the availability of resource 610 objects under churn. The security issues here are typically end to 611 end, and about the content and authority security. 613 First, We need to protect resource objects when needed against 614 unauthorized data operation such as fetch, modify or remove. A 615 solution for authorization is needed. 617 Second, The P2PSIP overlay needs a method to prevent attackers from 618 publishing malicious information that will cause a DDOS attack. For 619 example, Peer A may publish a very popular resource record with the 620 contact address of Peer B without B's permission. That causes 621 unexpected connections to B which will overload Peer B. Using 622 certificates can't solve this problem, a check mechanism for the 623 resource object is needed. 625 Third, overlays work well for a reasonable amount of resource 626 objects, but crash more or less when inserting big number of resource 627 objects per node. Spam attacks can make overlays go down. Open 628 issue: Should spam attack be considered in the storage layer? Or is 629 it only the responsibility of the application layer to handle this 630 problem? 632 Fourth, for the availability of the resource records in the overlay 633 network, replication is needed, but attackers can replicate excessive 634 amount of resources in the overlay network. So, only authorized 635 peers can replicate certain resources, and the number of resources 636 one can replicate is limited. 638 5.5. Message Transport Security 640 Some attacker who is not responsible for the destination ID may 641 respond to some requests when he is in the intermediate routing 642 path(May respond with a fabricated resource object or just says that 643 the searched resource object doesn't exist). Should the source node 644 verify whether the response peer is responsible for the request? 645 When and how does the source peer do that? Whether the response peer 646 is responsible for the request is important for the end to end 647 message transport security. 649 Another security issue in this layer is about the message state 650 maintenance. The timeout value for the end to end message transport 651 must be chosen appropriately, because too short timeout value will 652 cause the overlay be flooded with messages since the initiator will 653 send the request again before the response is received. And too long 654 timeout value will not satisfy the requirement for communication 655 efficiency when routing failures occur. An open issue here is: How 656 to derive the appropriate timeout value and should the timeout value 657 be changed when the overlay size changes? 659 5.6. Usage Layer Security 661 The SIP usage security analysis is briefly discussed in the Security 662 Considerations section of [I-D.ietf-p2psip-sip]. 664 6. Security Analysis with Application Scenarios 666 As mentioned in the security considerations section in the 667 application scenarios draft [I-D.bryan-p2psip-app-scenarios], the 668 security requirements of the various application scenarios vary 669 tremendously. So in this section, we divide the application 670 scenarios into two main types, instead of analyzing all the security 671 threats with each specific scenario described in the application 672 scenarios draft, we just analyze the relative security threats of 673 these two types, which represent most of the likely deployment 674 scenarios in the real world. For example, the "Public P2P VoIP 675 Service Providers" scenario in section 4.1.1 of application scenarios 676 draft may be deployed using the first type(refer to section 6.1 of 677 this specification), and the "Open Global P2P VoIP Network" scenario 678 in section 4.1.2 of application scenarios draft may be deployed using 679 the second type(refer to section 6.2 of this specification). 681 6.1. Trusted P2P Overlay Base 683 In a trusted P2P Overlay Base, all the peers are deemed to be 684 trustworthy and are assumed to behave in a good manner. They may be 685 deployed to provide reliable and high quality services, and may also 686 do some management services for the overlay. All P2PSIP clients 687 access the overlay service through an associated trusted peer, as 688 shown in figure 3. 690 +---------+ +---------+ 691 | Trusted +---------------+ Trusted | 692 | Peer | | Peer | 693 +---+-----+ +----+----+ 694 | | 695 | | 696 | | 697 | | 698 | P2PSIP Peer Protocol | 699 +---+-----+ (RELOAD) +----+----+ 700 | Trusted +---------------+ Trusted | 701 | Peer | | Peer | 702 +---+-----+ +----+----+ 703 | | 704 P2PSIP Peer P2PSIP Peer 705 Protocol(RELOAD) Protocol(RELOAD) 706 +---+-----+ +----+----+ 707 | | | | 708 |Client | | Client | 709 +---------+ +---------+ 711 Figure 3 Trusted P2P Overlay Base 713 In these scenarios, we regard the P2P Overlay Base to be secure. The 714 security issues to be considered are the transport security between 715 trusted peers and the security issues associated with clients. 716 Security issues also focus on distributed storage layer. 718 +--------------------+-----------------------+---------------------+ 719 | Possible Attacks | Descriptions | Considerations | 720 |--------------------+-----------------------+---------------------+ 721 | | 1.Message Privacy | TLS and DTLS | 722 | Transport Related | 2.ID hijack | | 723 +--------------------+-----------------------+---------------------+ 724 |Unauthorized Data | Unauthorized Access, | Certificate | 725 |Operation | Modification, Removing| Mechanism | 726 +--------------------+-----------------------+---------------------+ 727 | | In the progress of | | 728 | Man In the Middle | Authentication between| Authentication | 729 | | client and its | Security | 730 | | associated peer | | 731 +--------------------+-----------------------+---------------------+ 732 | | | | 733 | data pollution and |1.Publish Fake Resource| 1.Check Mechanism? | 734 | poison | Objects | | 735 | |2.Publish malicious | 2.Black List? | 736 | | contact information | | 737 | | (DDOS attack) | | 738 +--------------------+-----------------------+---------------------+ 739 | | | | 740 | Spam Attack | Publish lots of | 1. Check Mechanism? | 741 | | redundant resources | 2. Limit one's | 742 | | | publication number | 743 | | | per time unit | 744 +--------------------+-----------------------+---------------------+ 746 Figure 4 Possible Attacks on Trusted Overlay Base Scenarios 748 6.2. Untrusted P2P Overlay Base 750 In an untrusted P2P Overlay Base, there are peers who are not trusted 751 by other peers. Some of the untrusted peers may do harmful things or 752 abnormal behaviors to the overlay due to malicious or unknown 753 intentions. There may be trusted peers in the overlay, as Shown in 754 Figure 5. 756 +---------+ +---------+ 757 |Untrusted+---------------+ Trusted | 758 | Peer | | Peer | 759 +---+-----+ +----+----+ 760 | | 761 | | 762 | | 763 | | 764 | P2PSIP Peer Protocol | 765 +---+-----+ (RELOAD) +----+----+ 766 | Trusted +---------------+Untrusted| 767 | Peer | | Peer | 768 +---+-----+ +----+----+ 769 | | 770 P2PSIP Peer P2PSIP Peer 771 Protocol(RELOAD) Protocol(RELOAD) 772 +---+-----+ +----+----+ 773 | | | | 774 |Client | | Client | 775 +---------+ +---------+ 777 Figure 5 Untrusted P2P Overlay Base 779 In these scenarios, the security threats with the Trusted P2P Overlay 780 Base still exist. However there are many additional security threats 781 because there may exist malicious peers in these networks. Each 782 layer of the P2PSIP architecture and the enrollment may be attacked. 783 The attacks beyond those in the Trusted Overlay Base scenarios are 784 listed in Figure 6. 786 +--------------------+-----------------------+---------------------+ 787 | Possible Attacks | Descriptions | Considerations | 788 |--------------------+-----------------------+---------------------+ 789 | |1.Chosen-ID attack | 1.Enrollment Server | 790 | Identity Attack |2.Sybil Attack | | 791 | |3.Fabricated response | 2.A proof mechanism | 792 | | from the intermediate| to verify whether it| 793 | | peer | is a true root? | 794 +--------------------+-----------------------+---------------------+ 795 | |1.discard messages | 1.message signature?| 796 | Forwarding Attack |2.Forwarding to a wrong| 2.A diagnosis | 797 | |next hop node | mechanism for | 798 | |3.modify messages when | detecting which | 799 | |forwarding | intermediate peer is| 800 | | | a bad man? | 801 +--------------------+-----------------------+---------------------+ 802 | | Intermediate peer | | 803 | Replay Attack | stores messages and |Timestamp to | 804 | | replays |recognize timed | 805 | | |messages? | 806 +--------------------+-----------------------+---------------------+ 807 | | give malicious | | 808 | Routing Table | response info to an |Per DHT specific? | 809 | Attack | updating routing table| | 810 | | request | | 811 +--------------------+-----------------------+---------------------+ 813 Figure 6 Possible Attacks on Untrusted Overlay Base Scenarios,not 814 covered by Figure 4 816 As for these security issues, the P2PSIP diagnostics draft 817 [I-D.ietf-p2psip-diagnostics] provides a framework using diagnostic 818 methods to diagnose some of the problems in the P2PSIP overlay. 820 7. Interconnection to other networks 822 While some P2PSIP systems may exist that only allow communication 823 between P2PSIP peers within the system, other P2PSIP systems may have 824 connections to other networks such as the traditional Public Switched 825 Telephone Network (PSTN) or newer SIP-based networks. 827 For example, a P2PSIP system might be deployed within a branch office 828 with a connection from the P2PSIP system going back to a SIP-based 829 communication network in a main corporate office. Alternatively, a 830 small office might deploy a P2PSIP system and then have some gateway 831 to the PSTN for external communication. 833 In examples such as these, care must be taken to ensure the security 834 of communication to those external networks. Note that the level of 835 concern may vary depending upon whether the P2PSIP overlay base is 836 trusted or untrusted, as discussed in the previous section. 838 7.1. Connections to SIP networks 840 A common scenario may be for a P2PSIP system to be connected to 841 another SIP network. This could be to a main corporate network as 842 described earlier, or it could be to a SIP-based Service Provider who 843 would then provide inbound and / or outbound connectivity to the 844 PSTN. It could also be to an on-premise device such as an IP-PBX or 845 SIP application server that would provide connectivity to other 846 networks. 848 Important considerations here include: 850 o How is the P2PSIP overlay network connected to the SIP network? 851 Is it through a single designated peer? Is it through multiple 852 peers? 854 o How is the availability of the connection to the SIP network 855 preserved? 857 o How susceptible to Denial of Service attacks is the connection? 859 o How are the authentication credentials for the SIP connection 860 protected? 862 o What kind of transport security is deployed for the connection? 864 o How are firewall traversal issues addressed? 866 Care must be taken that the confidentiality, integrity and 867 availability of this connection be maintained. 869 7.2. Direct connections to the PSTN 871 While some P2PSIP systems may choose to connect to SIP-based Service 872 Providers to achieve PSTN connectivity, others might opt for direct 873 connectivity to the PSTN through local gateways such as hardware 874 cards. For instance, a small office might have a PC or other device 875 with a hardware card that provided connectivity to a traditional 876 analog line to the PSTN. Similarly, a desk phone may be created with 877 both an IP connection and an analog line connection. 879 In these cases, one or more of the P2PSIP Peers may have these 880 devices installed and may then advertise these resources as being 881 available. Important considerations here include: 883 o How is the availability of the Peer(s) providing the PSTN gateway? 885 o Are there protections in place to ensure that routing tables 886 aren't manipulated so that other Peers cannot find the gateways? 888 8. Security considerations 890 This section describes aspects of security considerations in a P2PSIP 891 system. 893 8.1. User security considerations 895 The user wants available and reliable service that enables him to 896 interact with other users and resources in a secure way. This means 897 that the P2PSIP system must provide: 899 o lookup and discovery of users and resources that is secure and 900 reliable, 902 o certainty of user and resource identity, 904 o confidentiality and integrity of end-to-end multimedia 905 communication, 907 o easy and secure enrollment to the P2PSIP system, 909 8.2. System security considerations 911 In order for a P2PSIP system to function properly and that the end 912 user gets a proper service, there are several aspects that the P2PSIP 913 system must take in to account. 915 8.2.1. Dependence of reachability of a centralized server 917 Considering the nature of P2P in general, the dependence of 918 reachability of a centralized server should be minimized. There may 919 be unavoidable situations such as the enrollment process, where this 920 is not possible. However, the normal functioning of the P2PSIP 921 overlay such as join and leave operations, modification, retrieval 922 and deletion of P2PSIP resource (user) records from the P2PSIP system 923 should not depend on the reachability of a centralised server. 925 8.2.2. Scalability 927 P2PSIP security should scale from a small ad-hoc network to a network 928 with hundred millions of network nodes and users. 930 8.2.3. Preference of existing security mechanisms 932 Although P2PSIP defines a new architecture, and thereby new 933 interfaces and protocols, for security there are several standardized 934 solutions for access control, authentication, integrity protection 935 and communication security. Using established protocols minimizes 936 potential security loopholes that need to be patched later. Besides 937 implementation is easier if chosen security protocols are widely 938 implemented and used. 940 8.2.4. Base P2P security design considerations and guideline 942 All of the security operations should be specified in such a way that 943 they do not impose new unnecessary requirements on a base P2P 944 algorithm (e.g., DHT implementations) and limit its scalability. The 945 security issues that are not introduced by the P2P algorithm must not 946 be left to the P2P algorithm to solve. 948 A P2PSIP system should provide methods to support various level of 949 security provisioning. Security requirements in P2P systems can be 950 different, depending on level of trust in the central entities and 951 connectivity to the global Internet. Security operations should be 952 specified in a manner that they do not overload base P2P algorithms 953 (e.g. DHT implementations). Security risks, not covered by these, 954 should be further investigated in research projects. 956 8.2.5. Node and user identification 958 The P2PSIP system must preserve user and resource identities. It 959 must NOT be possible to steal a P2PSIP identity from another user. 961 Because some attackers may try to use identities of another P2PSIP 962 network entities it should be possible to verify the identity of 963 another party. 965 8.2.6. Enrollment 967 The enrollment process defines the set of users and P2PSIP network 968 entities that may participate in a P2PSIP system. Each P2PSIP system 969 may establish its own policy for who can join the system. The 970 enrollment process policy may define: 972 o how many and what user IDs and peer IDs a user or a P2PSIP network 973 entity may register, 975 o and how often they must re-new their subscription to the P2PSIP 976 system. 978 As it was indicated in [I-D.bryan-p2psip-requirements] the enrollment 979 process may take several measures in admitting a user or a network 980 node to the P2PSIP system to increase security: 982 o may require strong identity such as employment or identity 983 provided by a trusted 3rd party or by the P2PSIP service operator, 985 o may apply reputation mechanisms. 987 Although the user probably is the entity that enrolls to the P2PSIP 988 system, the credentials that are the result of the enrollment are 989 used to grant a device the right to function as a peer, client or any 990 other operative function possible in the system. Thus the security 991 of enrollment also translates to the security of the device itself 992 where the credentials are stored, and threats related to device 993 security in general. 995 8.2.7. Replay attacks 997 An attacker should not be able to repeat or delay valid data 998 transmission during enrollment and modification of P2PSIP resource 999 (user) records in a P2PSIP overlay. 1001 8.2.8. Unauthorized data access 1003 An attacker must NOT be able to easily corrupt, delete, or overwrite 1004 other user's or resource's data stored in P2PSIP resource (user) 1005 records as well as routing tables. Only authorized users must be 1006 able to modify, delete or overwrite their P2PSIP resource (user) 1007 records in the P2PSIP system. P2PSIP security should allow users and 1008 P2PSIP network entities to register the same resources (e.g. 1009 TURN@overlay.net), however each entity should have rights only to its 1010 own part of a resource record. In other words each entity should be 1011 able to perform the same operations on its part of a resource record 1012 as on its own resource (user) records. 1014 The owner of the P2PSIP resource (user) records should be able to 1015 authorize other users and network entities to modify, delete their 1016 P2PSIP resource (user) records. 1018 8.2.9. Data validation 1020 First and foremost it must be possible to verify that the data stored 1021 in or retrieved from the P2PSIP overlay is authentic, i.e. was not 1022 tampered by unauthorized P2PSIP network entities. 1024 The peer that stores P2PSIP resource (user) records must be able to 1025 validate the data received in the process of P2PSIP resource (user) 1026 record insertion and modification. 1028 8.2.10. Denial of Service (DOS) attacks 1030 It must NOT be possible to obtain control of the location in the 1031 overlay where the attacked user's or resource's records are 1032 registered. In order to prevent so-called Sybil or join-leave 1033 attacks the attacker should NOT be able to easily register a 1034 unlimited number of IDs of his choice in the P2SIP overlay. The 1035 P2PSIP system should be able to control ID assignment. Once 1036 assigned, an ID or a set of IDs should be difficult to change. 1038 In addition the P2PSIP architecture should make sure that data stored 1039 in a P2PSIP overlay is persistent, meaning that even if a number of 1040 nodes (but not all of nodes in the overlay) fails the data stored by 1041 those nodes is not lost. In addition the attacker must NOT be able 1042 to register unlimited number of resources in the overlay. 1044 8.2.11. Privacy Protection 1046 The security of P2PSIP systems must guarantee privacy of the P2PSIP 1047 network participants. The P2PSIP security should allow the users and 1048 P2PSIP network entities to indicate which other users or P2PSIP 1049 network entities can retrieve, modify, and delete data stored in 1050 their P2PSIP resource (user) records. The owner of a P2PSIP resource 1051 (user) record should be able to limit the access to his own resource 1052 (user) records, and this feature should be enforced by the P2P 1053 network. 1055 It must also be difficult to monitor who is communicating with a 1056 particular user, or retrieve any contextual data about the user 1057 without the user's explicit consent. The P2PSIP network entities 1058 must be provided with option to encrypt data exchanged with other 1059 P2PSIP network entities. 1061 8.2.12. Badly behaving nodes 1063 It should be possible to limit potential damage caused by 1064 malfunctioning and badly behaving nodes in a P2PSIP system. As the 1065 policy taken by the P2PSIP system operator/community may be very 1066 liberal, any user can obtain the right to be a user of a P2PSIP 1067 system. It may be that some users behave badly intentionally in 1068 which case it should be possible to limit the impact of the badly 1069 behaving nodes on the overall system security. There should be 1070 methods to look for badly behaving nodes and exclude or reject them 1071 from the P2PSIP system. 1073 9. Security Considerations 1075 This memo discusses security threats in P2PSIP overlay networks. 1076 Security aspects are discussed throughout the document. However, 1077 this document does not introduce any security risk by itself. 1079 10. IANA Considerations 1081 There are no IANA considerations associated to this memo. 1083 11. Acknowledgments 1085 The authors would like to thank the many people of the IETF P2PSIP WG 1086 that have contributed to discussions and provided input invaluable in 1087 assembling this document. 1089 Acknowledgement is also given to Jan-Erik Ekberg and Pekka Laitinen, 1090 both with Nokia, and to Jiang Xingfeng with Huawei for their work on 1091 earlier versions of the documents now incorporated into this draft. 1092 Acknowledgement is also given to Christian Schmidt with Nokia Siemens 1093 Networks, Roni Even with Gesher Erove for providing valuable input to 1094 this document, and also to Bruce Lowekamp for valuable comments to 1095 this document. 1097 12. Changes 1099 NOTE TO RFC EDITOR: Please remove this section prior to publication. 1100 It is included only to aid in the discussion and development of the 1101 document. 1103 12.1. Revision 5 1105 This document represents a merge of two drafts: 1107 o draft-matuszewski-p2psip-security-requirements 1109 o [I-D.song-p2psip-security-eval] 1111 with some post-merge editing by Song Haibin, Dan York and Marcin 1112 Matuszewski. The authors have finished with the work that is 1113 promised in the previous version. The main changes include: 1115 o The security requirements have been taken out from this document, 1116 which have been sent out to the P2PSIP mailing list to provide 1117 security guidance for the base draft. And this document has 1118 become an analysis and tutorial for p2psip security. 1120 o The document is synchronized with the recently released updates to 1121 the RELOAD protocol as documented by editor Bruce Lowekamp in 1122 [I-D.ietf-p2psip-sip] and [I-D.ietf-p2psip-base] 1124 o The merge between the two previous documents is completed and the 1125 text flows better. 1127 o A section will be added on security requirements related to 1128 interconnection of P2PSIP networks to other networks including 1129 non-P2P SIP networks and the PSTN. 1131 o A subsection about SIP usage security has been created. 1133 o Various wording changes based on comments from Christian Schmidt. 1135 12.2. Revision 6 / Overview -00 1137 This revision primarily is the change of the name to 1138 'draft-matuszewski-p2psip-security-overview-00' for consideration for 1139 adoption as a working group document. 1141 Additionally, the following changes were made: 1143 o IPR declaration changed to 'pre5378Trust200902' based on feedback 1144 from other authors. 1146 o Removed references to RFC 2119 and began removal of normative 1147 language. 1149 o Figures changed to reflect RELOAD protocol. 1151 o Reference to "I-D.zheng-p2psip-diagnose" changed to "I-D.ietf- 1152 p2psip-diagnostics". 1154 o Affiliation of Marcin Matuszewski changed to "Future Invest". 1156 o Acknowledgements changed to add notes about Roni Even and Bruce 1157 Lowekamp. 1159 13. Normative References 1161 [I-D.bryan-p2psip-app-scenarios] 1162 Bryan, D., Shim, E., Lowekamp, B., and S. Dawkins, 1163 "Application Scenarios for Peer-to-Peer Session Initiation 1164 Protocol (P2PSIP)", draft-bryan-p2psip-app-scenarios-00 1165 (work in progress), November 2007. 1167 [I-D.bryan-p2psip-requirements] 1168 Bryan, D., "P2PSIP Protocol Framework and Requirements", 1169 draft-bryan-p2psip-requirements-00 (work in progress), 1170 July 2007. 1172 [I-D.ietf-p2psip-base] 1173 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 1174 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 1175 Base Protocol", draft-ietf-p2psip-base-03 (work in 1176 progress), July 2009. 1178 [I-D.ietf-p2psip-concepts] 1179 Bryan, D., Matthews, P., Shim, E., Willis, D., and S. 1180 Dawkins, "Concepts and Terminology for Peer to Peer SIP", 1181 draft-ietf-p2psip-concepts-02 (work in progress), 1182 July 2008. 1184 [I-D.ietf-p2psip-diagnostics] 1185 Yongchao, S., Jiang, X., Even, R., and D. Bryan, "P2PSIP 1186 Overlay Diagnostics", draft-ietf-p2psip-diagnostics-01 1187 (work in progress), June 2009. 1189 [I-D.ietf-p2psip-sip] 1190 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 1191 H. Schulzrinne, "A SIP Usage for RELOAD", 1192 draft-ietf-p2psip-sip-01 (work in progress), March 2009. 1194 [I-D.song-p2psip-security-eval] 1195 Yongchao, S., Zhao, B., Jiang, X., and J. Haifeng, "P2PSIP 1196 Security Analysis and Evaluation", 1197 draft-song-p2psip-security-eval-00 (work in progress), 1198 February 2008. 1200 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1201 A., Peterson, J., Sparks, R., Handley, M., and E. 1202 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1203 June 2002. 1205 Authors' Addresses 1207 Song Haibin 1208 Huawei 1209 Baixia Road No. 91 1210 Nanjing, Jiangsu Province 210001 1211 P.R.China 1213 Phone: +86-25-84565867 1214 Fax: +86-25-84565085 1215 Email: melodysong@huawei.com 1217 Marcin Matuszewski 1218 Future Invest 1220 Email: marcin.matuszewski@futureinvest.pl 1222 Dan York 1223 Voxeo Corporation 1224 Keene, NH 1225 USA 1227 Phone: +1-407-455-5859 1228 Email: dyork@voxeo.com 1229 URI: http://www.voxeo.com/