idnits 2.17.1 draft-song-p2psip-security-eval-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 665. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 676. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 683. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 689. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 3, 2008) is 5927 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.bryan-p2psip-app-scenarios' is mentioned on line 93, but not defined == Missing Reference: 'I-D.draft-bryan-p2psip-app-scenarios' is mentioned on line 333, but not defined == Unused Reference: 'RFC4981' is defined on line 524, but no explicit reference was found in the text == Unused Reference: 'I-D.jennins-p2psip-security-mechanisms' is defined on line 536, but no explicit reference was found in the text == Unused Reference: 'I-D.bryan-p2psip-requirement' is defined on line 540, but no explicit reference was found in the text == Unused Reference: 'P2PSIP-Concepts-Terminology' is defined on line 544, but no explicit reference was found in the text == Unused Reference: 'P2P-Vulnerabilities-Report' is defined on line 552, but no explicit reference was found in the text == Unused Reference: 'P2P-Sybil-Attack' is defined on line 557, but no explicit reference was found in the text == Unused Reference: 'P2P-Eclipse-Attack' is defined on line 560, but no explicit reference was found in the text == Unused Reference: 'P2P-Namespace-Integrity' is defined on line 564, but no explicit reference was found in the text == Unused Reference: 'I-D.zheng-p2psip-diagnose' is defined on line 568, but no explicit reference was found in the text == Unused Reference: 'I-D.bryan-p2psip-reload' is defined on line 574, but no explicit reference was found in the text == Unused Reference: 'I-D.baset-p2psip-p2pp' is defined on line 578, but no explicit reference was found in the text == Unused Reference: 'I-D.jiang-p2psip-sep' is defined on line 582, but no explicit reference was found in the text == Unused Reference: 'I-D.marocco-p2psip-xpp-pcan' is defined on line 586, but no explicit reference was found in the text == Unused Reference: 'I-D.matthews-p2psip-hip-hop' is defined on line 591, but no explicit reference was found in the text == Unused Reference: 'I-D.bryan-p2psip-dsip' is defined on line 595, but no explicit reference was found in the text == Unused Reference: 'I-D.jennings-p2psip-asp' is defined on line 599, but no explicit reference was found in the text == Unused Reference: 'I-D.zheng-p2psip-client' is defined on line 603, but no explicit reference was found in the text == Unused Reference: 'I-D.li-p2psip-client' is defined on line 607, but no explicit reference was found in the text -- No information found for draft-ietf- - is the name correct? == Outdated reference: A later version (-06) exists of draft-matuszewski-p2psip-security-requirements-01 == Outdated reference: A later version (-04) exists of draft-bryan-p2psip-reload-02 == Outdated reference: A later version (-01) exists of draft-jiang-p2psip-sep-00 -- No information found for draft-marocco- - is the name correct? == Outdated reference: A later version (-01) exists of draft-zheng-p2psip-client-protocol-00 Summary: 1 error (**), 0 flaws (~~), 25 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Yongchao. Song 3 Internet-Draft Huawei 4 Intended status: Informational Ben Y. Zhao 5 Expires: August 6, 2008 U. of California, Santa Barbara 6 Xingfeng. Jiang 7 Haifeng. Jiang 8 Huawei 9 February 3, 2008 11 P2PSIP Security Analysis and Evaluation 12 draft-song-p2psip-security-eval-00 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 6, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2008). 43 Abstract 45 This document provides an analysis and evaluation of security with 46 P2PSIP overlay network. The draft compares security difference 47 between C/S and P2P, then partitions the P2PSIP architecture into 48 layers, and analyze the security issues in each layer and the 49 security relationship among the layers. Security issues with 50 different kind of application scenarios are distinct. This draft 51 classifies the application scenarios into two main types, and the 52 security threats with these two types of scenarios are analyzed in 53 detail. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Security Comparison between C/S and P2P . . . . . . . . . . . 4 60 4. Security Analysis with P2P Layers . . . . . . . . . . . . . . 5 61 4.1. Transport Layer Security . . . . . . . . . . . . . . . . . 7 62 4.2. Routing Maintenance and KBR layer Security . . . . . . . . 7 63 4.3. Distributed Storage and Replication Layer Security . . . . 8 64 4.4. Application Layer Security . . . . . . . . . . . . . . . . 8 65 5. Security Analysis with Application Scenarios . . . . . . . . . 8 66 5.1. Trusted P2P Overlay Base . . . . . . . . . . . . . . . . . 9 67 5.2. Untrusted P2P Overlay Base . . . . . . . . . . . . . . . . 10 68 6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 71 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 74 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 76 Intellectual Property and Copyright Statements . . . . . . . . . . 17 78 1. Introduction 80 As pointed out in Peer-to-Peer SIP (P2PSIP) concepts and terminology 81 document [I-D.ietf-p2psip-concepts], building a P2PSIP system has 82 many security consideration. The intention of this draft is not to 83 provide a solution but to give some guidelines and references for the 84 development of P2PSIP peer and client protocol. The interaction with 85 conventional SIP and other systems are not included at present. 87 This document compares security difference between C/S and P2P, and 88 then partitions the P2P applications into four main layers, and 89 analyze the security issues in each layer, and their relationship 90 from security perspective. 92 The detailed security requirements of P2PSIP overlay network are 93 dependent on the deployment scenarios[I-D.bryan-p2psip-app-scenarios] 94 in the real world. In this draft, the application scenarios are 95 divided into two types in general according to the likely deployment 96 method. The security issues with each type are analyzed in detail. 98 2. Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 The terminology and definitions used in this document are compatible 105 with P2PSIP Work Group Draft "Concepts and Terminology for Peer to 106 Peer SIP" [I-D.ietf-p2psip-concepts]. We also introduce the 107 following important new terms used in this document, and they are 108 also interpreted when used inline. 110 P2P Overlay Base:A P2P Overlay Base includes all the Peers that 111 participate in the p2p overlay. The P2P Overlay Base provides 112 distributed storage and routing services to both peers and 113 clients. 115 Trusted P2P Overlay Base:All peers in a Trusted P2P Overlay Base are 116 trusted. The Peers in the overlay are all of good behaviors and 117 under control due to deployment. For example, a carrier deploys 118 a Trusted P2P Overlay Base to provide service to his customers, 119 and all the peers are the carrier's devices. 121 Untrusted P2P Overlay Base: Peers in a Untrusted P2P Overlay Base 122 are not all trusted. There may exist some malicious behaving 123 nodes in the P2P Overlay Base. 125 3. Security Comparison between C/S and P2P 127 +------------+----------------------+--------------------------+ 128 | | | | 129 | | C/S | P2P | 130 +------------+----------------------+--------------------------+ 131 | | | | 132 | transport | authenticate between | authenticate between | 133 | | client and server | neighbors | 134 | | | | 135 +------------+----------------------+--------------------------+ 136 | |need one hop security | need hop by hop security| 137 | routing |transport layer | to ensure the end to end| 138 | |security can ensure it| security | 139 +------------+----------------------+--------------------------+ 140 | | | responsible peer may not | 141 | storage | server is trusted for| trusted, need end to end | 142 | | storage | security | 143 +------------+----------------------+--------------------------+ 144 | | | | 145 | application| out of scope of this| out of scope of this | 146 | | specification | specification | 147 | | | | 148 +------------+----------------------+--------------------------+ 150 Figure 1 Comparision between C/S and P2P security 152 In Client Server(C/S) architecture, a client asks for a specific 153 service only from a specific server. And the following process of 154 the server is transparent to the client. The destination contact 155 address(i.e. the address of that server) can be acquired from the 156 trusted DNS system directly. So there only exist security issues 157 with one hop. What we need to do is making a client be secure to 158 that server, and making that server be secure to this client, and 159 typically nothing more. 161 However, in P2P Overlay, the distinct architecture from C/S makes the 162 security issues change. 164 First, One overlay is an autonomous system, each peer in the system 165 can provide distributed storage and transport services for other P2P 166 entities, and the p2p overlay is self-organization. Whereas in C/S 167 architecture, only a specific server provides certain services to the 168 clients. 170 Second, a peer sends messages though Key-Based-Routing and he doesn't 171 know where the destination is. There exist intermediate nodes 172 between the source and destination. Whereas in C/S architecture, a 173 client sends its request directly to a server. 175 Third, one peer does not know whether he should trust the information 176 acquired from the overlay. Whereas in C/S architecture, the 177 information acquired from the server is always trustful. 179 So in P2P overlay, security issues not only exist between end to end 180 entities, but also between hop by hop services. They are not only 181 related to the routing security, but also related to the content 182 security. 184 4. Security Analysis with P2P Layers 186 The security of P2PSIP has close relationship with each layer 187 security of P2PSIP architecture. Here we splits the P2PSIP 188 architecture into four main layers, as shown in the following figure, 189 and analyze the security issues from the p2psip architecture 190 perspective. 192 +----------+ 193 | | Application Layer 194 | | -------------------------------------- 195 | | +------+ +-------------+ +-------------+ 196 | | | | | Distributed | | Replication | 197 | | | | | Storage | | | 198 | | | | +-------------+ +-------------+ 199 | | | |-------------------------------------- 200 |Enrollment| |P2P | +-------------+ 201 |Server | |Layers| | Routing | 202 | | | | | Maintenance | +-----------+ 203 | | | | +-------------+ | NAT&FW | 204 | | | | +-------------+ | Traversal | 205 | | | | | Key Based | +-----------+ 206 | | | | | Routing(KBR)| 207 | | +------+ +-------------+ 208 | | -------------------------------------- 209 | | Transport Layer Security(TLS,DTLS) 210 +----------+ 212 Figure 2 P2PSIP architecture 214 The four main layers are: 216 Application Layer: Provides the user application, and invokes the 217 services provided by the Distributed Storage and Replication Layer. 219 Distributed Storage and Replication Layer: Stores and Manages the 220 resource objects. Each peer's responsible resource objects are 221 determined by the specific P2P algorithm. Replication may be 222 utilized to ensure the availability of resource objects under churn. 224 Routing Maintenance and KBR Layer: Maintains the routing table, and 225 do the Key Based Routing(KBR). NAT and Firewall traversal may be 226 involved to establish direct connections. 228 Transport Layer: Provides transport service for the upper layers. 230 The security measures adopted in the lower layer may impact the upper 231 layer security choices. And not every security threat needs to be 232 considered in all layers, however, it is typically only required to 233 be solved in one layer. And the interesting issue is in which layer 234 should the specific security threat be considered and solved. We 235 have our primary analysis for each layer in the following sub 236 sections. 238 4.1. Transport Layer Security 240 P2PSIP overlay mostly run on top of the Internet, messages between 241 associated nodes should be protected against attacks(such as Man-in- 242 the-Middle). In order to establish the identity trust association, 243 nodes SHOULD authenticate each other, TLS and DTLS are preferable to 244 solve these problems. If transport service security is fully 245 protected, we can prevent nodes without valid identities to 246 participate in the overlay. This layer must provides reliable and 247 secure hop by hop transport service for the p2p overlay, though that 248 is not enough. 250 4.2. Routing Maintenance and KBR layer Security 252 Each Peer in the P2PSIP overlay provides key based routing service to 253 other peers, and a routing maintenance mechanism is used to keep the 254 routing table timely and correct for the routing service. There are 255 some security threats with the routing table updating interaction and 256 the key based routing. 258 Even if all the nodes participating in the P2PSIP overlay are with 259 valid identities, the overlay may still be attacked by responding 260 with fake routing table to UPDATE requests. If the routing table is 261 false, the routing determination based on it will be false too. So, 262 verification mechanisms SHOULD be adopted to verify if the routing 263 table one learned from another is correct or not. A correct routing 264 table is important for hop by hop security. 266 Second, some attacker who is not responsible for the destination ID, 267 responds to some requests when he is in the intermediate routing 268 path(May respond with a fabricated resource object or just says that 269 the searched resource object doesn't exist). Should the source node 270 verify whether the response peer is responsible for the request? 271 When and how does the source peer do that? Whether the response peer 272 is responsible for the request is important for the end to end 273 security. 275 Third, some attackers may discard the messages when forwarding, or on 276 purpose forward the message to a wrong next hop. Should the overlay 277 need a method to detect the misbehaving forwardings? 279 Chosen-ID attack makes the above security issues much more worse. 281 Fourth, some attacks may cause the overlay under high churn rate. 282 Overlay wastes much more traffic to update the routing table, and 283 transfer relative resource objects under churn. 285 The first and fourth issue above is about routing maintenance 286 function security, and the remain two issues are about the KBR 287 function security. 289 4.3. Distributed Storage and Replication Layer Security 291 Distributed storage and replication layer provides distributed 292 storage service for the resource objects that located in one's 293 responsible resource ID range, and the replication service to keep 294 the availability of resource objects under churn. The security 295 issues in this layer are typically end to end, and about the content 296 and authority security. 298 First, how to protect resource objects against unauthorized data 299 operation such as obtainment, modification or removing? 301 Second, should the P2PSIP overlay need a method to prevent attackers 302 from publishing malicious information that will cause a DDOS attack? 303 For example, Peer A may publish a very popular resource record with 304 the contact address of Peer B without B's permission. That causes 305 unexpected lots of connections to B which will make Peer B down. 307 Third, overlays work well for a reasonable amount of resource 308 objects, but crash more or less when inserting millions of resource 309 objects per node. Spam attacks can make overlays go down. Open 310 issue: Should the spam attack be considered in the distributed 311 storage layer? Or is it only the responsibility of the application 312 layer to handle this problem? 314 Replication security is to TODO. 316 4.4. Application Layer Security 318 Application layer security requirements are out of scope of this 319 specification. 321 5. Security Analysis with Application Scenarios 323 As described in the security considerations section in application 324 scenarios draft[I-D.draft-bryan-p2psip-app-scenarios], the security 325 requirements of the various application scenarios vary tremendously. 326 So in this section, we divide the application scenarios into two main 327 types, instead of analyzing all the security threats with each 328 specific scenario described in the application scenarios draft, we 329 just analyze the relative security threats of these two types, which 330 represent most of the likely deployment scenarios in the real world. 331 For example, the "Public P2P VoIP Service Providers" scenario in 332 section 4.1.1 of application scenarios 333 draft[I-D.draft-bryan-p2psip-app-scenarios] may be deployed using the 334 first type(refer to section 5.1 of this specification), and the "Open 335 Global P2P VoIP Network" scenario in section 4.1.2 of application 336 scenarios draft may be deployed using the second type(refer to 337 section 5.2 of this specification). 339 5.1. Trusted P2P Overlay Base 341 In a trusted P2P Overlay Base, all the peers are deployed with 342 trustful nodes. They are of good behaviors. They may deployed to 343 provide reliable and high quality services, and may also do some 344 management issues for the overlay. All P2PSIP clients access the 345 overlay service through the associated trusted peer. Shown as the 346 following figure 3. 348 +---------+ +---------+ 349 | Trusted +---------------+ Trusted | 350 | Peer | | Peer | 351 +---+-----+ +----+----+ 352 | | 353 | | 354 | 355 | | 356 | P2PSIP Peer | 357 +---+-----+ Protocol +----+----+ 358 | Trusted +---------------+ Trusted | 359 | Peer | | Peer | 360 +---+-----+ +----+----+ 361 | | 362 P2PSIP Client | 363 Protocol | 364 +---+-----+ +----+----+ 365 | | | | 366 |Client | | Client | 367 +---------+ +---------+ 369 Figure 3 Trusted P2P Overlay Base 371 As for this type of scenarios, we regard the P2P Overlay Base to be 372 secure. The security issues to be considered are the transport 373 security between trusted peers and the security issues associated 374 with clients. Because clients doesn't provide routing service for 375 the overlay. Security issues more focus on distributed storage 376 layer. Some of the attacks are described in the p2p-security- 377 requirement draft[I-D.matuszewski-p2psip-security-requirement]. 379 +--------------------+-----------------------+---------------------+ 380 | Possible Attacks | Descriptions | Considerations | 381 |--------------------+-----------------------+---------------------+ 382 | | 1.Message Privacy | TLS and DTLS | 383 | Transport Related | 2.ID hijack | | 384 +--------------------+-----------------------+---------------------+ 385 |Unauthorized Data | Unauthorized Access, | Certificate | 386 |Operation | Modification, Removing| Mechanism | 387 +--------------------+-----------------------+---------------------+ 388 | | In the progress of | | 389 | Man In the Middle | Authentication between| Authentication | 390 | | client and its | Security | 391 | | associated peer | | 392 +--------------------+-----------------------+---------------------+ 393 | | | | 394 | data pollution and |1.Publish Fake Resource| 1.Check Mechanism? | 395 | poison | Objects | | 396 | |2.Publish malicious | 2.Black List? | 397 | | contact information | | 398 | | (DDOS attack) | | 399 +--------------------+-----------------------+---------------------+ 400 | | | | 401 | Spam Attack | Publish lots of | 1. Check Mechanism? | 402 | | redundant resources | 2. Limit one's | 403 | | | publication number? | 404 +--------------------+-----------------------+---------------------+ 406 Figure 4 Possible Attacks on the Trusted Overlay Base Scenarios 408 5.2. Untrusted P2P Overlay Base 410 In an untrusted P2P Overlay Base, there are peers who are not trusted 411 by other peers. Some of untrusted peers may do harmful things or 412 abnormal behaviors to the overlay due to malicious or unknown 413 intentions. There may or may not exist trusted peers in the overlay. 414 Shown as the following Figure 5. 416 Please view in a fixed-width font such as 417 Courier. 419 +---------+ +---------+ 420 |Untrusted+---------------+ Peer | 421 | Peer | | | 422 +---+-----+ +----+----+ 423 | | 424 | | 425 | | 426 | | 427 | P2PSIP Peer | 428 +---+-----+ Protocol +----+----+ 429 | Peer +---------------+Untrusted| 430 | | | Peer | 431 +---+-----+ +----+----+ 432 | | 433 P2PSIP Client P2PSIP Client 434 Protocol Protocol 435 +---+-----+ +----+----+ 436 | | | | 437 |Client | | Client | 438 +---------+ +---------+ 440 Figure 5 Untrusted P2P Overlay Base 442 As for this type of scenarios, the security threats with the Trusted 443 P2P Overlay Base still exist, besides that, even more security issues 444 emerge, because there may exist malicious peers in this type of 445 scenarios. Each layer of the P2PSIP architecture and the enrollment 446 may be attacked, the attacks beyond those in the Trusted Overlay Base 447 scenarios are listed in the followings Figure 6. 449 +--------------------+-----------------------+---------------------+ 450 | Possible Attacks | Descriptions | Considerations | 451 |--------------------+-----------------------+---------------------+ 452 | |1.Chosen-ID attack | 1.Enrollment Server | 453 | Identity Attack |2.Sybil Attack | | 454 | |3.Fabricated response | 2.A proof mechanism | 455 | | from the intermediate| to verify whether it| 456 | | peer | is a true root? | 457 +--------------------+-----------------------+---------------------+ 458 | |1.discard messages | 1.message signature?| 459 | Forwarding Attack |2.Forwarding to a wrong| 2.A diagnosis | 460 | |next hop node | mechanism for | 461 | |3.modify messages when | detecting which | 462 | |forwarding | intermediate peer is| 463 | | | a bad man? | 464 +--------------------+-----------------------+---------------------+ 465 | | Intermediate peer | | 466 | Replay Attack | stores messages and |Timestamp to | 467 | | replays |recognize timed | 468 | | |messages? | 469 +--------------------+-----------------------+---------------------+ 470 | | give malicious | | 471 | Routing Table | response info to an |Per DHT specific? | 472 | Attack | updating routing table| | 473 | | request | | 474 +--------------------+-----------------------+---------------------+ 476 Figure 6 Possible Attacks on the Untrusted Overlay Base Scenarios 478 As for these security issues, the diagnosis draft[I-D.zheng-p2psip- 479 diagnose] provides a framework using an ECHO message to diagnose the 480 problems in the P2PSIP overlay. 482 6. Open Issues 484 1. Do we need a verification mechanism to verify if the routing 485 table one learned from another is correct or not? 487 2. Should the source node verify whether the response peer is 488 responsible for the request? When and how does the source peer do 489 that? 491 3. Should the overlay need a method to detect the misbehaving 492 forwardings? 494 4. How to protect resource objects against unauthorized data 495 operations? And in which layer should we do that? 496 5. Should the P2PSIP overlay need a method to prevent attackers from 497 publishing Malicious Information or Spams? And in which layer should 498 we address these problems? 500 7. Security Considerations 502 This document analyzes and evaluates security in P2PSIP overlay 503 networks, but it does not introduce any security risk by itself. 505 8. IANA Considerations 507 There are no IANA considerations associated to this memo. 509 9. Acknowledgments 511 We would like to thank Zheng Hewen for his contribution to part of 512 this specification. We would like to thank Eunsoo Shim, Li Feng, Hu 513 Xinyu, Ning Zong for their valuable comments. And many authors' 514 discussion in the p2psip and p2p-hackers mailing list are contributed 515 to this draft. 517 10. References 519 10.1. Normative References 521 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 522 Requirement Levels", BCP 14, RFC 2119, March 1997. 524 [RFC4981] J. Risson, "Survey of Research towards Robust Peer-to-Peer 525 Networks: Search Methods", RFC 4981, September 2007. 527 [I-D.ietf-p2psip-concepts] Bryan, D., "Concepts and Terminology for 528 Peer to Peer SIP", draft-ietf- p2psip-concepts-00 (work in progress), 529 June 2007. 531 [I-D.matuszewski-p2psip-security-requirement] M. Matuszewski, 532 "Security requirements in P2PSIP", 533 draft-matuszewski-p2psip-security-requirements-01 (work in progress), 534 July 2007 536 [I-D.jennins-p2psip-security-mechanisms] C. Jennings, "Security 537 Mechanisms for Peer to Peer SIP", draft-jennings-p2psip-security-00 538 (work in progress), February 2007 540 [I-D.bryan-p2psip-requirement] D. Bryan, "P2PSIP Protocol Framework 541 and Requirements", draft-bryan-p2psip-requirements-00 (work in 542 progress), July 2007 544 [P2PSIP-Concepts-Terminology] Dean Willis, "P2PSIP Concepts and 545 Terminology", http://www3.ietf.org/ proceedings/07jul/slides/p2psip- 546 13.pdf, July 2007 548 [I-D.draft-bryan-p2psip-app-scenarios]D. Bryan, "Application 549 Scenarios for Peer-to-Peer Session Initiation Protocol", 550 draft-bryan-p2psip- app-scenarios-00(work in progress), November 2007 552 [P2P-Vulnerabilities-Report] Marling Engle and Javed I. Khan, 553 "Vulnerabilities of P2P Systems and a Critical Look at their 554 Solutions", http://medianet.kent.edu/technicalreports.html, November 555 2006 557 [P2P-Sybil-Attack] John R. Douceur, "The Sybil Attack", In Proc. of 558 IPTPS (Cambridge, MA, March 2002). 560 [P2P-Eclipse-Attack] Singh, A., Ngan, T.-W., Druschel, P., and 561 Wallach, D., "Eclipse attacks on overlay networks: Threats and 562 defenses" In Proc. of INFOCOM (Barcelona, Spain, April 2006) 564 [P2P-Namespace-Integrity] Krishna P. N. Puttaswamy, Ben Y. Zhao etc, 565 "Protecting Namespace Integrity in Structured Overlays", IEEE, 566 December 2007 568 [I-D.zheng-p2psip-diagnose] H. Zheng, "Diagnose P2PSIP Overlay 569 Network Failures", draft- zheng-p2psip-diagnose-00 (work in 570 progress), November 2007. 572 10.2. Informative References 574 [I-D.bryan-p2psip-reload] C. Jennings, B. Lowekamp, E. Rescorla and 575 J. Rosenberg, "REsource LOcation And Discovery (RELOAD)", 576 draft-bryan-p2psip-reload-02 (work in progress), November 2007. 578 [I-D.baset-p2psip-p2pp] S. Baset, H. Schulzrinne and M. Matuszewski, 579 "Peer-to-Peer Protocol (P2PP)", draft-baset-p2psip-p2pp-01 (work in 580 progress), November 2007. 582 [I-D.jiang-p2psip-sep] X. Jiang and H. Zheng, "Service Extensible P2P 583 Peer Protocol", draft-jiang-p2psip-sep-00 (work in progress), 584 November 2007. 586 [I-D.marocco-p2psip-xpp-pcan] Marocco, E. and E. Ivov, "XPP 587 Extensions for Implementing a Passive P2PSIP Overlay Network based on 588 the CAN Distributed Hash Table", draft-marocco- p2psip-xpp-pcan-00 589 (work in progress), June 2007. 591 [I-D.matthews-p2psip-hip-hop] Cooper, E., "A Distributed Transport 592 Function in P2PSIP using HIP for Multi-Hop Overlay Routing", 593 draft-matthews-p2psip-hip-hop-00 (work in progress), June 2007. 595 [I-D.bryan-p2psip-dsip] D. Bryan, B. Lowekamp and C. Jennings, "dSIP: 596 A P2P Approach to SIP Registration and Resource Location", 597 draft-bryan-p2psip-dsip-00 (work in progress), February 2007. 599 [I-D.jennings-p2psip-asp] C. Jennings, J. Rosenberg and E. Rescorla,, 600 "Address Settlement by Peer to Peer", draft-jennings-p2psip-asp-00 601 (work in progress), July 2007. 603 [I-D.zheng-p2psip-client] H. Zheng, "P2PSIP Client Protocol", 604 draft-zheng-p2psip-client-protocol-00 (work in progress), October 605 2007. 607 [I-D.li-p2psip-client] L. Li, Ch. Zhang, Y. Wang and Y. Ji, "A SIP- 608 based P2PSIP Client Protocol", draft-li-p2psip-client-protocol-00 609 (work in progress), November 2007. 611 Authors' Addresses 613 Song Yongchao 614 Huawei 615 Baixia Road No. 91 616 Nanjing, Jiangsu Province 210001 617 P.R.China 619 Phone: +86-25-84565081 620 Fax: +86-25-84565070 621 Email: melodysong@huawei.com 623 Ben Y. Zhao 624 U. of California, Santa Barbara 625 Santa Barbara, California 626 U.S.A 628 Phone: +1 805 893-3926 629 Fax: +1 805 893-8553 630 Email: ravenben@cs.ucsb.edu 631 Jiang Xingfeng 632 Huawei 633 Baixia Road No. 91 634 Nanjing, Jiangsu Province 210001 635 P.R.China 637 Phone: +86-25-84565079 638 Fax: +86-25-84565070 639 Email: jiang.x.f@huawei.com 641 Jiang Haifeng 642 Huawei 643 Baixia Road No. 91 644 Nanjing, Jiangsu Province 210001 645 P.R.China 647 Phone: +86-25-84565080 648 Fax: +86-25-84565070 649 Email: jianghaifeng@huawei.com 651 Full Copyright Statement 653 Copyright (C) The IETF Trust (2008). 655 This document is subject to the rights, licenses and restrictions 656 contained in BCP 78, and except as set forth therein, the authors 657 retain all their rights. 659 This document and the information contained herein are provided on an 660 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 661 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 662 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 663 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 664 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 665 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 667 Intellectual Property 669 The IETF takes no position regarding the validity or scope of any 670 Intellectual Property Rights or other rights that might be claimed to 671 pertain to the implementation or use of the technology described in 672 this document or the extent to which any license under such rights 673 might or might not be available; nor does it represent that it has 674 made any independent effort to identify any such rights. Information 675 on the procedures with respect to rights in RFC documents can be 676 found in BCP 78 and BCP 79. 678 Copies of IPR disclosures made to the IETF Secretariat and any 679 assurances of licenses to be made available, or the result of an 680 attempt made to obtain a general license or permission for the use of 681 such proprietary rights by implementers or users of this 682 specification can be obtained from the IETF on-line IPR repository at 683 http://www.ietf.org/ipr. 685 The IETF invites any interested party to bring to its attention any 686 copyrights, patents or patent applications, or other proprietary 687 rights that may cover technology that may be required to implement 688 this standard. Please address the information to the IETF at 689 ietf-ipr@ietf.org. 691 Acknowledgment 693 Funding for the RFC Editor function is provided by the IETF 694 Administrative Support Activity (IASA).