idnits 2.17.1 draft-bryan-p2psip-requirements-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 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1431. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1408. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1415. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1421. 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 53 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Req 7-8: The size of the routing state, that is the greedy routing table plus the tables of neighbor nodes SHOULD be kept equal or minimally larger than required by the routing table for the [14] routing protocol and MUST not grow faster than the log of the P2P overlay size. Note however that this does NOT mean that it must be the log of the maximum size possible (for example, 160 neighbors for systems using 2^160 hash size) of the overlay, since this may be impractical (and undesirable) for small networks such as ad-hoc or enterprise. It also does NOT mean that additional neighbors may not be stored to improve efficiency if capacity is available. Because routing efficiency and local storage used are tradeoffs that may vary for different deployments, the balance of this is left to the various DHTs used (or the overlay designer) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Req 7-10: The default DHT selected for the peer protocol MUST incorporate techniques for handling churn. Joining, leaving, or searching the P2P overlay under high churn condition SHOULD not be significantly slower than these operations in the absence of churn. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: In some DHTs a peer ID is based on the IP address. This means that when a node receives a new IP address it must also receive a new peer ID. This is equivalent to a node leaving the overlay network and joining it again. This may cause network instability and require additional resources to handle network adaptation (as explained above). This has impact on battery life of battery-powered as well as on system reliability. In the transition period search delay for user contact information may be higher, delaying the call establishment. For these reasons, the node ID SHOULD not depend on the IP address. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Req 7-11: The peer protocol MUST not interfere with mobility. A DHT MUST be available that supports mobility to allow network nodes to freely move from one access network to another without causing changes in the overlay network topology and decreasing routing performance. The information about new address of a node MUST propagate in real-time to the rest of the peers that need that information. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 P2PSIP WG D. Bryan/SIPeerio-editor 2 Internet Draft S. Baset/Columbia U. 3 Intended status: Informational M.Matuszewski/Nokia 4 Expires: Jan 2008 H.Sinnreich/Adobe 6 P2PSIP Protocol Framework and Requirements 7 draft-bryan-p2psip-requirements-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on December 1, 2007. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2007). 38 Abstract 40 Though both SIP and various peer-to-peer (p2p) protocols have been 41 widely deployed, there is no operational experience with SIP using 42 overlay networks. Also, most p2p networks developed in the research 43 community do not deal with NAT traversal. This document attempts to 44 list the design requirements for a P2PSIP protocol taking into 45 account the experience gained from both the p2p and the SIP 46 communities. Special emphasis has been put on the SIP-DHT interface, 47 on the overlay performance, on NAT traversal and on security. 49 Conventions used in this document 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in RFC-2119. 55 Table of Contents 57 1. Introduction...................................................4 58 2. Deployment Scenario Examples...................................5 59 2.1. Peer Protocol Deployment..................................6 60 2.2. Client Protocol Deployment................................6 61 3. NAT Traversal..................................................7 62 4. Bootstrap and Other Servers....................................7 63 5. SIP-P2P Interface..............................................8 64 6. APIs for DHT Usage............................................10 65 7. P2P Overlay Requirements......................................10 66 7.1. Architecture and Virtual Geometries......................11 67 7.2. Structured Overlays......................................12 68 7.3. Data Replication.........................................12 69 7.4. Load Balancing...........................................13 70 7.5. Overlay Performance......................................13 71 7.5.1. Routing Performance.................................14 72 7.5.2. Routing Tables and Routing State....................15 73 7.5.3. Iterative and Recursive Routing Styles..............16 74 7.5.4. Handling of Join/Leave (Churn)......................17 75 7.5.5. Enabling Mobility...................................18 76 7.5.6. Fault Tolerance to Non-Transitive Connectivity......19 77 7.6. Implementation Experience in Selecting DHTs..............20 78 7.7. Simplicity of Implementation in Selecting a DHT..........21 79 7.8. Discussion on the Selection of a DHT Overlay.............21 80 8. Client Protocol Requirements..................................22 81 8.1. Discussion about the Client Protocol.....................24 82 9. Security Considerations.......................................25 83 9.1. DHT Security.............................................25 84 9.2. SIP Security.............................................27 85 9.3. Client Protocol Security.................................27 86 9.4. Security of the SIP-DHT Interface........................28 87 10. IANA Considerations..........................................29 88 11. Conclusions..................................................29 89 12. Acknowledgments..............................................29 90 13. References...................................................29 91 Author's Addresses...............................................32 92 Intellectual Property Statement..................................33 93 Disclaimer of Validity...........................................34 95 1. Introduction 97 Recently, the IETF has established a P2PSIP WG [2] to discuss the 98 development of a protocol to allow the establishment of SIP 99 connections with little or no need for centralized servers of any 100 kind. The WG (and individuals now composing it prior to the official 101 formation) have focused on developing a DHT based system that can be 102 used to achieve these ends. A concepts document [3] has been produced 103 that outlines the basic ideas and concepts of how such a system would 104 be structured. 106 This document attempts to accomplish a few things. It attempts to 107 combine and present requirements for designing the peer and (if 108 needed) client protocols, attempts to provide some insight into 109 selection of mandatory DHTs, and attempts to present requirements for 110 other DHTs that may be added as well. 112 Much of what is presented here is also a collection of insights and 113 references to material assembled by the authors that will assist in 114 these decisions. As the authors all have different (and sometimes 115 conflicting!) ideas about how these systems should be implemented, 116 this document may present multiple alternatives, or even mention 117 points of contention. As the group reaches more consensus, it is 118 expected that these differences will diminish. 120 This is a first revision of this document, and is the result of work 121 by authors on several continents. As such, inconsistencies and even 122 outright errors are likely to appear. The authors recognize this and 123 are happy to have the work criticized to help improve it. In 124 addition, the document is certainly incomplete, and there are areas 125 (most notably the security section) where additional help is required 126 to complete this document. We hope the discussion generated can 127 offset the early stage of this work. 129 This document on the requirements for the p2p protocols is based on 130 published research and also on running code for p2p systems. We have 131 carefully avoided articulating any requirements that cannot be 132 substantiated by both usage scenarios and by published work based on 133 running code, simulations and measurements on deployed P2P systems. 134 We have provided for this reason references that are pertinent to 135 each specific requirement. 137 This document does NOT attempt to replace the concepts [3] in any 138 way, but rather extend it to discuss requirements. 140 OPEN ISSUE: Should this document eventually be split (either into two 141 documents or simply within this document) into sections on P2PSIP 142 protocol decisions vs. DHT decisions? 144 OPEN ISSUE: Should this document eventually be split (either into two 145 documents or simply within this document) into sections on P2PSIP 146 protocol decisions vs. DHT decisions? 148 2. Deployment Scenario Examples 150 Generic applications for P2PSIP have been discussed in [4], [5] and 151 we are adding some more detailed deployment scenarios here. 153 The use of innovation in the market is usually hard to predict. 154 Still, P2PSIP can be deployed in many scenarios; out of which we have 155 selected here examples that could be most frequently related to 156 present SIP deployments. New scenarios may however emerge with 157 increased use of P2PSIP. 159 An overall view of possible deployment scenarios would require a 160 table that may be too big to fit into the ASCII format of this memo. 161 For this reason, we will rather enumerate here the main categories 162 that are encountered in deployment scenarios: 164 o Degree of mobility: Stable (PC, gateway), nomadic (laptop), 165 mobile (phone, PDA) 167 o NAT scenario: Any type of NAT, BEHAVE compliant NAT, no NAT 169 o IP connectivity: Stable, intermittent. 171 Of special interest to wireline (DSL, cable, fiber) service providers 172 is the deployment scenario where the peer nodes are located in the 173 network access devices of their customers, be they residential 174 gateways or enterprise gateways. 176 Peers located in access devices enjoy major benefits, such as: 178 o High bandwidth on the Internet side 179 o Stable connectivity 180 o No NAT in some provider network designs. 182 P2PSIP nodes in the access devices seem to be a valid replacement of 183 the conventional client-server SIP VoIP infrastructure, while 184 combining all the benefits of the end-to-end principle of the 185 Internet with the control desired by service providers or network 186 administrators via the software in the access device. 188 Mobile service providers can reap the benefit of P2PSIP by placing 189 peer nodes into the base station network and using a battery sparing 190 client protocol in the mobile devices. 192 The deployment scenarios may suggest a wide variety of protocol 193 parameters or several DHT types for various deployments. 195 In the following sections, we will use the terms P2P network and P2P 196 overlay interchangeably. 198 2.1. Peer Protocol Deployment 200 Though the mobility, churn rate and session time are quite different 201 for adapters and access devices versus a laptop, it still make sense 202 to use a single peer protocol: 204 o The IP address changes even for fixed devices 205 o Devices with higher churn rate and low session time will benefit 206 from the existence of stable peers 207 o IP connectivity may be very good for one peer but may be less 208 satisfactory for other remote peers. 209 o Interoperability will be improved, making it more likely that many 210 devices can function together in one overlay. 212 Designers may be tempted to pick the simplest DHT peer protocol for 213 the deployment scenario at hand, but run the risk of loosing the 214 flexibility offered by a full featured peer protocol. Additionally, 215 choosing a protocol that only works in limited environments means 216 those devices cannot be used in more challenging environments. 218 2.2. Client Protocol Deployment 219 The small battery capacity of handheld mobile devices requires 220 reducing the amount of messages between the mobile device and the 221 fixed network to an absolute minimum. The client protocol has 222 therefore to be designed to avoid the large message exchange required 223 for the maintenance of the P2P overlay. 225 A single standard client protocol is desirable for interoperability. 227 Wireless access points, wireless radio base stations may also contain 228 DHT peers so as to facilitate mobile devices running only the client 229 protocol. 231 To date, the working group has not decided if such a protocol is 232 needed, or if unmodified SIP can serve this role. 234 3. NAT Traversal 236 As mentioned in the Concepts and Terminology document on P2PSIP, it 237 is expected the majority of SIP peers will reside behind NAT. This 238 raises the issue to what extent can P2PSIP be successfully deployed, 239 since it will depend on effective NAT traversal techniques. 241 The state of P2P communications across NAT is discussed in [6]. In 242 the light of this document, P2PSIP must be a NAT-friendly 243 application, that is: 245 "A NAT-friendly P2P application registers with a well-known 246 rendezvous server, used for node registration and peer node discovery 247 purposes. Pursuant to registering with rendezvous server, a P2P- 248 friendly application uses its private endpoint, public endpoint, or a 249 combination thereof to establish peering sessions." 251 P2PSIP can be a NAT-friendly application, by using ICE [7]. According 252 to surveys such as [8], practically all consumer grade NAT devices 253 are P2P-friendly, so ICE can be used effectively for NAT traversal 254 consumer devices. 256 Symmetric NAT is however not P2P-friendly and NAT traversal may not 257 succeed without using STUN/TURN relay servers [9]. Symmetric NAT is 258 almost always deployed in private enterprise IT networks. Since 259 P2PSIP must be used in enterprise networks with the consent and 260 cooperation with the IT network administrator, measures can be taken 261 in private IP networks to deploy IETF BEHAVE standard compliant NAT 262 devices that are P2P friendly. The use of TURN may be required for 263 facilities where this is not possible, and SHOULD be included in 264 proposals. 266 4. Bootstrap and Other Servers 268 A small number of servers is required for the proper operation of the 269 overlay network. We discuss here briefly for clarity only these types 270 of servers though they do not affect the P2PSIP protocol design. 272 o The P2P overlay is established with the help of bootstrap servers. 274 o As mentioned in the section on NAT traversal, P2PSIP must be NAT- 275 friendly and thus also requires well-known rendezvous servers, 276 such as specified for the ICE protocol. 278 o Security for the overlay must be based on strong authentication 279 provided by an authentication server. P2PSIP does not depend on 280 the particular implementation of the authentication server and 281 therefore the authentication server is not discussed in this 282 document. 284 The bootstrap servers and the rendezvous servers may or may not be 285 placed on the same machines and this is a design decision that does 286 not affect the P2PSIP protocol. 288 A recent I-D on NAT traversal specifically for P2PSIP has been 289 published [10], showing that NAT traversal using ICE techniques are 290 quite effective. 292 5. SIP-P2P Interface 294 In a typical SIP trapezoid, a caller in domainA wishing to contact a 295 callee in domainB sends a request to its proxy server (proxyA), which 296 following the guidelines in [1] forwards the request to the proxy 297 server of domainB (proxyB). When the request arrives at proxyB, it 298 consults its location service (typically a database) to find the IP 299 address of the callee, and forwards the request to callee SIP user 300 agent. 302 A characteristic of this architecture is that the typical SIP hop- 303 count is only a few hops; the caller only needs to send its request 304 to its outbound SIP proxy, which in turn needs to locate the SIP 305 server of the callee. The key assumptions of this architecture are 306 that SIP proxy servers use DNS to locate other proxy servers, 307 maintain a database of SIP user agents in its domain, are fairly 308 stable and trusted. 310 Peer-to-peer systems on the other hand distribute the task of 311 locating the SIP proxy servers, and proxy servers locating SIP user 312 agents to the peer themselves. This means that SIP requests no longer 313 traverse through reliable and trusted proxy servers and the SIP hop- 314 count of a request can be significantly greater than a few hops; in a 315 DHT it is log(N), where N is the number of peers. 317 The above discussion suggests at least two paradigms for SIP 318 operation in a p2p setting: the end-to-end paradigm where a SIP user 319 agent uses the p2p location service to discover the location of 320 callee, and then send the SIP message directly to the callee, or a 321 hop-by-hop paradigm where each peer forwards the SIP request to a 322 peer which is more 'closer' to the callee. The former can be thought 323 of as a RPC whereas the later can be thought of as a local procedure 324 call to determine the next hop. 326 SIP uses an address-of-record (AOR), to locate the user. An AOR is a 327 SIP or SIPS URI and frequently thought as the "public address" of the 328 user. DHTs are a prime motivation for P2PSIP and they convert a blob 329 of text to a unique hash value. A DHT will generate a unique hash for 330 a SIP or SIPS URI for the same user, and store it on different peers. 331 Since a peer-to-peer system may suffer through churn, it may lead to 332 a situation where a SIP URI is reachable but SIPS URI is not or vice 333 versa. The impact of such distributions due to the underlying P2P 334 service must carefully be analyzed. 336 A SIP user agent can participate in the traditional c/s SIP or a 337 P2PSIP network at the same time. Such a UA must have a predictable 338 ordering of what to do when presented with a SIP URI. 340 SIP relies on STUN, TURN and ICE for NAT traversal. The P2P service 341 will likely incorporate NAT and firewall mechanisms for the 342 maintenance of the overlay. The SIP application may take advantage of 343 NAT traversal mechanisms provided by the underlying P2P service. 345 It is important to note that the SIP-DHT interface and the peer 346 protocol should not depend on one particular DHT. While having one 347 DHT as must implement is necessary for interoperability, there is a 348 danger that specifics from that DHT may creep into the overall 349 design. Moreover, there is no 'clear winner' out of the DHTs proposed 350 so far. The research in DHTs is ongoing and therefore the must- 351 implement DHT should in no way restrict the SIP-DHT interface and the 352 peer protocol from incorporating a DHT in the future that performs 353 significantly better. Any attempt to incorporate DHT-specific 354 information will greatly undermine the flexibility of the SIP-DHT 355 interface and the peer protocol. The Peer-to-Peer Protocol (P2PP) 356 [27] is a proposal that attempts to incorporate these concerns. 358 Req 5-1: The P2PSIP protocol MUST have a clearly defined interface 359 between the SIP and overlay layers. 361 Req 5-2: The interface between SIP and the overlay MUST support the 362 use of various types of overlays. 364 6. APIs for DHT Usage 366 DHTs provide two conceptual operations, namely, 'Lookup' to locate 367 peers responsible for a key, and 'Publish' to insert a key-value pair 368 in the DHT. In addition, a 'Remove' operation allows the publisher to 369 explicitly remove a key-value pair. These operations suffice for 370 nodes that do not participate in the DHT overlay. For nodes that do 371 participate in the overlay, additional operations of 'Join' and 372 'Leave' are necessary. Thus, at the very least, the following API 373 must be provided by the P2P layer: 375 o Join 376 o Leave 377 o Lookup 378 o Publish 379 o Remove 381 If a client protocol is implemented, the following API must be used: 383 o Lookup 384 o Publish 385 o Remove 387 Peer protocol will likely implement mechanisms for overlay 388 maintenance during churn, and replication. However, an application 389 using DHT does not need to be aware of them. If there is a need to 390 fine tune these parameters, an API similar to set[get]sockopt() can 391 be defined. 393 OPEN ISSUE: Is there a need to separately define the secure and non- 394 secure version of these APIs? 396 7. P2P Overlay Requirements 398 SIP can be used with various types of P2P overlay networks. This 399 document focuses on requirements for overlays on the Internet to 400 leverage the global reach, inherent mobility, resilience and other 401 attributes of the Internet. 403 At the same time, these requirements take also into account the 404 impairments found on the public Internet, the lack of transparency 405 due to NAT, as well as the various exposures to security for P2PSIP. 407 An important feature of the P2P design for global reach over the 408 Internet is the self organizing characteristic of P2P networks, in 409 the sense that no network management and no peer node configuration 410 is required to be performed manually. 412 Smaller P2PSIP networks such as found in private IP networks may have 413 different requirements that are not addressed in this document. 415 As mentioned in below, designers can have a fair choice of the DHT 416 they may want to deploy and this can be accommodated by the SIP-DHT 417 interface discussed in Section 5. 419 Though the focus of this memo is on SIP applications, we take into 420 account, whenever is possible, the fact that P2P overlays can be used 421 for many other non-SIP applications. Implementers of P2PSIP may have 422 compelling reasons to use an overlay for other applications beyond 423 SIP that are however out of scope for the P2PSIP WG. For this reason, 424 the flexibility of using a DHT for other applications must also be 425 considered. 427 The default protocol must be a DHT but we should not preclude other 428 overlay protocols from consideration. 430 7.1. Architecture and Virtual Geometries 432 One of the main reasons for selecting DHT overlays for large-scale 433 systems is their resilience in the event of node failures. 435 Research on structured, DHT based overlays has revealed multiple 436 architectures with various pros and cons that go beyond the scope of 437 this memo, since the DHT routing architecture is only one of several 438 selection criteria and by itself, is not of exclusive importance. 440 In this memo we focus only on structured, DHT functionality on 441 Internet-like scale for the overlay network that can be used for SIP 442 based multimedia communications. 444 For illustrative purposes, we assume a large DHT address space such 445 as 160 bits that can be represented on a virtual circular space. A 446 virtual circle is however not the only possible geometry. Pastry and 447 its successor Bamboo also display a virtual tree-like geometry that 448 facilitates routing based on increasingly matched prefixes. 450 Various tree-like routing architectures can be used for application 451 level multicast, for conferencing, collaboration and for prefix based 452 search - all of which are of interest for use in distributed SIP 453 conferencing. Highly scalable application layer multicast systems 454 have been developed in the research community [11]. Application level 455 multicast can support a wide variety of applications [12]. 457 7.2. Structured Overlays 459 Req 7-1: For scalability and predictability, a structured DHT overlay 460 MUST be used as the default P2P protocol. 462 Examples of structured overlays include CAN, Chord, Bamboo, Kademlia, 463 Pastry, Tapestry, and Viceroy [13]. 465 DHT overlays have natural limitations that must be taken into account 466 [14]. Two very different deployment scenarios illustrate the 467 limitations a particular DHT has when trying to address all problems: 469 o Highly dynamic membership of peers: In this case only small amounts 470 of data can be stored, limited by the amount of bandwidth available 471 for the update of data stored in peers. Besides the maintenance of 472 the overlay network structure may require additional resources such 473 as bandwidth, CPU and memory. This is especially evident in the 474 high network churn scenarios. 476 o Stable membership of peers: In this case large amounts of data can 477 be stored since no frequent updates are required. 479 System designers must have the flexibility to target their design 480 anywhere between these two extremes. 482 Req 7-2: The peer protocol MUST allow for flexibility in the DHT 483 selected, to allow for deployments with various tradeoffs for churn, 484 data size and bandwidth for reliable data storage. One (or a small 485 number) of DHTs specified as mandatory MUST be supported, but 486 protocol MUST allow for new DHTs to be added. 488 7.3. Data Replication 490 Most DHT schemas provide data replication in neighbor nodes that have 491 overlay identifiers numerically close to the target node. 493 High reliability for the availability of replicated data can be 494 assured because of the wide geographic diversity, IP network 495 ownership and jurisdiction, etc, of neighbor nodes that have close 496 neighbor identities [15], [16]. 498 There is a trade-off between data replication being controlled by the 499 data publisher or by the node storing the data. 501 Req 7-3: The P2PSIP Overlay MUST assure that no data placed in the 502 overlay is lost before the scheduled timeout. The scheduled timeout 503 for data on the overlay is a design choice. The protocol selected 504 MUST allow for flexibility in how redundant a system is, since some 505 deployments may require higher (or lower to conserve resources) 506 levels of redundancy. 508 7.4. Load Balancing 510 The load balancing mechanism in DHT based overlays is provided by the 511 statistical nature of the hash function and the algorithm of the DHT 512 itself. Refinement in overlay protocols, such as reported for PAST 513 over PASTRY [15] file storage have been described that attempt to 514 improve the fairness of disk sharing among peers. 516 There are several other flavors of load balancing: One is to 517 distribute data request among several replications. The other is to 518 make the request routed through different overlay paths and reduce 519 burden of hot spots. 521 Req 7-4: Dedicated load balancing schemas beyond the natural load 522 balancing of the DHT MAY be used for fair disk storage sharing 523 between peers as well as for balanced network usage. The DHT SHOULD 524 allow an efficient load balancing algorithm that distributes the load 525 on P2PSIP network entities that are responsible for storing 526 frequently queried resources. While the authors would prefer to make 527 this a MUST requirement, it is recognized that some specialized DHTs 528 may be designed to prefer other factors (for example, geographical 529 nearness) over fair load balancing. The default DHT MUST provide fair 530 load balancing. 532 7.5. Overlay Performance 534 While other designs may be possible, there are two components of most 535 DHTs that define how routing works: 537 1. Neighbor nodes for correct routing to the destination. The 538 selection of neighbor nodes can take into account network proximity 539 metrics such as latency, hop count or bandwidth of the neighbor 540 nodes. 542 2. A DHT routing algorithm for fast, greedy search, generally a 543 mechanism for determining which neighbor node to send the message 544 to. 546 These two components of the DHT architecture will be discussed here 547 in more detail. 549 7.5.1. Routing Performance 551 One of the criteria for selecting a specific DHT geometry is routing 552 performance, meaning the average number of hops as a function of 553 overlay network size. If we denote the complexity by O and the number 554 of nodes in overlay by N, most architectures assure a number of hops 555 proportional to O*log(N). 557 The routing performance MAY be improved by parallel queries, which 558 reduce the delay impact of contacting a dead node. 560 Req 7-5: The peer protocol MUST accommodate a DHT for a fast routing 561 algorithm that minimizes hop count to the root node. The routing 562 algorithm MUST assure real time information retrieval. This also 563 means that the delay of the information retrieval MUST be acceptable 564 to users. 566 There are two fundamental types of neighbor nodes: 568 o Neighbor nodes in the hash table key space. Chord for example 569 defines its neighbors as the successor nodes from itself [17], 570 while Pastry [15] and Bamboo [18] define the so called leaf nodes 571 that are at an equal distance before and after itself on the 572 circle. Kademlia uses the mathematical distance based on XOR metric 573 [19]. Such neighbor nodes may however be widely dispersed across 574 the underlying IP network and this fact guarantees good geographic 575 diversity. 577 o Neighbor nodes learned from the routing process in various searches 578 that have terminated on the target root node. In Pastry and Bamboo 579 the target root node makes a neighborhood list and can apply 580 various routing metrics such as delay, number of IP hops or 581 bandwidth to select the closest known peers. This is an extremely 582 valuable feature for real time communications. 584 Req 7-6: The number of neighbor nodes MUST be selected high enough to 585 insure the the loss of connectivity to a few nodes does not 586 disconnect the peer and cause loss of data (although replication 587 should mitigate this). 589 Req 7-7: The protocol DHTs MUST have the capability of applying 590 various routing metrics in selecting neighbor nodes. Latency based 591 neighbor selection (for example for use in NAT traversal) for SIP 592 based real time communications SHOULD be supported by the peer 593 protocol. 595 7.5.2. Routing Tables and Routing State 597 The number and size of routing tables varies for the different DHT 598 types. Some DHTs keep only a table of logarithmically distributed 599 peers, where others keep additional information. For example, Pastry 600 and Bamboo have the following: 602 o A routing table of known live peers. This table is used to 603 execute fast search requests from other peers. 604 o A list of the leaf set with its identifiers and IP addresses. 605 The leaf set is used for accuracy in finding the root. 606 o A neighborhood set selected by some routing metric, such as 607 delay. 609 Routing state is understood here to mean the total data amount stored 610 in the routing tables. 612 The routing state has to be maintained under churn. Devices may learn 613 this by a number of ways, including from the routing events or/and by 614 querying other nodes for their availability. The DHT maintenance 615 mechanism may require setting up and maintaining TCP or TLS 616 connections with neighbor nodes or other nodes in the routing tables. 618 In all battery-powered devices such as laptops, mobile phones, PDAs, 619 or WiFi phones, power management is one of the key issues. The power 620 consumption may be impacted by maintenance of the routing state and 621 by the handling of lookups. These two mainly affect the idle state. 622 The idle state represent a state when P2PSIP peer software runs in a 623 battery-powered device but a user does not use any services provided 624 by the P2PSIP overlay. The power consumption in the idle state 625 determines how long a battery-powered device can stay online without 626 recharging. Similarly, small capacity devices such as low-end desktop 627 phones may have limited CPU and/or memory capacity. These limitations 628 may result in different requirements for DHTs. 630 Req 7-8: The size of the routing state, that is the greedy routing 631 table plus the tables of neighbor nodes SHOULD be kept equal or 632 minimally larger than required by the routing table for the [14] 633 routing protocol and MUST not grow faster than the log of the P2P 634 overlay size. Note however that this does NOT mean that it must be 635 the log of the maximum size possible (for example, 160 neighbors for 636 systems using 2^160 hash size) of the overlay, since this may be 637 impractical (and undesirable) for small networks such as ad-hoc or 638 enterprise. It also does NOT mean that additional neighbors may not 639 be stored to improve efficiency if capacity is available. Because 640 routing efficiency and local storage used are tradeoffs that may vary 641 for different deployments, the balance of this is left to the various 642 DHTs used (or the overlay designer) 644 Req 7-9: The maintenance of the routing state MUST consume minimum 645 node and network resources. 647 7.5.3. Iterative and Recursive Routing Styles 649 Routing in the hash identifier space can be iterative or recursive, 650 each having its advantages and drawbacks depending on the 651 application. 653 o Iterative routing allows the source to control the routing process. 654 The source peers can apply logic for security by checking the 655 routing integrity. The number of NAT traversals is smaller and NAT 656 traversal may be therefore easier. Besides the iterative routing 657 offers increased robustness against message loss since the message 658 is not relayed by many nodes in the overlay. The disadvantage of 659 iterative routing is higher message traffic at the source and a 660 slightly higher search delay. Further, iterative routing over TCP 661 may result in establishing a per-hop TCP connection. 663 o Recursive routing is performed hop by hop and its advantages are 664 that it is faster and has lower message traffic at the source. The 665 disadvantage of recursive routing is a higher vulnerability to 666 malicious nodes, since the routing integrity cannot be checked at 667 the source, lower robustness against message loss and possibly 668 higher number of required NAT traversals. 670 Other mechanisms (such as strictly forward routing) may also be 671 appropriate and should be considered for incorporation here. 673 Note that because various circumstances (such as the presence of 674 NATs) may only occur on some links, the protocol must allow a mixture 675 of these routing mechanisms. 677 7.5.4. Handling of Join/Leave (Churn) 679 We define here the metrics of churn [20] that is relevant for SIP 680 applications using as background the application scenarios for 681 P2PSIP. There are two distinctive metrics for churn: 683 o Time online: The length of time when a peer node is online for the 684 purpose of a real time communication session. This includes: 685 o The length of time a mobile device is online 686 o A PC online where the user is monitoring the presence list 687 for buddies of interest or some other SIP events not 688 related to real time communications 689 o A network access device for a residential or enterprise 690 network, which may be very nearly "always on". 692 o Lifetime: The length of time during which a peer node may appear 693 online. This happens between the time of enrollment and when 694 leaving the P2P service. 696 Churn in P2P networks has been studied extensively for various 697 applications, but unfortunately not for SIP applications. At this 698 point in time, we have to rely on studies on the handling of churn 699 that have been done for other applications on various P2P systems. 701 The handling of peer nodes joining and leaving the overlay is a most 702 critical decision. Various DHT algorithms have very different 703 procedures for new nodes joining the overlay and leaving, mostly 704 suddenly the overlay. Dealing with nodes leaving the overlay is more 705 difficult. For example: 707 o Chord has a stabilization protocol that runs in the background to 708 check the successor nodes. 710 o Pastry and Bamboo perform periodic check to verify the existence of 711 the neighbor nodes and modify the routing tables accordingly. 713 Both Chord and Pastry may have additional algorithms for handling 714 churn. 716 Reported test results include [23] comparing Chord and Bamboo for the 717 latency of routing versus session time between active nodes. Note 718 that such comparisons do not provide the whole picture in the 719 presence of network impairments. 721 There are too many differing factors to compare between differing 722 architectures and the effects of various features are hard to 723 isolate. For this reason, it is not practical comparing the 724 architectural differences of the various DHT implementations but 725 rather focus on the important issues in handling churn. Simulations 726 and testing can eliminate DHT types that show no promise and help in 727 selecting a candidate DHT for the "must implement" DHT. Again, 728 requiring modularity in DHT selection for the protocol can prevent 729 the protocol from being tied to a poor choice or limited to only be 730 appropriate for certain deployments. 732 Req 7-10: The default DHT selected for the peer protocol MUST 733 incorporate techniques for handling churn. Joining, leaving, or 734 searching the P2P overlay under high churn condition SHOULD not be 735 significantly slower than these operations in the absence of churn. 737 7.5.5. Enabling Mobility 739 Handling nodes leaving the overlay introduces an additional traffic 740 overhead in the overlay and also requires additional processing power 741 to modify information in routing tables. When a peer rejoins the 742 overlay network the overlay may have to perform more operations than 743 in the case when a peer leaves a network. Additionally, updates to 744 the DHT do not take place immediately after a node leaves. 746 Laptop computers, mobile phones, PDAs, and WiFi phones may move from 747 one network to another by doing handover between different access 748 networks or moving from one WLAN access point to another. When doing 749 handover they may loose connectivity to the overlay for a short 750 period of time. Most important for mobility is the fact they may 751 receive a new IP address from the new access network. 753 In some DHTs a peer ID is based on the IP address. This means that 754 when a node receives a new IP address it must also receive a new peer 755 ID. This is equivalent to a node leaving the overlay network and 756 joining it again. This may cause network instability and require 757 additional resources to handle network adaptation (as explained 758 above). This has impact on battery life of battery-powered as well as 759 on system reliability. In the transition period search delay for user 760 contact information may be higher, delaying the call establishment. 761 For these reasons, the node ID SHOULD not depend on the IP address. 763 The peer protocol SHOULD support a mechanism for DHTs that allows 764 network nodes to freely move from one access network to another 765 without a need to reconfigure their peer IDs and without changes in 766 the overlay network topology such as changes in neighboring sets or 767 contacts in the routing tables. This requires only that the new 768 address of a moving node propagates in real-time to the rest of the 769 peers that need that information. 771 Req 7-11: The peer protocol MUST not interfere with mobility. A DHT 772 MUST be available that supports mobility to allow network nodes to 773 freely move from one access network to another without causing 774 changes in the overlay network topology and decreasing routing 775 performance. The information about new address of a node MUST 776 propagate in real-time to the rest of the peers that need that 777 information. 779 7.5.6. Fault Tolerance to Non-Transitive Connectivity 781 The various DHT architectures assume all peer nodes can communicate 782 at all times but this is not true in practice [21]. The Internet has 783 transient failures of connectivity due to link failures, route 784 flapping due to equipment maintenance, faulty BGP routing table 785 updates and ISP disputes. During such transient failures, pairs of 786 nodes such as node A and node B can communicate with node C, but 787 cannot communicate with each other. This is called non-transitivity. 788 In addition, the presence of NATs can lead to systemic and semi- 789 permanent non-transitivity. 791 Extensive testing on Planet Lab that includes nodes on Internet1, 792 Internet2 and multihomed nodes has shown amounts of non-transitivity 793 than can lead to significant problems for various types of DHT. Note 794 this occurs even on Planet Lab, which is relatively closed, high 795 quality, NAT-free academic environment which is far more forgiving 796 than real-world deployments are likely to be. 798 Non-transitivity is actually rather the rule than the exception on 799 the Internet since most peer nodes are likely to reside behind one or 800 more NATs. The section on NAT traversal deals more with this aspect. 802 Firewalls can be another cause for non-transitivity, but we assume 803 the network administrator will configure firewalls to pass P2PSIP 804 messages if this behavior is desired. If local policy should prohibit 805 the firewall to pass P2PSIP messages then it is not our intent to 806 write standards requirements to circumvent local firewall policy. 808 The problems arising due to non-transitivity include the following: 810 o Invisible nodes when a peer learns about a node but cannot 811 communicate with it 812 o Routing loops when a search skips a node around the virtual circle 813 in some implementations 814 o Broken return paths. This may happen when the root node holding the 815 information is found by using recursive routing and the result is 816 sent back directly to the source node, but there is no connectivity 817 between them. 818 o Inconsistent roots. The correctness of the key space can be 819 affected if two nodes that cannot see each other believe each to be 820 the correct root during a lookup. 822 Various DHT systems have different specific remedies to counter non- 823 transitivity. 825 Req 7-12: DHTs designed for use with the P2PSIP protocol MUST take 826 into consideration non-transitivity on the Internet. 828 7.6. Implementation Experience in Selecting DHTs 830 A significant aspect in choosing a DHT for P2PSIP is the glaring 831 contrast between the huge number of research papers versus the 832 extremely limited DHT overlays that have actually been deployed in 833 large scale systems on the Internet. 835 There are other considerations as well, besides the routing aspects 836 in choosing a DHT, such as: 838 o To what degree has a particular DHT been deployed and tested in 839 large scale systems over the Internet? 840 o To what a degree has a particular DHT been researched in depth and 841 the research results made public? 842 o To what degree has a DHT been used for various significant 843 applications and can their use be extrapolated for P2PSIP? 845 Bamboo was deployed on the openDHT network on Planet Lab. Kademlia is 846 the only DHT that was deployed in a large scale commercial systems. 848 Req 7-13: The DHT selected for the default DHT MUST be based on 849 operational experience from large scale systems and measurements on 850 the Internet or significant testing and research involving multiple 851 peers. 853 7.7. Simplicity of Implementation in Selecting a DHT 855 Selecting a DHT as the "must implement" must also take into account 856 the fact that many developers will be independently building 857 implementations. While any algorithm, even one of arbitrary 858 complexity, may work, and may even be more efficient, the likelihood 859 of two independent implementations functioning properly together 860 decreases greatly as the algorithm's complexity increases. While 861 efficiency is extremely important, the "must implement" should be a 862 safe fall back that can be easily and correctly implemented. More 863 complex DHTs can be employed as additional DHTs. 865 Req 7-14: The DHT selected as the default DHT MUST be as simple and 866 easy to implement as possible, while addressing the majority of 867 requirements above. 869 This selection MUST be driven by an understanding of the difficulty 870 of different developers producing interoperable, running code. 872 7.8. Discussion on the Selection of a DHT Overlay 874 Picking one or a small selection of DHT overlays for P2PSIP is a 875 difficult proposition, given the very large number of solutions 876 developed in the research community. To overcome this difficulty it 877 is useful to look first at the important properties of various DHT 878 without going into all the specific details for each. After choosing 879 the key properties, various DHT can be compared as has been done in 880 [22], [23]. The selection of a DHT for P2PSIP MUST be based on a 881 thorough comparison and discussions in the IETF P2PSIP WG. 883 There are a large selection of DHT geometries, including the ring 884 geometry, the XOR geometry, the tree and hypercube. Some DHT such as 885 Pastry feature a dual geometry of both ring and tree. It is beyond 886 the scope of this memo to discuss in detail the various geometries 887 and we prefer to reference key literature on this topic. A detailed 888 mathematical analysis of the various geometries in [23] shows the 889 ring and XOR geometries to have the best performance using the above 890 criteria, with the ring geometry showing a slight advantage. 892 8. Client Protocol Requirements 894 Note: While it is not yet clear if a Client protocol will be required 895 (a number of members of the WG, and even some of the authors of this 896 document, feel conventional SIP may be enough, although it is too 897 early to tell), if one is required, the following requirements would 898 apply to this protocol. 900 One assumption of DHT networks on the Internet could be that the 901 network nodes are homogenous, and they have enough processing power 902 and memory to run DHT networks without any limits. This assumption 903 does not hold however if we consider mobile devices such as mobile 904 phones, PDAs, or WiFi phones. Mobile devices are heterogeneous. Low- 905 end devices may have a little memory, a slow CPU and may not support 906 fast packet radio interfaces. On the other hand, high-end devices may 907 have significantly higher capabilities: Fast radio interfaces, more 908 memory and faster CPU then they their less advanced counterparts. 910 From this reason we can classify network nodes into two categories: 911 Mainly those that have enough CPU power, memory and fast network 912 interface to run P2PSIP peer protocol and those that may not have 913 enough capabilities to become P2PSIP peers. 915 Additionally, if we consider the issue of NAT traversal, a very 916 powerful mobile device can be behind a restrictive NAT. This may 917 require the device to establish a TCP or TLS connection towards a 918 TURN server. If the connection has to be maintained for a long 919 period, it may drain the device battery. From these reasons, not all 920 battery powered devices though having enough capabilities to run the 921 peer protocol will still not be able to become P2PSIP peers. 923 Essentially, any DHT overlay network can support two basic 924 operations: PUT and GET. In the P2PSIP overlay a PUT operation is 925 used to insert, modify, or delete data in the overlay,such as user or 926 resource records. A GET operation is used to retrieve data stored in 927 the overlay. Clients should be able to store, modify, delete and 928 retrieve user and resource records from the overlay; in the P2P 929 language they must support PUT and GET operations. 931 Req 8-1: The client protocol MUST allow nodes that are not eligible 932 to become peers to store, modify, delete and retrieve user and 933 resource records stored in the P2PSIP overlay. 935 In all kinds of battery-powered devices such as laptops, mobile 936 phones, PDAs, or WiFi phones power management is one of the key 937 issues. As discussed in this section and section 8.7.2 traffic 938 introduced by the overlay protocols may significantly reduce the 939 battery life of battery powered devices. This does not allow some of 940 the nodes to become peers. Those devices will have to act as clients 941 and implement the client protocol that conserves the client's 942 battery. 944 Req 8-2: The client protocol must be efficient enough to conserve the 945 client's battery. 947 As mentioned, there are many situations when powerful mobile devices 948 cannot be elected as peers. This may happen, e.g. if the access 949 network provides a small bandwidth interface or if the user is not 950 willing to assume the cost of increased bandwidth consumption related 951 to the P2PSIP application. 953 Req 8-3: The client protocol MUST introduce low message traffic to 954 preserve bandwidth. 956 User and resource records may include different data that may be of 957 no use to some applications. Transferring all of the data stored in 958 user and resource records over the network interface (especially over 959 the air interface) may be undesirable in some situations since it 960 will increase traffic in the network. Additionally a user may make 961 only small changes to its own records stored in the overlay. In this 962 case it should be possible to update only a part of the user record 963 stored in the overlay without a need of uploading the whole user 964 record to the responsible peer. 966 From these reasons, there should be a mechanism to allow clients to 967 indicate what data they want to modify, delete, or retrieve. 969 Req 8-4: The client protocol MUST enable peer clients to selectively 970 indicate the data they are interested on. The clients MUST be able to 971 retrieve, modify or delete a selected part of user and resource 972 records. 974 In order to support the iterative routing style the client protocol 975 must support redirection from a peer to another peer or other network 976 node. The peer must be able to send redirect response to a request 977 originated by a client with the address of a node that is better 978 suited to handle the request. 980 Req 8-5: The client protocol MUST support redirection of requests 981 from one peer to another network node. 983 8.1. Discussion about the Client Protocol 985 The realisation of the client protocol may have many forms. The 986 widely deployed protocols on the Internet that are used to manipulate 987 data stored remotely are using HTTP as the transport and such as the 988 XML data format as the encoding. A Remote Procedure Call (RPC) 989 protocol such as XML RPC is one of the options for the client 990 protocol. XML RPC [24] is used in OpenDHT [25] deployed in Planet Lab 991 [26] that is designed to support long-running services for a client 992 base. This protocol is also proposed in [28] as an ASCII based client 993 protocol. A binary protocol is yet another possibility. 995 In this option SIP is used for multimedia session establishment 996 between endpoints whereas XML RPC or a similar protocol is used as a 997 lookup protocol providing an access to SIP data stored in the P2PSIP 998 overlay that is required to setup a multimedia session. 1000 Another option is to send XML documents in SIP messages or modify SIP 1001 to support functionality needed for the client protocol. It has been 1002 noted that SIP is a session establishment protocol, not a generic 1003 lookup protocol; therefore it should not be used for general Remote 1004 Procedure Call (RPC). 1006 It seems to be a more reasonable solution to support conventional SIP 1007 UAs (unmodified SIP devices). In this alternative the P2PSIP overlay 1008 would have to appear as a conventional SIP network to SIP UAs. This 1009 solution does not require any changes to the existing SIP devices, 1010 which can use SIP services provided by the overlay without even 1011 noticing its existence. However it introduces the very strict 1012 requirement that every peer in the P2PSIP overlay implements the SIP 1013 proxy and redirect server functionality. 1015 The P2PSIP overlay may include STUN/TURN servers that do not 1016 implement a SIP stack but may assist peers/SIP UA in NAT traversal. 1017 These servers must be allowed to register to the DHT and advertise 1018 their services. 1020 It is also possible to combine a client protocol with support for 1021 conventional SIP devices. In this scenario some of the peers would 1022 include a co-located SIP proxy server which implements a P2PSIP API 1023 that allows them to PUT/GET information to/from the overlay on behalf 1024 of unmodified SIP devices. All of the peers (or the subset of 1025 thereof) would implement the (different) client protocol to support 1026 requests. 1028 End users and P2P operators may have an equal or even bigger interest 1029 in various other non-SIP applications compared to P2PSIP only. For 1030 this reason, the Client Protocol may be enabled with other interfaces 1031 to the DHT, such as described in [30]. Such interfaces are however 1032 beyond the scope of P2PSIP WG. 1034 9. Security Considerations 1036 P2PSIP security [29] can be decomposed into several parts: 1038 o DHT security 1039 o SIP security 1040 o Client protocol security 1041 o Security of the SIP-DHT interface. 1043 It is a good idea to keep these parts as independent as possible, 1044 though as we will see, DHT security can be enhanced by strong 1045 authentication provided in the SIP application layer. 1047 9.1. DHT Security 1049 The specific security issues for large public P2P networks stem from 1050 the fact that mutually distrusting parties must be able to join the 1051 overlay network in spite of having possibly conflicting interests. 1052 This is also true for large closed P2P networks [30]. 1054 A fraction of the nodes may act maliciously and cause the following 1055 problems: 1057 o Misrouted, corrupted or dropped messages, 1058 o Corrupted routing information, 1059 o False identities being presented to the other peers, 1060 o Corrupting or deleting data they are supposed to store. 1062 1. The attacker should not be able to easily corrupt, delete, or 1063 overwrite data stored in the P2PSIP overlay, the data stored in 1064 routing tables as well as user records. In order to achieve this, the 1065 node ID assignment process should make sure that a single user 1066 receives only one node ID. Once assigned, the node ID should be 1067 difficult to change. These two requirements prevent the so-called 1068 Sybil [31] attacks, where a malicious party obtains a large number of 1069 valid node IDs. Several measures can be taken by the enrollment 1070 process, for example: 1071 rd o Strong identity such as employment or provided by 3 party, 1072 o Charging for the enrollment, 1073 o Trust may be a useful tool in very large P2PSIP networks [32]. 1075 2. It should be possible to verify integrity of data stored in the 1076 overlay by comparing data with neighbor nodes or by checking the 1077 consistency of the routing tables. 1079 3. It should be possible to verify integrity of data stored in the 1080 overlay by comparing data with neighbor nodes or by checking the 1081 consistency of the routing tables. 1083 4. Signature mechanisms can be used to verify data has not been tampered 1084 with while stored. 1086 The security mechanisms should scale from a few nodes to an overlay of 1087 many millions of nodes across the globe. Because of the nature of 1088 P2PSIP the security mechanism SHOULD NOT depend on centralized servers 1089 except for a central certificate authority such as from the P2P overlay 1090 operator. Self signed certificates may also be deployed. 1092 Req 9-1: The security of the underlying DHT in P2P SHOULD use one or a 1093 combination of all four DHT specific security techniques: 1095 1. Secure node IDs obtained from the enrollment server 1096 2. Secure routing table maintenance by checking the routing tables with 1097 the neighbors 1098 3. Secure message forwarding using various failure tests, such as 1099 comparing responses from different nodes when using different source 1100 nodes to launch a request. 1101 4. Originator signed data. 1102 Trust [32] MAY also be used to reduce the reliance on the above 1103 security tools. 1105 9.2. SIP Security 1107 The minimal requirements for SIP security for both client-server and 1108 peer-to-peer modes are detailed in [33]. 1110 9.3. Client Protocol Security 1112 The client protocol must allow nodes that are not eligible to become 1113 peers to securely store, modify, delete and retrieve user and resource 1114 records stored in the P2PSIP overlay. This includes the following 1115 operations: 1117 1. Authentication 1119 2. Access rights assignment 1121 3. Integrity protection 1123 4. Data encryption 1125 The client protocol must support a method for clients and peers to 1126 authenticate each other. This is important in a distributed scenario 1127 where a client may connect to different unknown peers. The client should 1128 be able to verify that the peer it is connecting to belongs to the 1129 desired overlay. On the other hand the server should also be able to 1130 authenticate the client. Some widely deployed cryptographic protocols 1131 such as (D)TLS use a certificate based authentication. 1133 Req 9-2: The client protocol must support mutual authentication between 1134 peers and clients. The authentication method MUST be implemented by 1135 peers and clients and SHOULD be used by these entities. 1137 The client protocol must support a method that allows setting access 1138 rights to the resources stored in a DHT. When inserting a new user or 1139 resource record into the DHT, the client should be able to allow one or 1140 more network entities to perform one or more of the following 1141 operations: modify, delete, and override the inserted record. 1143 Req 9-3: The client protocol MUST allow setting access rights to the 1144 resources stored in a DHT. 1146 The peer should be able to validate that the data received from a client 1147 was not altered. It should be also possible for a client to verify 1148 integrity of data retrieved from the overlay. 1150 Req 9-4: The client protocol MUST support integrity protection of the 1151 data being inserted or retrieved to/from an overlay. 1153 The clients should be provided with option to encrypt data exchanged 1154 with peers, and vice versa. 1156 Req 9-5: The client protocol SHOULD support data encryption. 1158 9.4. Security of the SIP-DHT Interface 1160 Besides the security of the P2PSIP overlay itself that we have discussed 1161 in the sections 10.1 and 10.2, the security of the interface between SIP 1162 and the DHT is also a matter of concern. 1164 Two main attack scenarios have been identified between the DHT and 1165 applications that use it [30]: 1167 o Squatting: Use a valuable key ("coca-cola.com"), similar to domain 1168 names 1170 o Drowning: Putting a vast number of values for the same key. 1172 The security design for the interface to deal with the above can be 1173 summarized as in the following example 1175 1. Authentication 1176 o Assumes the existence of a private + public crypto key pair 1177 o Verify that an authorized and/or trusted entity wrote a value 1178 o A node protects its own value from overwriting. 1180 2. Publish security 1181 o The publishing node signs the key/value pair. 1183 3. Lookup security 1184 o A node verifies the data returned by the Lookup operation. 1186 4. Remove security 1187 o A node verifies the credentials of the requestor to remove 1188 data. 1190 Req 9-5: The interface between SIP and the DHT MUST be secured in 1191 case the P2PSIP client is connecting to peer nodes of the P2PSIP 1192 networks or when an external DHT is used: 1194 9-5 a. Authentication credentials MUST be presented, and 1196 9-5 b. All commands to the peer must be secured by encryption and 1197 digital signatures. 1199 10. IANA Considerations 1201 This document has no actions for IANA. 1203 11. Conclusions 1205 The requirements for P2PSIP point to a complex protocol, especially 1206 when choosing a high performing DHT layer that includes system 1207 design based on operational experience and measurements. 1209 NAT traversal and security add to the complexity of P2PSIP. 1211 Given however that all peers run essentially the same software and 1212 P2PSIP is a self organizing network, the operational complexity and 1213 cost is expected to be much less that conventional client-server 1214 SIP networks. 1216 12. Acknowledgments 1218 The authors would like to thank Kundan Singh for useful input to 1219 this document and also for reviewing parts of the draft. In 1220 addition, the many people of the IETF P2PSIP WG that have 1221 contributed to discussions or drafts were invaluable in assembling 1222 this document. 1224 Jiang XingFeng has made valuable comments to this document. 1226 This document was prepared using 2-Word-v2.0.template.dot. 1228 13. References 1230 13.1. Normative References 1232 [1] RFC 3263, "Session Initiation Protocol (SIP): Locating SIP 1233 Servers", by J. Rosernberg and H. Schulzrinne, June 2002. 1235 13.2. Informative References 1237 [2] Home page for the P2PSIP WG: http://tools.ietf.org/wg/p2psip/ 1239 [3] Bryan, D., Matthews, P., Shim, E. and Willis, D: "Concepts and 1240 Terminology for Peer to Peer SIP", draft-willis-p2psip- 1241 concepts-04 (work in progress), http://www.ietf.org/internet- 1242 drafts/draft-willis-p2psip- concepts-04.txt, March 2007. 1244 [4] D. Bryan et al: "Use Cases for Peer-to-Peer Session Initiation 1245 Protocol (P2P SIP)", I-D, IETF November 2005. 1247 [5] David A. Bryan, Bruce B. Lowekamp, and Cullen Jennings, 1248 SOSIMPLE: A Serverless, Standards-based, P2P SIP Communication 1249 System (pdf), Proceedings of the 2005 International Workshop on 1250 Advanced Architectures and Algorithms for Internet Delivery and 1251 Applications (AAA-IDEA 2005), June 2005 1253 [6] "State of P2P Communication Across NATs" by P. Srisuresh et al. 1254 Internet Draft, IETF, February 2007. 1256 [7] "Interactive Connectivity Establishment (ICE)" by J. Rosenberg. 1257 Internet Draft (Version 15), March 2007. 1259 [8] "NAT Classification Results using STUN" by C. Jennings. 1260 Internet Draft, IETF, October 2004 (archive). 1262 [9] "Obtaining Relay Addresses from Simple Traversal Underneath NAT 1263 (STUN)" by J. Rosenberg. Internet Draft, IETF, March 2007, work 1264 in progress. 1266 [10] "The Effects of NATs on the P2P Overlay Architecture" by E. 1267 Cooper and P. Matthews. Internet-Draft, IETF March 2007, work 1268 in progress. 1270 [11] "Scribe: A large-scale and decentralized application level 1271 multicast infrastructure" by M. Castro et al. IEEE Journal on 1272 Selected Areas in Communications, October 2002. 1273 http://freepastry.org/PAST/jsac.pdf 1275 [12] "A Survey and Comparison of End-System Overlay Multicast 1276 Solutions Suitable for Network Centric Warfare" by Cristina 1277 Abad et al., NCSA and CS University of Illinois, SPIE 2004. 1279 [13] "A Survey and Comparison of Peer-to-Peer Overlay Network 1280 Schemes" by E.K. Lua et al. IEEE, March 2004. 1281 http://www.cl.cam.ac.uk/teaching/2005/AdvSysTop/survey.pdf 1283 [14] "openDHT: A Public DHT Service, Ph.D. Thesis by Sean C. Rhea, 1284 2005 http://srhea.net/papers/rhea-thesis.pdf 1286 [15] "Pastry: Scalable, decentralized object location and routing 1287 storage for large-scale peer-to-peer systems" by A. Rowstron 1288 and P. Druschel. Proceedings of the IFIP/ACM , Nov. 2001. 1290 [16] "Scalable peer-to-peer substrates: A new foundation for 1291 distributed applications?" by P. Druschel and A. Rowstron. Rice 1292 University and Microsoft Research. 1294 [17] The Chord Project, see http://pdos.csail.mit.edu/chord/ 1296 [18] "The Bamboo Distributed Hash Table" web site at http://bamboo- 1297 dht.org/ 1299 [19] "Kademlia" A Peer-to-peer Information System Based on XOR 1300 Metric" by P. Mamounkov and D. Mazieres. Rice University 2002. 1301 http://www.cs.rice.edu/Conferences/IPTPS02/109.pdf 1303 [20] "Handling of Churn in a DHT" by S. Rhea et al. USENIX Annual 1304 Technical Conference, June 2004. 1306 [21] "Non-Transitive Connectivity and DHTs" by M. Freedman et al. 1307 Workshop on Real Large Distributed Systems conference 2005. 1309 [22] David A. Bryan, Marcia Zangrilli, and Bruce B. Lowekamp, 1310 Challenges of DHT Design for a Public Communications System 1311 (pdf), William and Mary Technical Report WM-CS-2006-03, June 1312 2006. 1314 [23] "The Impact of DHT Routing Geometry on Resilience and 1315 Proximity" by K. Gummadi et al. SIGCOMM conference 2003, 1316 Karlsruhe, Germany. 1317 http://www.sigcomm.org/sigcomm2003/papers/p381-gummadi.pdf 1319 [24] XML-RPC, online at : http://xmlrpc.com 1321 [25] "OpenDHT", online at: http://www.opendht.org 1323 [26] "PlanetLab", online: http:// https://www.planet-lab.org 1325 [27] S. Baset and H. Schulzrinne: "Peer-to-Peer Protocol (P2PP)", 1326 Internet Draft, IETF, February 2007, work in progress 1328 [28] K. Singh and H. Schulzrinne: "Data format and interface to an 1329 external peer-to-peer network for SIP location service", I-D, 1330 IETF, May 2006, expired. 1332 [29] "Security requirements in P2PSIP" by M. Matuszewski et al. 1333 Internet-Draft, IETF, Feb. 2007, work in progress. 1335 [30] S. Rhea, et al: "Open DHT: A Public DHT Service and Its Uses", 1336 SIGCOMM'05, 2005. http://www.sigcomm.org/sigcomm2005/paper- 1337 RheGod.pdf 1339 [31] Douceur, J., "The Sybil Attack", IPTPS '02, March 2002. 1341 [32] "P2P Trust Infrastructure" by R. Nelson et al. UCLA report, 1342 2/13/2005. http://www.cs.ucla.edu/~rlnelson/trust.pdf 1344 [33] "Simple SIP Usage Scenario for Applications in the Endpoints" 1345 by H. Sinnreich et al. Internet-Draft, IETF, Sep. 2007, work in 1346 progress. 1348 Author's Addresses 1350 David A. Bryan 1352 SIPeerior; William & Mary 1354 3000 Easter Circle 1356 Williamsburg, VA 23188 1358 USA 1360 Email: bryan@ethernot.org 1362 Marcin Matuszewski 1364 Nokia 1366 P.O.Box 407 1368 NOKIA GROUP, FIN 00045 1370 Finland 1372 Email: marcin.matuszewski@nokia.com 1373 Salman A. Baset 1375 Dept. of Computer Science 1377 Columbia University 1379 1214 Amsterdam Avenue 1381 New York, NY 10027 1383 USA 1385 Email: salman@cs.columbia.edu 1387 Henry Sinnreich 1389 Adobe Systems Incorporated 1391 601 Townsend Street 1393 San Francisco, CA 94103 1395 USA 1397 Email: henrys@adobe.com 1399 Intellectual Property Statement 1401 The IETF takes no position regarding the validity or scope of any 1402 Intellectual Property Rights or other rights that might be claimed to 1403 pertain to the implementation or use of the technology described in 1404 this document or the extent to which any license under such rights 1405 might or might not be available; nor does it represent that it has 1406 made any independent effort to identify any such rights. Information 1407 on the procedures with respect to rights in RFC documents can be 1408 found in BCP 78 and BCP 79. 1410 Copies of IPR disclosures made to the IETF Secretariat and any 1411 assurances of licenses to be made available, or the result of an 1412 attempt made to obtain a general license or permission for the use of 1413 such proprietary rights by implementers or users of this 1414 specification can be obtained from the IETF on-line IPR repository at 1415 http://www.ietf.org/ipr. 1417 The IETF invites any interested party to bring to its attention any 1418 copyrights, patents or patent applications, or other proprietary 1419 rights that may cover technology that may be required to implement 1420 this standard. Please address the information to the IETF at 1421 ietf-ipr@ietf.org. 1423 Disclaimer of Validity 1425 This document and the information contained herein are provided on an 1426 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1427 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1428 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1429 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1430 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1431 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1433 Copyright Statement 1435 Copyright (C) The IETF Trust (2007). 1437 This document is subject to the rights, licenses and restrictions 1438 contained in BCP 78, and except as set forth therein, the authors 1439 retain all their rights. 1441 Acknowledgment 1443 Funding for the RFC Editor function is currently provided by the 1444 Internet Society.