idnits 2.17.1 draft-willis-p2psip-concepts-01.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 23. -- Found old boilerplate from RFC 3978, Section 5.5 on line 833. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 844. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 851. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 857. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (August 18, 2006) is 6460 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1738 (ref. '2') (Obsoleted by RFC 4248, RFC 4266) == Outdated reference: A later version (-03) exists of draft-bryan-sipping-p2p-02 == Outdated reference: A later version (-01) exists of draft-irtf-p2prg-survey-search-00 == Outdated reference: A later version (-16) exists of draft-ietf-behave-turn-00 == Outdated reference: A later version (-20) exists of draft-ietf-sip-outbound-03 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group D. Willis, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Experimental D. Bryan 5 Expires: February 19, 2007 P2PSIP.org and William and Mary 6 Department of Computer 7 Science 8 P. Matthews 9 Avaya 10 E. Shim 11 Panasonic Digital Networking 12 Laboratory 13 August 18, 2006 15 Concepts and Terminology for Peer to Peer SIP 16 draft-willis-p2psip-concepts-01 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on February 19, 2007. 43 Copyright Notice 45 Copyright (C) The Internet Society (2006). 47 Abstract 49 This document defines concepts and terminology for use of the Session 50 Initiation Protocol in a peer-to-peer environment where the 51 traditional proxy-registrar function is replaced by a distributed 52 mechanism that might be implemented using a distributed hash table or 53 other distributed data mechanism with similar external properties. 54 This document includes a high-level view of the functional 55 relationships between the network elements defined herein, a 56 conceptual model of operations, and an outline of the related open 57 problems that might be addressed by an IETF working group. 59 Requirements Language 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in [1]. 65 Table of Contents 67 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 3.1. What Kinds of P2PSIP Overlay Peers and Clients Might 73 Exist? . . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 3.2. Reference Model . . . . . . . . . . . . . . . . . . . . . 10 75 3.3. Conceptual Outline of Operations . . . . . . . . . . . . . 12 76 3.3.1. Enrolling and Inserting an P2PSIP Overlay Peer . . . . 12 77 3.3.2. More on The Difference Between a Peer, Client, and 78 User Agent . . . . . . . . . . . . . . . . . . . . . . 12 79 3.3.3. Enrolling a User and Inserting a P2PSIP Overlay 80 User Agent . . . . . . . . . . . . . . . . . . . . . . 13 81 3.3.4. Placing a Call from a P2PSIP Overlay Client UA to 82 a P2PSIP Overlay Client UA . . . . . . . . . . . . . . 14 83 3.3.5. Bootstrapping . . . . . . . . . . . . . . . . . . . . 14 85 4. Questions . . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 4.1. Definition of P2PSIP Overlay Peer Enrollment . . . . . . . 15 87 4.2. PP2PSIP Overlay Peer Protocol . . . . . . . . . . . . . . 15 88 4.3. P2PSIP Overlay Client Protocol . . . . . . . . . . . . . . 15 89 4.4. Universal Routing: . . . . . . . . . . . . . . . . . . . . 15 90 4.5. How To Find Media Relays? . . . . . . . . . . . . . . . . 15 91 4.6. How Do We Find Gateways? . . . . . . . . . . . . . . . . . 16 92 4.7. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 16 93 4.8. Peer-Adjacency Through NATs . . . . . . . . . . . . . . . 16 94 4.9. Cryptotransparency . . . . . . . . . . . . . . . . . . . . 16 95 4.10. Record Formats . . . . . . . . . . . . . . . . . . . . . . 16 96 4.11. Peer and Client Enrollment Protocols . . . . . . . . . . . 16 97 4.12. Peer and User Credentials . . . . . . . . . . . . . . . . 16 98 4.13. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 17 99 4.14. Credential Recovery . . . . . . . . . . . . . . . . . . . 17 100 4.15. Overlapping Domains . . . . . . . . . . . . . . . . . . . 17 101 4.16. Hybrid Domains . . . . . . . . . . . . . . . . . . . . . . 17 102 4.17. Admissions Control . . . . . . . . . . . . . . . . . . . . 17 103 4.18. Users versus Resources . . . . . . . . . . . . . . . . . . 18 105 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 107 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 109 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 111 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 112 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 113 8.2. Informative References . . . . . . . . . . . . . . . . . . 19 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 116 Intellectual Property and Copyright Statements . . . . . . . . . . 21 118 1. Background 120 One of the fundamental problems in multimedia communications between 121 Internet nodes is that of a discovering the IP address at which a 122 given correspondent can be reached. Correspondents are frequently 123 identified by distinguished names, perhaps represented in the form of 124 a universal resource indicator (URI) [2]. 126 The Session Initiation Protocol (SIP) [3] commonly addresses this 127 task assuming that the domain part of the URI indicates an internet 128 host address or internet domain name using the Domain Name System 129 (DNS) [4]. SIP's location process [5] assumes that host part of the 130 URI indicates either the target SIP user agent (UA), or a proxy that 131 has knowledge of how to to reach the target UA, presumably gained 132 through SIP's registration process. 134 This approach, referred to herein as "Conventional SIP" or "Client/ 135 Server SIP", assumes a relatively fixed hierarchy of SIP routing 136 proxies (servers) and SIP user agents (clients). The routing proxies 137 are typically resolvable using conventional Internet mechanisms with 138 static IP addresses and associated DNS entries. This structure may 139 not be ideal in all cases, including specifically ad-hoc, serverless, 140 and reduced-administration scenarios. As an alternative, several 141 authors [7] [8] [9] [10] have proposed using peer-to-peer (P2P) [11] 142 approaches to solving the correspondent discovery problem. 144 This document offers a consolidation of the more important terms and 145 concepts from several of the above documents, presented in the 146 context of a reference model for peer-to-peer SIP (P2PSIP). It is 147 intended that this document serve as a starting point for describing 148 the work needed to resolve a number of open questions such that an 149 IETF working group could be chartered to do the work needed to 150 resolve these questions and present a standard solution. The authors 151 believe that this goal is roughly consistent with that of a Protocol 152 Model as defined in [12]. 154 2. Definitions 156 Defined terms include: 158 Overlay Network: An overlay network is a computer network which is 159 built on top of another network. Nodes in the overlay can be 160 thought of as being connected by virtual or logical links, each of 161 which corresponds to a path, perhaps through many physical links, 162 in the underlying network. For example, many peer-to-peer 163 networks are overlay networks because they run on top of the 164 Internet. Dial-up Internet is an overlay upon the telephone 165 network. 167 P2P Network: A peer-to-peer (or P2P) computer network is a network 168 that relies primarily on the computing power and bandwidth of the 169 participants in the network rather than concentrating it in a 170 relatively low number of servers. P2P networks are typically used 171 for connecting nodes via largely ad hoc connections. Such 172 networks are useful for many purposes. Sharing content files (see 173 file sharing [15]) containing audio, video, data or anything in 174 digital format is very common, and realtime data, such as 175 telephony traffic, is also passed using P2P technology. 176 . A P2P Network may 177 also be called a "P2P Overlay" or "P2P Overlay Network" or "P2P 178 Network Overlay" , since its organization is not at the physical 179 layer, but is instead "on top of" an existing Internet Protocol 180 network. 182 P2PSIP: A communications protocol related to the Session Initiation 183 Protocol (sip) [3] that extends SIP by using peer-to-peer 184 techniques for resolving the targets of SIP requests. 186 P2PSIP Overlay: A P2PSIP Overlay is an association, collection, or 187 federation of nodes that provides SIP registration, SIP request 188 routing, and similar functions using a P2P organization, as 189 defined by "P2P Network" above. Short form: overlay. 191 P2PSIP Overlay Identifier: Information that identifies a specific 192 P2PSIP Overlay. This is presumed in the general case to be scoped 193 to a name within the DNS, but other scopes may apply, particularly 194 in ad-hoc environments. Short forms: overlay identifier, overlay 195 ID. 197 P2PSIP Overlay Peer: A node participating in a P2PSIP Overlay that 198 provides storage and routing services (fully participates in the 199 P2P routing) to other nodes in that P2PSIP Overlay. Each P2PSIP 200 Overlay Peer is presumed to have a unique identifier within the 201 P2PSIP Overlay. Each P2PSIP Overlay Peer may or may not be 202 coupled to one or more P2PSIP Overlay User Agents. Within the 203 P2PSIP Overlay, the peer is capable of performing several 204 different operations, including: joining and leaving the overlay, 205 routing requests within the overlay, storing information on behalf 206 of the overlay, putting information into the overlay, and getting 207 information from the overlay. Short forms: overlay peer, 208 supernode, P2PSIP peer, peer. 210 P2PSIP Overlay Peer Key: Information (perhaps a string, number or 211 URI) that uniquely identifies each P2PSIP Overlay Peer within a 212 given P2PSIP Overlay. These keys are completely independent of 213 identifier of any user of a user agent coupled to a peer. Short 214 forms: P2PSIP peer key, overlay peer key, peer key. 216 P2PSIP Overlay Client: A node participating in a P2PSIP Overlay that 217 provides neither routing nor route storage and retrieval functions 218 to that P2PSIP Overlay. The P2PSIP Overlay Client interacts with 219 the P2PSIP Overlay only to request the insertion of routing 220 information (put in a Contact), request the retrieval of routing 221 information (get a Contact), or to request the routing of a 222 message to elsewhere in the P2PSIP Overlay. Unlike the P2PSIP 223 Overlay Peer, the client is presumed not to have a unique 224 identifier or "key" within the overlay. A P2PSIP Overlay Client 225 may be coupled to one or more P2PSIP Overlay User Agents. Short 226 forms: overlay client, P2PSIP client, client. 228 P2PSIP Overlay User Agent: A SIP user agent that is coupled to a 229 P2PSIP Overlay Peer or P2PSIP Overlay Client, such that the peer 230 or client can assist the UA with registration (storage of a route 231 to users of the UA) and/or routing of requests using the P2PSIP 232 Overlay. A P2PSIP Overlay SUer Agent differs from a conventional 233 SIP user agent in that it is coupled directly to a P2PSIP Overlay 234 Peer or P2PSIP Overlay Client, and can therefore directly interact 235 with a P2PSIP Overlay, which a conventional SIP UA cannot do. 236 P2PSIP Overlay User Agents are presumed to have no distinguished 237 name or identifier. Short forms: overlay UA, P2PSIP UA. 239 P2PSIP Overlay User: An addressable user endpoint, entity, service, 240 or function within a P2PSIP Overlay. Examples include but are not 241 limited to humans, automata, bridges, mixers, media relays, 242 gateways, and media storage. Short forms: overlay user, P2PSIP 243 user. 245 P2PSIP Overlay User Identifier: A distinguished name that identifies 246 a specific P2PSIP Overlay User within a given P2PSIP Overlay. 247 This is presumed to be a URI scoped to the P2PSIP Overlay 248 Identifier. This is presumably the same as a SIP Address of 249 Record, or AOR Short forms: overlay user identifier, P2PSIP user 250 identifier, P2PSIP user-ID, P2PSIP AOR. 252 P2PSIP Overlay User Record: A block of data, stored in the data 253 mechanism of the P2PSIP Overlay, that includes information 254 relevant to a specific user. We presume that there may be 255 multiple types of user records. Some may describe routes to a 256 client at which the user is presumed reachable (a "user routing 257 record", like a SIP "Contact:"). Others might store presence 258 information. The types, usages, and formats of user records are a 259 question for future study. 261 P2PSIP Overlay Peer Protocol: The protocol spoken between P2P 262 Overlay peers to share information and organize the P2P Overlay 263 Network. Short form: peer protocol. 265 P2PSIP Overlay Client Protocol: The protocol spoken between P2P 266 Overlay Clients and the P2P Overlay Peer they use to place into or 267 retrieve information from the P2P Overlay Network. This is 268 presumably a functional subset of the P2P Overlay Peer Protocol, 269 but may differ in syntax and protocol implementation (i.e., may 270 not be syntactically related). Note that the precise relationship 271 between the P2PSIP Overlay Peer Protocol and the P2PSIP Overlay 272 Client Protocol remains an open question and is expected to be a 273 principle topic of the detailed design work. Short form: client 274 protocol. 276 P2PSIP Overlay Neighbors: The set of P2P Overlay Peers that either a 277 P2P Overlay Peer or P2P Overlay Client know of directly and can 278 reach without further lookups. Short form: neighbor 280 P2PSIP Overlay Bootstrap Server: A network node used by P2PSIP 281 Overlay Peers or Clients who are attempting to enter to locate an 282 entry into the P2P Overlay Network. It may return an entry point 283 (address of a Peer) to the P2PSIP Overlay or act as one itself. 284 This should be a quasi-stable and well known host, located using a 285 configuration or discovered via , DNS, broadcast, or other 286 mechanism. Example: a P2PSIP Overlay Peer that reboots and has no 287 knowledge of other peers uses a P2PSIP Overlay Bootstrap Server to 288 find other peers in the P2P Overlay Network and establish P2PSIP 289 Overlay Peer Insertion. (Note: An overlay peer might or might not 290 provide this functionality). Short forms: bootstrap server, boot 291 server. 293 P2PSIP Overlay Peer Insertion: The act of inserting a P2PSIP Overlay 294 Peer into the current routing structure (presumably a distributed 295 database or hash table) of a P2PSIP Overlay. In general, this 296 routing structure maps the peer's P2PSIP Overlay Peer Key to the 297 IP address or DNS name of the peer. During insertion, the peer 298 discovers its P2PSIP Overlay neighbors. Following insertion, the 299 peer will be able to store user records (such as routing 300 information), query other peers for user records, and pass 301 requests to route messages to other peers. Short form: peer 302 insertion. 304 P2PSIP Overlay User Record Insertion: The act of inserting a record 305 for a P2PSIP Overlay User into the data maintained by the P2PSIP 306 Overlay Peers. Following insertion, the data stored at one or 307 more peers will contain a record (such as a P2PSIP Overlay User 308 Routing Record), keyed at least in part by a P2PSIP Overlay User 309 Identifier. Short form: User record insertion. 311 P2PSIP Overlay User Routing Record: A P2PSIP overlay user record 312 that provides a routing vector that points to a P2PSIP UA where 313 the user can presumably be reached. This is analogous to the 314 combination of a SIP [3] "Contact:" and a "Path:" [6]. The P2PSIP 315 equivalent of a SIP registration process would be the insertion of 316 an overlay user routing record into the overlay. Short form: user 317 route record or user route. 319 P2PSIP Overlay Peer Enrollment: The initial one-time process a 320 P2PSIP Overlay Peer follows to obtain an identifier and 321 credentials, if any, within a P2PSIP Overlay. This is not 322 performed each time the peer comes online, only the first time 323 they do so, or following a loss of identifier or credentials by 324 the peer. Short form: peer enrollment. 326 P2PSIP Overlay User Enrollment: The initial one-time process a 327 P2PSIP Overlay User follows to obtain a unique identifier within a 328 P2PSIP Overlay. This is not performed each time the resource 329 comes online, only the first time they do so, or following a loss 330 of identifier or credentials by the client. Short form: user 331 enrollment. 333 3. Discussion 335 3.1. What Kinds of P2PSIP Overlay Peers and Clients Might Exist? 337 In general, P2PSIP nodes might have the same sorts of duties and 338 profiles as traditional client-server SIP nodes. This includes but 339 is not limited to: 341 1. User Agent: a phone, voice mail server, bridge, or other device 342 that initiates or terminates session requests. 344 2. Media relay: a peer or client capable of relaying RTP sessions, 345 as described in [13] 347 3. Gateway: a peer or client that converts from P2PSIP to some other 348 protocol, such as PSTN. 350 4. Redirector or Location Server: a peer or client that, given a SIP 351 (or other SIP request) to a P2PSIP overlay resource identifier, 352 returns the route to a resource in a 302 or 305 response. 354 5. Registrar: A peer or client that processes SIP REGISTER requests, 355 either storing or retrieving the contact information to/from the 356 routing data of the P2PSIP Overlay. 358 6. Proxy: A peer or client that accepts SIP requests, resolves the 359 next hop or hops using the routing information of the P2PSIP 360 Overlay, and passes the request on towards the next hop. 362 3.2. Reference Model 364 The following diagram depicts a reference or "boxes and arrows" model 365 showing several of the above peer and client types, along with two 366 conventional SIP user agents. 368 --->PSTN 369 -----------/ 370 | Gateway | 371 ________ ----------| Peer |------------- 372 | | | | | |Client Protocol 373 | UA |\ | ----------- | GET/PUT 374 | Peer |\\|N|----- | | 375 |______| \|A| | | \__/ 376 |T| ---- | v / \ 377 Peer Protocol/ |---- / UA \ 378 / P2PSIP Overlay | /Client\ 379 |N|/ | |______| 380 -------- /|A|------ Route Data | ^ 381 | |//|T| ____|___ | | 382 | UA |/ | | | | 383 | Peer | | UA | | | 384 -------- | Peer | | | 385 |______| | | 386 | | |SIP 387 Peer Protocol | --------- --------- | | 388 | | | | | | | 389 ----| Proxy |----- --| Redir |----| | 390 | Peer | | Peer | | | 391 | | | | | 392 --------- ---------- | 393 / \ / 394 / \ / 395 \__/ / SIP SIP \ \__/ / 396 /\ / \ /\ / 397 / \/ \/ \/ 398 / UA \ / UA \ 399 /______\ /______\ 400 SIP UA A SIP UA B 402 Figure: Reference Model 404 Here, the large rectangle represents the P2PSIP Overlay and its 405 associated routing data. Around the periphery of the P2PSIP Overlay 406 rectangle, we have several P2PSIP Overlay Peer nodes -- a PSTN 407 gateway, a user-agent, a proxy, and a redirector. To the left we 408 have two UA peers are behind network address translator. On the 409 right side, we have a P2PSIP Overlay "UA client", which uses the 410 P2PSIP Overlay Client Protocol to interact with the P2PSIP Overlay. 411 Below, we have conventional SIP UA "A", which has used SIP to 412 interact with the Proxy Peer and establish a dialog with the UA peer, 413 and SIP UA "B" which has been redirected by the Redirect Peer and set 414 up a dialog with the UA Client. Note that the Proxy Peer and the UA 415 Peer interact using the P2PSIP Overlay Peer Protocol, which is also 416 presumably used on the keepalive links between the UA Peers and their 417 neighbors. 419 Both the "Proxy Peer" and "Redir Peer" serve as adapters between 420 ordinary SIP devices and the the P2PSIP Overlay. Each accepts SIP 421 requests and resolves the next-hop by using the P2PSIP overlay Peer 422 Protocol to interact with the routing knowledge of the P2PSIP 423 Overlay, then processes the SIP requests as appropriate (proxying or 424 redirecting towards the next-hop). 426 The Gateway Peer provides a similar sort of adaptation to and from 427 the public switched telephone network (PSTN). However, there is a 428 subtle distinction. The gateway function itself can be viewed as a 429 "user" or within the P2PSIP overlay, and is addressed using a P2PSIP 430 Overlay User Identifier. This gateway functionality could also be 431 located in a P2PSIP Overlay Client, or even in a traditional SIP UA 432 that is reached via P2P (using a P2P proxy or redirector) or 433 conventional SIP mechanisms. 435 3.3. Conceptual Outline of Operations 437 3.3.1. Enrolling and Inserting an P2PSIP Overlay Peer 439 Peers are the full-function "routing and storage" nodes of a P2PSIP 440 Overlay. When a new peer is first created, it must enroll in the 441 P2PSIP Overlay. We currently have no defined mechanism for this (do 442 we need one?), but we know that once the process is complete, the new 443 peer will have at least a P2PSIP Overlay Peer Key and a set of 444 credentials. 446 After enrollment, each time the peer connects to the overlay, it must 447 insert itself. We don't have a defined protocol and process for 448 this, and assume we need one. Presumably the inserting peer connects 449 to one or more existing peers (possibly with the aid of a bootstrap 450 server) presents its credentials, and ends up connected to the 451 overlay, with some knowledge of neighbors (successor, precursor, 452 finger tables, or whatever the distribution mechanism defines) and is 453 able to store data on behalf of and route requests to other nodes in 454 the P2PSIP overlay. 456 3.3.2. More on The Difference Between a Peer, Client, and User Agent 458 P2PSIP Overlay Peers directly interact with and contain the routing 459 and storage fabric of the overlay. P2PSIP Overlay Clients just use 460 the routing and storage facilities provided by the peers. The peers 461 speak the P2PSIP Overlay Peer Protocol, which presumably has a full 462 range of expressivity for the routing and storage facilities of the 463 overlay. Clients speak the P2PSIP Overlay Client protocol, which is 464 presumably a subset of the peer protocol, and is limited to storage 465 insertion (put), storage retrieval (get), and message routing (send). 467 Some peers and some clients may be coupled to SIP user agents, making 468 them P2PSIP Overlay User Agents capable of both sending and receiving 469 conventional SIP messages (as per a SIP UA) using conventional SIP 470 resolution procedures and of using the resolution facilities provided 471 by the overlay 473 The mix and configuration of peers, clients, and P2PSIP UAs is 474 expected to vary depending on the deployment scenario. For example, 475 an ad-hoc scenario might deploy nothing but P2PSIP Overlay Peers, 476 each of which is coupled to a P2PSIP User Agent, using a broadcast or 477 multicast bootstrap mechanism. Another common scenario, the "self 478 organizing proxy farm", might consist of P2PSIP Overlay Peers, each 479 of which is coupled to a SIP proxy/registrar function. 481 3.3.3. Enrolling a User and Inserting a P2PSIP Overlay User Agent 483 Clients and Peers are the "end points" or "user agents" of a P2PSIP 484 Overlay. Users are the named entities that participate in a P2PSIP 485 overlay using a client. 487 To get started, users must be enrolled in the overlay. We do not 488 have a process or protocol for this, nor are we certain we need a 489 standardized mechanism. We presume that after enrollment, the user 490 has a distinguished name within the overlay (example: 491 sip:bob@example.com) and a set of credentials useful for 492 authenticating its usage of the distinguished name. One possible 493 mechanism for these credentials would be an x.509 certificate. It 494 might also be possible to use a PGP key, a password, or some other 495 mechanism. Presumably following enrollment, the user is also 496 equipped with the information needed to connect to the overlay, such 497 as the address of a bootstrap server. Whether this startup 498 information is delivered as a part of enrollment of through some 499 separate configuration process remains an open question. 501 Once a user is enrolled, the user may exercise a P2PSIP Overlay User 502 Agent to insert into the P2PSIP Overlay. We currently have no 503 protocol for this, and need one. The P2PSIP UA exercises either a 504 P2PSIP Overlay Peer or P2PSIP Overlay Client to execute the 505 "registration" function and insert a route for the user into the 506 P2PSIP overlay. This function is described as a "PUT" request, and 507 results in the storage of an authenticated route-set for the user in 508 the P2PSIP overlay, such that the terminus of the route is the URI of 509 the user at the P2PSIP UA. This is analogous to "registration" in a 510 classic SIP environment, and might even be doable using the SIP 511 REGISTER method. Presumably, the P2PSIP UA connects to a peer or 512 client and uses the user's credentials to authenticate a route-set 513 (Contact: plus Path:) to itself, and the peer or client stores the 514 route-set into the overlay, using a key derived from the user's 515 identity. 517 3.3.4. Placing a Call from a P2PSIP Overlay Client UA to a P2PSIP 518 Overlay Client UA 520 Assume we have two users, Alice and Bob, who have successfully 521 enrolled and inserted themselves into a P2PSIP Overlay using clients. 522 Alice wants to call Bob, and enters Bob's user identity (AOR) into 523 her client. Alice's client does not have current knowledge of a 524 route-set to Bob's client(s), so it needs to discover one. Alice's 525 Client then does a GET operation on Bob's identity, using a 526 previously-discovered peer, or using whatever procedures are needed 527 (such as RFC 3263, a bootstrap server, etc.) to find a peer. Alice's 528 client send the GET request to the selected peer. 530 The peer transforms the requested identity into a key, presumably by 531 hashing it, and determines the peer ID at which the resource (a 532 route-set) is most likely stored. The first peer then asks the 533 second peer to return the desired resource. The second peer may 534 return the desired resource, return a pointer to another peer, or 535 pass the request recursively on to another peer for resolution. 536 Eventually, some peer returns a resource containing a route-set for 537 Bob, and the first peer returns this to Alice's client. 539 Alice then sends a SIP INVITE with a request-URI equal to Bob's user 540 identity, and populated with a route from the returned route-set. 541 Bob's client returns a SIP response, and we proceed with SIP as 542 usual. 544 3.3.5. Bootstrapping 546 If a client or peer is just starting up and has no knowledge of how 547 to reach the other nodes of the overlay, it may exercise a bootstrap 548 server to find one. Presumably it discovers the bootstrap server by 549 some mechanism such as a DNS lookup, multicast, broadcast or 550 configuration, then queries the bootstrap server and receives an 551 address for a peer or set of peers that can be used to reach the 552 overlay. Ideally, these target peers will be selected from a 553 relatively large pool of peers that are currently online and 554 reachable. 556 After discovering the address of a peer, the behavior of the starting 557 node will vary depending on whether it is intending to be a peer or a 558 client. If it is intending to be a peer, it goes into the P2PSIP 559 Overlay Peer Insertion process, at the conclusion of which it is 560 actively participating in the target overlay as a peer and is capable 561 of routing requests and storing records on behalf of the P2PSIP 562 overlay. If it is intending to be a client, it does not bother with 563 insertion, but merely contacts the discovered peer in order to use 564 the overlay. 566 In the typical case, the peer or client coming up is also a P2PSIP 567 Overlay User Agent with one or more associated P2PSIP Overlay User 568 Identifiers. The next step then is to insert a P2PSIP Overlay User 569 Routing Record (a Contact:) into the P2PSIP Overlay. 571 4. Questions 573 4.1. Definition of P2PSIP Overlay Peer Enrollment 575 The definition for P2PSIP Overlay Peer Enrollment in the above 576 section doesn't sound quite right. It predates a decision made to 577 split off the UA from the Peer and Client nodes. What would a better 578 definition look like? 580 4.2. PP2PSIP Overlay Peer Protocol 582 This may or may not be SIP. What should it be? Alternatives include 583 SIP, OpenDHT, or something else. Do we need to define a new 584 protocol? 586 4.3. P2PSIP Overlay Client Protocol 588 This may or may not be SIP. What should it be? It defines only GET/ 589 PUT operations, which could be done using SIP REGISTER transactions. 591 4.4. Universal Routing: 593 Do all P2PSIP Overlay Peers route requests? How about clients? 595 4.5. How To Find Media Relays? 597 This needs to be net-path efficient. Is this possible? Is it enough 598 just to construct a key with a "relay" identifier? What sorts of 599 access controls do we need on media relays? 601 4.6. How Do We Find Gateways? 603 This needs to be not only netpath efficient, but also embodies 604 elements of the TRIP and SPEERMINT problems. 606 4.7. NAT Traversal 608 Some peers or clients may be isolated by NATs from other peers or 609 clients. How do we structure persistent keepalive connections to 610 them? Is it enough to maintain links to left and right neighbors and 611 construct dual routes? 613 4.8. Peer-Adjacency Through NATs 615 We assume that some or even many peers will be behind NATs, and 616 therefore reached through peer-to-peer routing. How do we keep alive 617 the NAT-crossing peer bindings? Is some variant of "outbound" [14] 618 usable? 620 4.9. Cryptotransparency 622 When forwarding requests, are the bodies of the requests visible to 623 peers? If so, this creates substantial security problems that the 624 deployers of conventional SIP have been willing to mostly ignore. 625 Can we make peers cryptotransparent (like HTTP proxies) when security 626 is requested? 628 4.10. Record Formats 630 Clearly we need user routing records stored into the p2PSIP overlay. 631 Do we need other sorts of record? If so, what? How do we 632 differentiate between or classify records? Do we end up with many 633 records per user per client, or do we aggregate the per-client or 634 per-user view using something like XML? 636 4.11. Peer and Client Enrollment Protocols 638 We know that we need to enroll peer and client nodes into a P2PSIP 639 Overlay. Do we define a protocol or process for this, assume it will 640 happen externally, or just provide an existence-proof argument? 642 4.12. Peer and User Credentials 644 We believe we need some sort of credentials for authenticating peers 645 and users of each P2PSIP Overlay. What should we use for these 646 credentials? Certificates? PGP keys? Passwords? If certificates, 647 should these be signed by a CA associated with the overlay, or can 648 self-signed certificates work in some or all cases? Do we need to 649 specify a standard credential format, or should we allow different 650 implementations to use different credential formats? 652 4.13. Bootstrapping 654 We know that sometimes peers or clients will start up without 655 knowledge of how to find a peer for insertion. Do we need to define 656 a bootstrap mechanism or mechanisms? Do we need to define supporting 657 protocols? 659 4.14. Credential Recovery 661 One reader suggested that we extend the definition of P2PSIP Overlay 662 Peer Enrollment to cover the case where a previously-inserted peer 663 has lost its credentials (through, perhaps, being moved to a 664 different host) and wishes to recover them without necessarily 665 creating a new P2PSIP Overlay Peer Key. The editors are inclined to 666 believe that this is an operational issue, not a matter of 667 definition, but would like to seek a broader consensus before 668 concluding the topic. A similar question applies to user enrollment. 670 4.15. Overlapping Domains 672 If the P2PSIP Overlay User Identifier is not scoped to a single DNS 673 domain, this would appear to allow nodes from two or more apparent 674 domains to share a single P2PSIP Overlay. What, if anything, do we 675 need to say about this mode of operation? 677 4.16. Hybrid Domains 679 It appears possible to have some hosts within a domain using 680 conventional SIP and some using P2PSIP. This potentially raises a 681 number of questions: 1) What should happen if we want to run a P2PSIP 682 overlay in an existing SIP domain? 2) Do the existing redir/proxy 683 servers need to be coupled with a peer layer? 3) When would an 684 overlay peer want to discover them as opposed to looking in the 685 overlay? 4) Is better not to run conventional SIP with overlay SIP? 686 5) When conventional and P2PSIP are run together, shall the existing 687 redir servers keep their local databases or switch to the overlay 688 storage. 690 4.17. Admissions Control 692 What do we need to say about admissions control with respect to the 693 enrollment of peers and users? Do we need to discuss per-call 694 admissions control in a P2P environment? 696 4.18. Users versus Resources 698 This model presumes that all addressable elements, aka "users", are 699 unique. Are their other classes of resources that need some sort of 700 class-addressable identifier that does not refer to a unique user? 702 5. Security Considerations 704 This specification probably has all sorts of security requirements 705 that we just haven't gotten to. 707 6. IANA Considerations 709 This document raises no IANA considerations. Yet. 711 7. Acknowledgements 713 This document draws heavily from the contributions of many 714 participants in the P2PSIP Mailing List but the authors are 715 especially grateful for the support of Henning Schulzrinne and Cullen 716 Jennings, both of whom spent many long pain-filled hours on the phone 717 with us. 719 8. References 721 8.1. Normative References 723 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 724 Levels", BCP 14, RFC 2119, March 1997. 726 [2] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform 727 Resource Locators (URL)", RFC 1738, December 1994. 729 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 730 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 731 Session Initiation Protocol", RFC 3261, June 2002. 733 [4] Mockapetris, P., "Domain names - concepts and facilities", 734 STD 13, RFC 1034, November 1987. 736 [5] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 737 (SIP): Locating SIP Servers", RFC 3263, June 2002. 739 [6] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) 740 Extension Header Field for Registering Non-Adjacent Contacts", 741 RFC 3327, December 2002. 743 8.2. Informative References 745 [7] Bryan, D., "A P2P Approach to SIP Registration and Resource 746 Location", draft-bryan-sipping-p2p-02 (work in progress), 747 March 2006. 749 [8] Shim, E., "An Architecture for Peer-to-Peer Session Initiation 750 Protocol (P2P SIP)", draft-shim-sipping-p2p-arch-00 (work in 751 progress), March 2006. 753 [9] Sinnreich, H. and A. Johnston, "SIP, P2P, and Internet 754 Communications", draft-johnston-sipping-p2p-ipcom-02 (work in 755 progress), March 2006. 757 [10] Matthews, P., "Industrial-Strength P2P SIP", 758 draft-matthews-sipping-p2p-industrial-strength-00 (work in 759 progress), February 2005. 761 [11] Risson, J. and T. Moors, "Survey of Research towards Robust 762 Peer-to-Peer Networks: Search Methods", 763 draft-irtf-p2prg-survey-search-00 (work in progress), 764 March 2006. 766 [12] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, 767 June 2005. 769 [13] Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal 770 of UDP Through NAT (STUN)", draft-ietf-behave-turn-00 (work in 771 progress), March 2006. 773 [14] Jennings, C. and R. Mahy, "Managing Client Initiated 774 Connections in the Session Initiation Protocol (SIP)", 775 draft-ietf-sip-outbound-03 (work in progress), March 2006. 777 URIs 779 [15] 781 Authors' Addresses 783 Dean Willis (editor) 784 Cisco Systems 785 3100 Independence Pkwy #311-164 786 Plano, Texas 75075 787 USA 789 Phone: unlisted 790 Email: dean.willis@softarmor.com 792 David Bryan 793 P2PSIP.org and William and Mary Department of Computer Science 794 P.O. Box 6741 795 Williamsburg, Virginia 23188 796 USA 798 Phone: unlisted 799 Email: bryan@ethernot.org 801 Philip Matthews 802 Avaya 803 100 Innovation Drive 804 Ottawa, Ontario K2K 3G7 805 Canada 807 Phone: +1 613 592 4343 x224 808 Email: philip_matthews@magma.ca 810 Eunsoo Shim 811 Panasonic Digital Networking Laboratory 812 Two Research Way, 3rd Floor 813 Princeton, New Jersey 08540 814 USA 816 Phone: unlisted 817 Email: eunsoo@research.panasonic.com 819 Full Copyright Statement 821 Copyright (C) The Internet Society (2006). 823 This document is subject to the rights, licenses and restrictions 824 contained in BCP 78, and except as set forth therein, the authors 825 retain all their rights. 827 This document and the information contained herein are provided on an 828 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 829 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 830 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 831 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 832 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 833 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 835 Intellectual Property 837 The IETF takes no position regarding the validity or scope of any 838 Intellectual Property Rights or other rights that might be claimed to 839 pertain to the implementation or use of the technology described in 840 this document or the extent to which any license under such rights 841 might or might not be available; nor does it represent that it has 842 made any independent effort to identify any such rights. Information 843 on the procedures with respect to rights in RFC documents can be 844 found in BCP 78 and BCP 79. 846 Copies of IPR disclosures made to the IETF Secretariat and any 847 assurances of licenses to be made available, or the result of an 848 attempt made to obtain a general license or permission for the use of 849 such proprietary rights by implementers or users of this 850 specification can be obtained from the IETF on-line IPR repository at 851 http://www.ietf.org/ipr. 853 The IETF invites any interested party to bring to its attention any 854 copyrights, patents or patent applications, or other proprietary 855 rights that may cover technology that may be required to implement 856 this standard. Please address the information to the IETF at 857 ietf-ipr@ietf.org. 859 Acknowledgment 861 Funding for the RFC Editor function is provided by the IETF 862 Administrative Support Activity (IASA).